bug-hurd
[Top][All Lists]
Advanced

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

Re: notify_no_senders oddity


From: Samuel Thibault
Subject: Re: notify_no_senders oddity
Date: Mon, 1 Jan 2007 20:08:17 +0100
User-agent: Mutt/1.5.11

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!

Samuel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]