[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: notify_no_senders oddity
From: |
Richard Braun |
Subject: |
Re: notify_no_senders oddity |
Date: |
Sun, 31 Dec 2006 19:17:03 +0100 |
User-agent: |
Mutt/1.5.9i |
On Sun, Dec 31, 2006 at 05:33:21PM +0100, Samuel Thibault wrote:
> Well, I actually don't know much details about mach ports :)
>
> More specifically, I'm talking about an ipc_port_t, as used for instance
> in linux/dev/glue/block.c in device_open()
>
> bd->port = ipc_port_alloc_kernel ();
>
> and just a few lines below,
>
> ipc_port_nsrequest (bd->port, 1, notify, ¬ify);
>
> which eventually calls ipc_notify_no_senders() which does
>
> n->not_header.msgh_remote_port = (mach_port_t) port;
>
> Hence casting ipc_port_t into mach_port_t, which later is converted to
> device_t as I said:
>
> > > dev = (device_t) ns->not_header.msgh_remote_port;
ipc_mqueue_send_always(), which is called bye ipc_notify_no_senders(),
is a macro which calls ipc_mqueue_send() :
ipc_mqueue_send(kmsg, option, time_out)
ipc_kmsg_t kmsg;
mach_msg_option_t option;
mach_msg_timeout_t time_out;
{
ipc_port_t port;
port = (ipc_port_t) kmsg->ikm_header.msgh_remote_port;
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 ?
--
Richard Braun
signature.asc
Description: Digital signature