[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_documentation]] [[!toc]] # Mach initiating RPCs to userspace tasks ## IRC, freenode, #hurd, 2011-06-11 I don't think we have a precendence case of Mach initiating RPCs to userspace tasks well mach regularly sends RPCs to external pagers hm, right anyways, the ds_ in device.defs is for use *inside* Mach, not for the userspace interface what makes you think so ? several things not least the fact that without zhengda's modifications, the device handling never calls out to userspace for all I know hm, it does for async I/O when the kernel has finished its I/O, it calls ds_device_read_reply/ds_device_write_reply I see I never quite understood the _reply stuff although i wonder how mig is supposed to forge those names braunr: it isn't braunr: there is a separate device_reply.defs braunr: and it sets a *userprefix* of ds_ rather than a serverprefix i saw, yes ah right so ds still refers to the in-Mach device server, not anything userspace so this is where the patch is supposed to introduce the device_intr_notify RPC or at least that's my understanding... no, it doesn't refer to in-mach servers it really forges the right rpcs to be called by mach the definition of "RPC" is rather unclear here why ? mach has its own mach_msg() call for kernel-to-user messaging yes, but this is used only to send the reply message for the RPC earlier initiated by userspace AIUI it doesn't look like there is any special RPC for async I/O yes, because this is the only use case they had hence the name "reply" intr_notify isn't a reply, but it uses the same mechanism these are declared as simpleroutine sure. but the fact that it isn't a reply message, but rather initiates a new RPC, changes things from MiG point of view I believe right, as there is no reply to the reply :-) :) a simpleroutine is how to turn an rpc into a simple ipc I know so in _reply, we pretend that the reply is actually a new RPC, with server and client roles reversed, and no reply (this is actually rather kludgy... apparently MIG has no real notion of async replies) i don't understand what you mean simpleroutine is the explicit solution for async replies as stated in http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps it's not a new rpc with roles reversed it's not a reply either it might be an explicit solution for that, but it still seems kludgy :-) i don't see why :/ would you have expected something like an option to create both sync and async versions ? because it requires an extra .defs file yes ok well this seems cumbersome to me :) i prefer the simpleroutine approach but i agree this seems odd since mach has a high level ipc api anyways, my point is that the ds_ in device_reply.defs still refers to the Mach side of things npnth: which package fails to build ? though a userspace process that actually handles the replies in an async fashion will of course need some kind of device server too, just like the DDE stuff... though naming it ds_ is confusing IMHO, because of the name clash with the device server in Mach hm again, i fail to see why ds_ just means device_server and as most things in mach, it can be in kernel or not i mean, this is an interface prefix, i don't refer to an actual single instance of a "device server" out there oh, right... DDE implements the Mach device protocol, so it *does* do the ds_ part... but that makes the interrupt notification stuff even more confusing hm because it provides a ds_device_intr_notify() which will never be used, just to completely implement the interface ? yeah, that's what I suspect... sounds likely the device interface actually has two parts: one for "generic" RPCs on the master device port, and one for device-specific RPCs. DDE implements the latter, and uses the former... they live in separate places though I think: the individual device RPCs are implemented in libmachdev, while the intr_ stuff is used in libddekit probably it would be hairy to build otherwise so we *really* need to know what component npnth gets the error with braunr: nah, not really. that's why we always have a separate prefix for the server routines in Hurd RPCs right, i really need to read about mig again it's pretty normal for a translator to both implement and use an interface # `MACH_SEND_INTERRUPT`/`MACH_RCV_INTERRUPT` [[!tag open_issue_glibc open_issue_gnumach]] ## IRC, freenode, #hurd, 2013-03-22 i'm also testing glibc packages on darnassus with a patch that removes the MACH_{SEND,RCV}_INTERRUPT options from mach_msg calls to avoid taking the slow path because of them if i got it right, almost every mach_msg call doesn't use any of these options, except for select it could slightly improve that, i'm not sure but don't we need that to get EINTR ? the options are purely userspace i'll upload the patch http://www.sceen.net/~rbraun/0001-Mask-options-implemented-by-the-userspace-side-of-ma.patch ah, ok, you mean userspace already implements what we need ## IRC, freenode, #hurd, 2013-04-23 i couldn't measure any difference with the glibc patch that removes the mach_msg interrupt related flags which isn't very surprising as it only concerns select as far as i can tell