On Mon, 2007-01-01 at 23:05 +0100, Samuel Thibault wrote: > 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.
My source (have things changed here in some material way?) does not have i386/i386at/i386at_ds_routines.c. It has oskit/ds_routines.c, which has: boolean_t ds_notify (mach_msg_header_t *msg) { if (msg->msgh_id == MACH_NOTIFY_NO_SENDERS) { device_t dev; mach_no_senders_notification_t *ns; ns = (mach_no_senders_notification_t *) msg; dev = dev_port_lookup ((ipc_port_t) ns->not_header.msgh_remote_port); assert (dev); /* Extant send rights held one ref on the device object, and we just got another one from dev_port_lookup. */ device_deallocate (dev); device_deallocate (dev); return TRUE; } printf ("ds_notify: strange notification %d\n", msg->msgh_id); return FALSE; } Notice that this routine does not simply cast the remote point, but looks it up in the table of device ports.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd