Re: notify_no_senders oddity

[Samuel Thibault]

Samuel Thibault, le Mon 01 Jan 2007 22:48:38 +0100, a écrit :
> 
> 
> Both types are used for the same port.
> 
> Samuel

Thomas Bushnell BSG, le Mon 01 Jan 2007 13:54:56 -0800, a écrit :
> On Mon, 2007-01-01 at 22:48 +0100, Samuel Thibault wrote:
> > Thomas Bushnell BSG, le Mon 01 Jan 2007 12:18:17 -0800, a écrit :
> > > > > >   bd->port = ipc_port_alloc_kernel ();
> > > > > >   ipc_port_nsrequest (bd->port, 1, notify, &notify);
> > > > > > 
> > > > > >       dev = (device_t) ns->not_header.msgh_remote_port;
> > 
> > > The MiG converters for the various types are not identical.  
> > 
> > But how is the differenciation done in this case?
> 
> The mig .defs file declares a port for the argument, and when MiG
> generates the server side stub, it automagically calls a function
> declared for that type between the RPC reception and the server
> function.

Ok, that I can understand, but the code snippet I showed doesn't pass
through MiG, it's just a function call:

kern/ipc_kobject.c:ipc_kobject_notify():
        ipc_port_t port = (ipc_port_t) request_header->msgh_remote_port;
        ...
        switch (ip_kotype(port)) {
                case IKOT_DEVICE:
                return ds_notify(request_header);

and i386/i386at/i386at_ds_routines.c:ds_notify():

ds_notify (mach_msg_header_t *msg)
{
...
        dev = (device_t) msg->msgh_remote_port;
        if (dev->emul_ops->no_senders)

> > Both types are used for the same port.
> 
> Yes, so?

They're of incompatible type (neither can cast to the other one), while
ip_kotype(port) wants ipc_port_t and dev->emul_ops wants device_t.

Just to be really clear: the code snippet above, given some msg, first
considers its msgh_remote_port member as an ipc_port_t, and _uses_ it
as such (reading its ip_object member), and then calls ds_notify, which
itself considers msgh_remote_port as a device_t, and _uses_ it as such
(reading its emul_ops member).  I fail to see how this can ever work.

Samuel