DragonFly kernel List (threaded) for 2003-07
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
C++
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
example:
struct myport {
MsgPort port;
MsgPort *realport;
}t;
...initialization of port...
myport->port.mp_SendMsg = myfunc;
myport->realport = originalport;
And then:
int
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]