Re: notify_no_senders oddity

[Thomas Bushnell BSG]

On Mon, 2007-01-01 at 20:08 +0100, Samuel Thibault wrote:
> Richard Braun, le Mon 01 Jan 2007 17:47:32 +0100, a écrit :
> > On Mon, Jan 01, 2007 at 11:49:54AM +0100, Samuel Thibault wrote:
> > > Ok, and how these two views may coexist?  As I showed, they _are_ mixed
> > > in the case of the linux block device glue for instance:
> > > linux/dev/glue/block.c:device_open():
> > > 
> > >   bd->device.emul_data = bd;
> > >   bd->device.emul_ops = &linux_block_emulation_ops;
> > >   ...
> > >   bd->port = ipc_port_alloc_kernel ();
> > >   ...
> > >   notify = ipc_port_make_sonce (bd->port);
> > >   ip_lock (bd->port);
> > >   ipc_port_nsrequest (bd->port, 1, notify, &notify);
> > > 
> > > 
> > > So here it's really a plain IPC port that is used (and it's the same in
> > > the plain device/ds_routines.c, linux net glue and pcmcia glue), while
> > > on the other end: i386/i386at/i386at_ds_routines.c
> > > 
> > >       dev = (device_t) ns->not_header.msgh_remote_port;
> > > 
> > > How can this work?  (I currently have a kernel fault here)
> > 
> > I guess it's because the device_t type is defined to something else
> > for i386 devices :
> 
> No objection to that, since that's precisely what Thomas said.  But just
> to repeat myself: as quoted above linux block/net/pcmcia devices and
> mach devices provide an IPC port, not a device_t!

ah, I recall now.

The MiG converters for the various types are not identical.  

The way this can work is by the kernel making sure that the kernel name
for the port is the same as the address of its internal record keeping
structure.  This approach was much beloved by the Mach designers.

Thomas

signature.asc
Description: This is a digitally signed message part