[Top][All Lists]

[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 11:49:54 +0100
User-agent: Mutt/1.5.11


Richard Braun, le Sun 31 Dec 2006 19:17:03 +0100, a écrit :
> A mach_port_t is actually a port name, a natural_t integer identifier for
> a port in a port space. Maybe the kernel uses this property and considers
> it can store the address of a port in a port name, to avoid a lookup ?

Thomas Bushnell BSG, le Sun 31 Dec 2006 13:06:55 -0800, a écrit :
> On Sun, 2006-12-31 at 12:30 +0100, Samuel Thibault wrote:
> > Hi,
> > 
> > There's something I don't understand in
> > i386/i386at/i386at_ds_routines.c:ds_notify()
> > 
> >       dev = (device_t) ns->not_header.msgh_remote_port;
> > 
> > How a port can be a device_t?
> A device_t is just a mach_port_t that is expected to be talking to
> something that implements the Mach device protocol.

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:

  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)


reply via email to

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