diff options
Diffstat (limited to 'microkernel')
| -rw-r--r-- | microkernel/genode.mdwn | 17 | ||||
| -rw-r--r-- | microkernel/genode/rpc.mdwn | 65 | ||||
| -rw-r--r-- | microkernel/l4.mdwn | 10 | ||||
| -rw-r--r-- | microkernel/mach/message.mdwn | 5 | ||||
| -rw-r--r-- | microkernel/mach/message/msgh_id.mdwn | 254 | ||||
| -rw-r--r-- | microkernel/mach/rpc.mdwn | 6 |
6 files changed, 350 insertions, 7 deletions
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 + + <mcsim> 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 + + <braunr> for the curious, genode has a very interesting way to provide IPC + <braunr> i think they're on the right path at least (synchronous rpc, + shared memory, signals, no IDL) + <braunr> (i just don't like their choosing C++ at the system core) + <kilobug> braunr: hum, how do you write the rpc if there is no IDL ? + <kilobug> 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++ ? + <kilobug> when you call them I mean + <braunr> kilobug: they call this dynamic marshalling based on C++ streams + <braunr> http://genode-labs.com/publications/dynrpc-2007.pdf + <kilobug> sounds quite ugly to use :s but that may because I'm not fond of + C++ itself ;) + <braunr> same for me + <braunr> they say inheritance in RPC interfaces is "a must" + <braunr> makes me skeptical + <braunr> other than that, it's very promising + <kilobug> 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 + <braunr> oh but they have that as well + <braunr> there is just an additional, thin layer of hand written code to + provide that + <kilobug> ok + <braunr> basically, interfaces are C++ virtual classes, which are then + inherited in client and server classes + <braunr> (although they're changing that with recursive templates) + <braunr> but i really like to idea of not relying on an IDL + <kilobug> recursive templates :s + <braunr> yeah :> + <braunr> must be some tricky code, but i guess once it's there, it must be + practical + <braunr> see + http://genode.org/documentation/release-notes/11.05#New_API_for_type-safe_inter-process_communication + <braunr> they also added typed capabilities, but i don't really like that + idea + <antrik> braunr: shared memory for what? + <braunr> antrik: for uh.. sharing ? :) + <braunr> antrik: these systems don't provide ipc primitives able to share + memory directly + <braunr> messages are always copied (although zero copy can be used) + <braunr> so sharing must be done separately + <antrik> hm... I realise that I have no idea how the map operation in L4 is + actually done... + <braunr> iirc, privileged threads handle that + <antrik> I guess you have to explicitly map before an RPC and revoke + afterwards, which is some overhead... + <braunr> so i guess it's separated as well + <braunr> 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 + + <mcsim> 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.] + + <antrik> create a new call, either with a new variant of vm_statistics_t, + or a new structure with only the extra fields + <braunr> that seems cleaner indeed + <braunr> but using different names for the same thing seems so tedious and + unnecessary :/ + <antrik> it's extra effort, but it pays off + <braunr> i agree, it's the right way to do it + <braunr> but this implies some kind of versioning + <braunr> which is currently more or less done using mig subsystem numbers, + and skipping obsolete calls in rpc definition files + <braunr> and a subsystem is like 100 calls (200 with the replies) + <braunr> at some point we should recycle them + <braunr> or use truely huge ranges + <antrik> braunr: that's not something we need to worry about until we get + there -- which is not likely to happen any time soon :-) + <braunr> "There is no more room in this interface for additional calls." + <braunr> in mach.defs + <braunr> i'll use the mach4.defs file + <braunr> 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 + <braunr> who cares about the skips used to keep us from using the old mach + 2.5 interface .. + <braunr> (and this 100 arbitrary limit is really ugly too) + <antrik> 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. + <tschwinge> 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. + <antrik> tschwinge: well, we probably shouldn't just reuse them + arbitrarily; but rather do a mass purge if the need really arises... + <antrik> it would be confusing otherwise IMHO + <tschwinge> antrik: What do you understand by doing a mass purge? + <tschwinge> My idea indeed was to replace arbitrary "skip"s by new RPC + definitions. + <braunr> a purge would be good along with a mig change to make subsystem + and routines identifier larger + <braunr> i guess 16-bits width should do + <tschwinge> But what do you unterstand by a "purge" in this context. + <braunr> removing all the skips + <tschwinge> But that moves the RPC ids following after? + <braunr> yes + <braunr> that's why i think it's not a good thing, unless we also change + the numbering + <tschwinge> ... which is a incompatible change for all clients. + <braunr> yes + <tschwinge> OK, so you'd propose a new system and deprecate the current + one. + <braunr> not really new + <braunr> just larger numbers + <braunr> we must acknowledge interfaces change with time + <tschwinge> Yes, that's "new" enough. ;-) + <tschwinge> New in the sense that all clients use new iterfaces. + <braunr> that's enough to completely break compability, yes + <braunr> at least binary + <tschwinge> Yes. + <tschwinge> However, I don't see an urgent need for that, do you? + <tschwinge> Why not just recycled a skip that has been unused for a decade? + <braunr> i don't think we should care much about that, as the only real + issue i can see is when upgrading a system + <braunr> i don't say we shouldn't do that + <braunr> actually, my current patch does exactly this + <tschwinge> OK. :-) + <braunr> purging is another topic + <braunr> but purging without making numbers larger seems a bit pointless + <braunr> as the point is allowing developers to change interfaces without + breaking short time compability + <braunr> compatibility* + <braunr> also, interfaces, even stable, can have more than 100 calls + <braunr> (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) + <antrik> tschwinge: you are right, it was a brain fart :-) + <antrik> no purge obviously + <antrik> but I think we only should start with filling skips once all IDs + in the subsystem are exhausted + <antrik> braunr: the 100 is not fixed in MIG IIRC; it's a definition we + make somewhere + <antrik> 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 + <antrik> err... not too bad + <antrik> especially since Hurd subsystem usually are spaced 1000 aways, so + there are some "spare" blocks between them anyways + <braunr> hm i'm almost sure it's related to mig + <braunr> that's how the reply id is computed + <antrik> 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 :-) + <pinotree> you mean like the 101-200 skip block in hurd/tioctl.defs? + <antrik> pinotree: exactly + <antrik> these are reserved for reply message IDs + <antrik> at 200 a new request message block begins... + <braunr> server.c: fprintf(file, "\tOutP->Head.msgh_id = InP->msgh_id + + 100;\n"); + <braunr> it's not even a define in the mig code :/ + <pinotree> meaning that in the space of an hurd subsystem there are max 500 + effective rpc's? + <antrik> actually, ioctls are rather special, as the numbers are computed + from the ioctl properties... + <antrik> braunr: :-( + <braunr> pinotree: how do you get this value ? + <pinotree> braunr: 1000/2? :) + <braunr> ? + <braunr> why not 20000/3 ? + <antrik> pinotree: yes + <braunr> where do they come from ? + <braunr> ah ok sorry + <pinotree> braunr: 1000 is the space of each subsystem, and each rpc takes + an id + its replu + <pinotree> *reply + <braunr> right + <braunr> 500 is fine + <braunr> better than 100 + <braunr> but still, 64k is way better + <braunr> and not harder to do + <pinotree> (hey, i'm the noob in this :) ) + <antrik> 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 + <braunr> yes + <braunr> but we still have to consider this mig limit + <antrik> there are one or two odd exceptions though, with "related" + subsystems starting at ??500... + <antrik> braunr: right. it's not pretty -- but I wouldn't consider it + enough of a problem to invest major effort in changing this... + <braunr> agreed + <braunr> at least not while our interfaces don't change often + <braunr> which shouldn't happen any time soon + + <tschwinge> 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. + + <braunr> i'm only adding a cached pages count you know :) + <braunr> (well actually, this is now a vm_stats call that can replace + vm_statistics, and uses flavors similar to task_info) + <antrik> braunr: I don't think introducing "flavors" is a good idea + <braunr> i just did it the way others calls were done + <braunr> other* + <braunr> woud you prefer a larger structure with append-only upgrades ? + <antrik> I prefer introducing new calls. it avoids an unncessary layer of + indirection + <antrik> flavors are not exactly RPC-over-RPC, but definitely going down + that road... + <braunr> right + <antrik> 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 + <antrik> (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) + <braunr> antrik: all right + + +## IRC, freenode, #hurd, 2012-07-13 + + <braunr> so, should i replace old, unused mach.defs RPCs with mine, or add + them to e.g. mach4.defs ? + <antrik> braunr: hm... actually I wonder whether we shouldn't add a + gnumach.defs -- after all, it's neither old mach nor mach4 interfaces... + <braunr> true + <braunr> good idea + <braunr> i'll do just that + <braunr> hm, doesn't adding a new interface file requires some handling in + glibc ? + <youpi> simply rebuild it + <braunr> youpi: no i mean + <braunr> youpi: glibc knows about mach.defs and mach4.defs, but i guess we + should add something so that it knows about gnumach.defs + <youpi> ah + <youpi> probably, yes + <braunr> ok + <braunr> i don't understand why these files are part of the glibc headers + <pinotree> are they? + <braunr> (i mean mach_interface.h and mach4.h) + <braunr> for example + <braunr> youpi: the interface i'll add is vm_cache_statistics(task, + &cached_objects, &cached_pages) + <braunr> if it's ok i'll commit directly into the gnumach repository + <youpi> shouldn't it rather be a int array, to make it extensible? + <youpi> like other stat functions of gnumach + <braunr> antrik was against doing that + <braunr> well, he was against using flavors + <braunr> maybe we could have an extensible array yes, and require additions + at the end of the structure + + +## IRC, freenode, #hurd, 2012-07-14 + + <antrik> 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... + <antrik> having said that, I'm not sure we should stick with that :-) + <braunr> antrik: what do you think about having a larger structure with + reserved fields ? sounds a lot better than flavors, doesn't it ? + <youpi> antrik: it's in debian, yes + <braunr> grmbl, adding a new interface just for a single call is really + tedious + <braunr> i'll just add it to mach4 + <antrik> 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 + <antrik> braunr: as for reserved fields, I guess that is somewhat better + than flavors; but I can't say I exactly like the idea either... + <braunr> antrik: there is room in mach4 ;p + + +## IRC, freenode, #hurd, 2012-07-23 + + <tschwinge> I'm not sure yet whether I'm happy with adding the RPC to + mach4.defs. + <braunr> that's the only question yes + <braunr> (well, no, not only) + <braunr> as i know have a better view of what's involved, it may make sense + to create a gnumach.defs file + <braunr> tschwinge: all right i'll create a gnumach.defs file + <tschwinge> braunr: Well, if there is general agreement that this is the + way to go. + <tschwinge> 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. + <braunr> ok + + +## IRC, freenode, #hurd, 2012-07-27 + + <braunr> tschwinge: i've pushed a patch on the gnumach page_cache branch + that adds a gnumach.defs interface + <braunr> 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 |