From 2603401fa1f899a8ff60ec6a134d5bd511073a9d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 7 Aug 2012 23:25:26 +0200 Subject: IRC. --- microkernel/genode.mdwn | 17 +++ microkernel/genode/rpc.mdwn | 65 +++++++++ microkernel/l4.mdwn | 10 +- microkernel/mach/message.mdwn | 5 +- microkernel/mach/message/msgh_id.mdwn | 254 ++++++++++++++++++++++++++++++++++ microkernel/mach/rpc.mdwn | 6 +- 6 files changed, 350 insertions(+), 7 deletions(-) create mode 100644 microkernel/genode.mdwn create mode 100644 microkernel/genode/rpc.mdwn create mode 100644 microkernel/mach/message/msgh_id.mdwn (limited to 'microkernel') diff --git a/microkernel/genode.mdwn b/microkernel/genode.mdwn new file mode 100644 index 00000000..66dd6b38 --- /dev/null +++ b/microkernel/genode.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2012 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]]."]]"""]] + + * [[RPC]] + + +# IRC, freenode, #hurd, 2012-08-02 + + If someone interested, there is a channel with lectures about + Genode and L4: http://www.youtube.com/user/drsartakov?feature=watch diff --git a/microkernel/genode/rpc.mdwn b/microkernel/genode/rpc.mdwn new file mode 100644 index 00000000..4f68a9f6 --- /dev/null +++ b/microkernel/genode/rpc.mdwn @@ -0,0 +1,65 @@ +[[!meta copyright="Copyright © 2012 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]]."]]"""]] + + +# IRC, freenode, #hurd, 2012-07-20 + + for the curious, genode has a very interesting way to provide IPC + i think they're on the right path at least (synchronous rpc, + shared memory, signals, no IDL) + (i just don't like their choosing C++ at the system core) + braunr: hum, how do you write the rpc if there is no IDL ? + braunr: in a dynamic language like Python or Ruby, you can have + "transparent" RPC with no IDL, but in a language like C or C++ ? + when you call them I mean + kilobug: they call this dynamic marshalling based on C++ streams + http://genode-labs.com/publications/dynrpc-2007.pdf + sounds quite ugly to use :s but that may because I'm not fond of + C++ itself ;) + same for me + they say inheritance in RPC interfaces is "a must" + makes me skeptical + other than that, it's very promising + from the caller side, having the RPC appearing to be normal + function calls (like you do with Mig or Corba) is quite pleasant, even if + writing IDL is burdersome, you write IDL only once while calling RPC is + done very often + oh but they have that as well + there is just an additional, thin layer of hand written code to + provide that + ok + basically, interfaces are C++ virtual classes, which are then + inherited in client and server classes + (although they're changing that with recursive templates) + but i really like to idea of not relying on an IDL + recursive templates :s + yeah :> + must be some tricky code, but i guess once it's there, it must be + practical + see + http://genode.org/documentation/release-notes/11.05#New_API_for_type-safe_inter-process_communication + they also added typed capabilities, but i don't really like that + idea + braunr: shared memory for what? + antrik: for uh.. sharing ? :) + antrik: these systems don't provide ipc primitives able to share + memory directly + messages are always copied (although zero copy can be used) + so sharing must be done separately + hm... I realise that I have no idea how the map operation in L4 is + actually done... + iirc, privileged threads handle that + I guess you have to explicitly map before an RPC and revoke + afterwards, which is some overhead... + so i guess it's separated as well + i have one question in mind for now, maybe you can help me with + that : + +[[open_issues/synchronous_ipc]]. diff --git a/microkernel/l4.mdwn b/microkernel/l4.mdwn index 7af5e6fc..de311497 100644 --- a/microkernel/l4.mdwn +++ b/microkernel/l4.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2004, 2006, 2007, 2008, 2010, 2011 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2004, 2006, 2007, 2008, 2010, 2011, 2012 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 @@ -24,6 +24,12 @@ There was a GNU/Hurd [[port to L4|history/port_to_another_microkernel]], which is now stalled. +# IRC, freenode, #hurd, 2012-08-02 + + If someone interested, there is a channel with lectures about + Genode and L4: http://www.youtube.com/user/drsartakov?feature=watch + + [[!ymlfront data=""" sel4: diff --git a/microkernel/mach/message.mdwn b/microkernel/mach/message.mdwn index ba47671e..6c6cfb1e 100644 --- a/microkernel/mach/message.mdwn +++ b/microkernel/mach/message.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2002, 2003, 2010, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -9,7 +9,8 @@ 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]]."]]"""]] -*Messages* are collections of typed data, with a defined layout. +*Messages* are collections of typed data, with a defined layout, including an +[[ID|msgh_id]]. They are used for [[IPC]], and are sent to and received from [[port]]s. diff --git a/microkernel/mach/message/msgh_id.mdwn b/microkernel/mach/message/msgh_id.mdwn new file mode 100644 index 00000000..986fcbc7 --- /dev/null +++ b/microkernel/mach/message/msgh_id.mdwn @@ -0,0 +1,254 @@ +[[!meta copyright="Copyright © 2012 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_mig]] + +Every [[message]] has an ID field, which is defined in the [[RPC]] `*.defs` +files. + + +# IRC, freenode, #hurd, 2012-07-12 + +[Extending an existing RPC.] + + create a new call, either with a new variant of vm_statistics_t, + or a new structure with only the extra fields + that seems cleaner indeed + but using different names for the same thing seems so tedious and + unnecessary :/ + it's extra effort, but it pays off + i agree, it's the right way to do it + but this implies some kind of versioning + which is currently more or less done using mig subsystem numbers, + and skipping obsolete calls in rpc definition files + and a subsystem is like 100 calls (200 with the replies) + at some point we should recycle them + or use truely huge ranges + braunr: that's not something we need to worry about until we get + there -- which is not likely to happen any time soon :-) + "There is no more room in this interface for additional calls." + in mach.defs + i'll use the mach4.defs file + but it really makes no sense at all to do such things just because + we want to be compatible with 20 year old software nobody uses any more + who cares about the skips used to keep us from using the old mach + 2.5 interface .. + (and this 100 arbitrary limit is really ugly too) + braunr: I agree that we don't want to be compatible with 20 years + old software. just Hurd stuff from the last few years is perfectly fine. + braunr, antrik: I agree with the approach of using a new + RPC/data structure for incompatible changes, and I also agree that + recycling RPC slots that have been unused (skipped) for some years is + fine. + tschwinge: well, we probably shouldn't just reuse them + arbitrarily; but rather do a mass purge if the need really arises... + it would be confusing otherwise IMHO + antrik: What do you understand by doing a mass purge? + My idea indeed was to replace arbitrary "skip"s by new RPC + definitions. + a purge would be good along with a mig change to make subsystem + and routines identifier larger + i guess 16-bits width should do + But what do you unterstand by a "purge" in this context. + removing all the skips + But that moves the RPC ids following after? + yes + that's why i think it's not a good thing, unless we also change + the numbering + ... which is a incompatible change for all clients. + yes + OK, so you'd propose a new system and deprecate the current + one. + not really new + just larger numbers + we must acknowledge interfaces change with time + Yes, that's "new" enough. ;-) + New in the sense that all clients use new iterfaces. + that's enough to completely break compability, yes + at least binary + Yes. + However, I don't see an urgent need for that, do you? + Why not just recycled a skip that has been unused for a decade? + i don't think we should care much about that, as the only real + issue i can see is when upgrading a system + i don't say we shouldn't do that + actually, my current patch does exactly this + OK. :-) + purging is another topic + but purging without making numbers larger seems a bit pointless + as the point is allowing developers to change interfaces without + breaking short time compability + compatibility* + also, interfaces, even stable, can have more than 100 calls + (at the same time, i don't think there would ever be many + interfaces, so using 16-bits integers for the subsystems and the calls + should really be fine, and cleanly aligned in memory) + tschwinge: you are right, it was a brain fart :-) + no purge obviously + but I think we only should start with filling skips once all IDs + in the subsystem are exhausted + braunr: the 100 is not fixed in MIG IIRC; it's a definition we + make somewhere + BTW, using multiple subsystems for "overflowing" interfaces is a + bit ugly, but not to bad I'd say... so I wouldn't really consider this a + major problem + err... not too bad + especially since Hurd subsystem usually are spaced 1000 aways, so + there are some "spare" blocks between them anyways + hm i'm almost sure it's related to mig + that's how the reply id is computed + of course it is related to MIG... but I have a vague recollection + that this constant is not fixed in the MIG code, but rather supplied + somewhere. might be wrong though :-) + you mean like the 101-200 skip block in hurd/tioctl.defs? + pinotree: exactly + these are reserved for reply message IDs + at 200 a new request message block begins... + server.c: fprintf(file, "\tOutP->Head.msgh_id = InP->msgh_id + + 100;\n"); + it's not even a define in the mig code :/ + meaning that in the space of an hurd subsystem there are max 500 + effective rpc's? + actually, ioctls are rather special, as the numbers are computed + from the ioctl properties... + braunr: :-( + pinotree: how do you get this value ? + braunr: 1000/2? :) + ? + why not 20000/3 ? + pinotree: yes + where do they come from ? + ah ok sorry + braunr: 1000 is the space of each subsystem, and each rpc takes + an id + its replu + *reply + right + 500 is fine + better than 100 + but still, 64k is way better + and not harder to do + (hey, i'm the noob in this :) ) + braunr: it's just how "we" lay out subsystems... nothing fixed + about it really; we could just as well define new subsystems with 10000 + or whatever if we wanted + yes + but we still have to consider this mig limit + there are one or two odd exceptions though, with "related" + subsystems starting at ??500... + braunr: right. it's not pretty -- but I wouldn't consider it + enough of a problem to invest major effort in changing this... + agreed + at least not while our interfaces don't change often + which shouldn't happen any time soon + + Hmm, I also remember seeing some emails about indeed versioning + RPCs (by Roland, I think). I can try to look that up if there's + interest. + + i'm only adding a cached pages count you know :) + (well actually, this is now a vm_stats call that can replace + vm_statistics, and uses flavors similar to task_info) + braunr: I don't think introducing "flavors" is a good idea + i just did it the way others calls were done + other* + woud you prefer a larger structure with append-only upgrades ? + I prefer introducing new calls. it avoids an unncessary layer of + indirection + flavors are not exactly RPC-over-RPC, but definitely going down + that road... + right + as fetching VM statistics is not performance-critical, I would + suggest adding a new call with only the extra stats you are + introducing. then if someone runs an old kernel not implementing that + call, the values are simply left blank in the caller. makes + backward-compatibility a no-brainer + (the alternative is a new call fetching both the traditional and + the new stats -- but this is not necessary here, as an extra call + shouldn't hurt) + antrik: all right + + +## IRC, freenode, #hurd, 2012-07-13 + + so, should i replace old, unused mach.defs RPCs with mine, or add + them to e.g. mach4.defs ? + braunr: hm... actually I wonder whether we shouldn't add a + gnumach.defs -- after all, it's neither old mach nor mach4 interfaces... + true + good idea + i'll do just that + hm, doesn't adding a new interface file requires some handling in + glibc ? + simply rebuild it + youpi: no i mean + youpi: glibc knows about mach.defs and mach4.defs, but i guess we + should add something so that it knows about gnumach.defs + ah + probably, yes + ok + i don't understand why these files are part of the glibc headers + are they? + (i mean mach_interface.h and mach4.h) + for example + youpi: the interface i'll add is vm_cache_statistics(task, + &cached_objects, &cached_pages) + if it's ok i'll commit directly into the gnumach repository + shouldn't it rather be a int array, to make it extensible? + like other stat functions of gnumach + antrik was against doing that + well, he was against using flavors + maybe we could have an extensible array yes, and require additions + at the end of the structure + + +## IRC, freenode, #hurd, 2012-07-14 + + braunr: there are two reasons why the files are part of glibc. one + is that glibc itself uses them, so it would be painful to handle + otherwise. the other is that libc is traditionally responsible for + providing the system interface... + having said that, I'm not sure we should stick with that :-) + antrik: what do you think about having a larger structure with + reserved fields ? sounds a lot better than flavors, doesn't it ? + antrik: it's in debian, yes + grmbl, adding a new interface just for a single call is really + tedious + i'll just add it to mach4 + braunr: well, it's not unlikely there will be other new calls in + the future... but I guess using mach4.defs isn't too bad + braunr: as for reserved fields, I guess that is somewhat better + than flavors; but I can't say I exactly like the idea either... + antrik: there is room in mach4 ;p + + +## IRC, freenode, #hurd, 2012-07-23 + + I'm not sure yet whether I'm happy with adding the RPC to + mach4.defs. + that's the only question yes + (well, no, not only) + as i know have a better view of what's involved, it may make sense + to create a gnumach.defs file + tschwinge: all right i'll create a gnumach.defs file + braunr: Well, if there is general agreement that this is the + way to go. + braunr: In that case, I guess there's no point in being more + fine-grained -- gnumach-vm.defs or similar -- that'd probably be + over-engineering. If the glibc bits for libmachuser are not + straight-forward, I can help with that of course. + ok + + +## IRC, freenode, #hurd, 2012-07-27 + + tschwinge: i've pushed a patch on the gnumach page_cache branch + that adds a gnumach.defs interface + tschwinge: if you think it's ok, i'll rewrite a formal changelog + so it can be applied diff --git a/microkernel/mach/rpc.mdwn b/microkernel/mach/rpc.mdwn index 422e0441..3615fc12 100644 --- a/microkernel/mach/rpc.mdwn +++ b/microkernel/mach/rpc.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2002, 2003, 2007, 2008, 2010, 2011 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2007, 2008, 2010, 2011, 2012 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 @@ -18,7 +18,7 @@ transparently. This can be implemented with user [[task]]s, but there is an implementation in the kernel possible, too, which is called *NORMA*, but is not avilable in [[GNU Mach|gnumach]]. -The RPC stub code generated by [[MIG]]. +The RPC stub code is generated by [[MIG]] to send appropriate [[message]]s. # Tracing -- cgit v1.2.3