From 1c8909017d006c8e4afeea6d1a1efdebe26fc6b0 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 15 Jul 2011 22:46:18 +0200 Subject: IRC. --- microkernel/mach/rpc/discussion.mdwn | 117 +++++++++++++++++++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 microkernel/mach/rpc/discussion.mdwn (limited to 'microkernel/mach/rpc') diff --git a/microkernel/mach/rpc/discussion.mdwn b/microkernel/mach/rpc/discussion.mdwn new file mode 100644 index 00000000..00e4a012 --- /dev/null +++ b/microkernel/mach/rpc/discussion.mdwn @@ -0,0 +1,117 @@ +[[!meta copyright="Copyright © 2011 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]] + + +# 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 -- cgit v1.2.3