bug-hurd
[Top][All Lists]
Advanced

[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, &notify);
> 
> 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

Attachment: signature.asc
Description: Digital signature


reply via email to

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