Samuel Thibault, le Mon 01 Jan 2007 22:48:38 +0100, a écrit :
>
>
> Both types are used for the same port.
>
> Samuel
Thomas Bushnell BSG, le Mon 01 Jan 2007 13:54:56 -0800, a écrit :
> On Mon, 2007-01-01 at 22:48 +0100, Samuel Thibault wrote:
> > Thomas Bushnell BSG, le Mon 01 Jan 2007 12:18:17 -0800, a écrit :
> > > > > > bd->port = ipc_port_alloc_kernel ();
> > > > > > ipc_port_nsrequest (bd->port, 1, notify, ¬ify);
> > > > > >
> > > > > > dev = (device_t) ns->not_header.msgh_remote_port;
> >
> > > The MiG converters for the various types are not identical.
> >
> > But how is the differenciation done in this case?
>
> The mig .defs file declares a port for the argument, and when MiG
> generates the server side stub, it automagically calls a function
> declared for that type between the RPC reception and the server
> function.
Ok, that I can understand, but the code snippet I showed doesn't pass
through MiG, it's just a function call:
kern/ipc_kobject.c:ipc_kobject_notify():
ipc_port_t port = (ipc_port_t) request_header->msgh_remote_port;
...
switch (ip_kotype(port)) {
case IKOT_DEVICE:
return ds_notify(request_header);
and i386/i386at/i386at_ds_routines.c:ds_notify():
ds_notify (mach_msg_header_t *msg)
{
...
dev = (device_t) msg->msgh_remote_port;
if (dev->emul_ops->no_senders)
> > Both types are used for the same port.
>
> Yes, so?
They're of incompatible type (neither can cast to the other one), while
ip_kotype(port) wants ipc_port_t and dev->emul_ops wants device_t.
Just to be really clear: the code snippet above, given some msg, first
considers its msgh_remote_port member as an ipc_port_t, and _uses_ it
as such (reading its ip_object member), and then calls ds_notify, which
itself considers msgh_remote_port as a device_t, and _uses_ it as such
(reading its emul_ops member). I fail to see how this can ever work.
Samuel
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
