DragonFly BSD
DragonFly kernel List (threaded) for 2003-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]


From: Peter Dufault <dufault@xxxxxxx>
Date: Fri, 18 Jul 2003 18:51:28 -0400

On Friday, Jul 18, 2003, at 13:34 US/Eastern, Matthew Dillon wrote:

:As I understand it mp_SendMsg is a function pointer in the message port
:structure. It gets filled in when the port is created.

Precisely. mp_SendMsg() is controlled by the target port and thus is
responsible for any frontend optimizations and conversions, including
chaining. mp_SendMsg is the 'agent' for the target port.

    This leads to all sorts of cool possibilities.  Inserting a shim
    becomes very easy, you would provide your own port that hides the
    real one and then you would do your own frontend processing.  For

    struct myport {
	MsgPort		port;
	MsgPort		*realport;

    ...initialization of port...
    myport->port.mp_SendMsg = myfunc;
    myport->realport = originalport;

And then:

    myfunc(struct myport *port, Msg *msg)
	if (message is something we want to play with) {
	/* else fall through to original port */
	return(port->realport->mp_SendMsg(port->realport, msg));

The port agent would be responsible for all sorts of things. For
example, in the kernel on a port representing entry into the TCP stack
the port agent would be responsible for partitioning the work amoungst
available TCP stack worker threads and forwarding the message

Did you consider using a subset of C++ for the kernel? I'm asking because of this example and because I personally would have had to consider it because of the hand-built repetitive infrastructure of pure C.

I can see many drawbacks (enforcing a subset, issues associated with many fingers in the pie, etc) and I want to know what you thought about it.

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]