[[!meta copyright="Copyright © 2012, 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_mig]]


# Originally in context of [[user/jkoenig/java]]

  * [[tschwinge]] has to read about RMI and CORBA.

  * MIG

      * Hacking [[microkernel/mach/MIG]] shouldn't be too difficult.

          * (Unless you want to make MIG's own code (that is, not the generated
            code, but MIG itself) look a bit more nice, too.)  ;-)

      * There are also alternatives to MIG.  If there is interest, the following
        could be considered:

          * FLICK ([[!GNU_Savannah_task 5723]]).  [[tschwinge]] has no idea yet if
            there would be any benefits over MIG, like better modularity (for the
            backends)?  If we feel like it, we could spend a little bit of time on
            this.

          * For [[microkernel/Viengoos]], Neal has written a RPC stub generator
            entirely in C Preprocessor macros.  While this is obviously not
            directly applicable, perhaps we can get some ideas from it.

          * Anything else that would be worth having a look at?  (What are other
            microkernels using?)


# IRC, freenode, #hurd, 2012-12-27

    <braunr> i'll soon have userspace on x15, and begin system calls, and of
      course IPC
    <braunr> and, since i personally have a strong disgust for IDLs, i was
      thinking of manually writing the RPC "stubs", with helper functions and
      macros
    <braunr> what do you think of that ?
    <pinotree> IDLs could have the advantage you can generate any kind of
      language output out of them
    <youpi> I'd not recommend that
    <youpi> as ugly as IDLs are, they are useful
    <pinotree> maybe pick something with proper per-arch types and
      structs... :)
    <braunr> youpi: what feature do you consider that important in an IDL ?
    <braunr> i mean important enough to want to keep it
    <youpi> argument matching between client and server code
    <braunr> well obviously, but system wide protocols such as the hurd's tend
      not to change much
    <youpi> we've still seen bugs about that
    <youpi> even without changing the protocol
    <braunr> pinotree: i agree about the language thing, but wrapping libraries
      also do
    <braunr> what IDL would you then recommend ?
    <pinotree> corba! :p
    * pinotree runs
    <braunr> well don't run
    <braunr> it's actually at the top of my list :p
    <braunr> the parser is free, and allows writing custom backends
    <braunr> and there is already support for many languages
    * pinotree some time ago fixed omniorb in debian
    <pinotree> (to compile on hurd, i mean)
    <braunr> i thought i could delay this problem some more but it's actually
      coming quite fast :/
    <braunr> i suppose it would make sense to use an already popular IDL so
      that support for other languages is readily available
    <pinotree> and/or people already know it
    <braunr> hm that's secondary imo
    <braunr> it's not that hard to learn an idl (providing it's simple,
      i.e. not mig-like)
    <braunr> hm how about google protocol buffers ?
    <pinotree> wow, not bad at a first glance (never seen it)
    <pinotree> structs, optional fields, builtin strings
    <braunr> the nice thing about it is that it focuses on serialization most,
      but has basic rpc support that allows using whatever communication
      channel you want
    <braunr> it may still be overkill for a microkernel based system
    <pinotree> otoh rpc is everything in a microkernel-based os
    <braunr> when i say overkill, i mean too slow
    <pinotree> we still have 1024-sized string_t...
    <braunr> yes, mig is totally hairy ...
    <braunr> hum, c++ only, no c :/
    <pinotree> there seems to be a C compiler, install protobuf-c-compiler
    <braunr> v0.15, doesn't seem widely used
    <pinotree> even on 0.14 (currently in debian)
    <braunr> it also seems to rely on contiguous messages, whereas i want
      scatter-gather to be used with x15
    <braunr> once more, i fell back on omg idl
    <braunr> oh, there is also flick that looks interesting


# IRC, freenode, #hurd, 2013-13-16

    <tschwinge> braunr: By the way, regarding your recent IDL considerations
      (and I too suggest using some kind of RPC generator basone on whichever
      IDL) -- are you aware that for Viengoos, Neal has written a RPC stub
      generator entirely in C Preprocessor macros?  No idea whather that's
      suitable for your case, but may be worth having a look at.
    <neal> it probably isn't easy to port to Mach
    <neal> genode has an ipc generator as well
    <neal> which is written in a real langugage
    <neal> that might be worth checking out as well
    <neal> (note: I haven't followed the conversation at all.)
    <braunr> i was considering using macros only too actually
    <braunr> (i thought genode had switched to complex c++ templates)
    <neal> dunno
    <neal> I'm not up to date
    <neal> macros are nice, but marshalling complicated data structures is hard
    <sekon_> why implement it with just macros ??
    <neal> no lexer, no parser
    <neal> no special special tools
    <neal> the first are a burden
    <neal> the latter is a pain
    <neal>
      http://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git;a=blob;f=libviengoos/viengoos/rpc.h;h=721768358a0299637fb79f226aea6a304571da85;hb=refs/heads/viengoos-on-bare-metal
    <neal> in the same directory, you there are headers that use it
    <braunr> neal: cf. http://genode.org/documentation/release-notes/11.05
    <braunr> tschwinge: why do you recommend an IDL ?
    <neal> braunr: What about it?
    <braunr> neal: it shows the difference between the earlier ipc/rpc
      interface, and the new one based only on templates and dynamic
      marshalling using c++ streams
    <neal> ok
    <tschwinge> braunr: In my book, the definition of RPC interfaces is just
      "data" in the sense that it describes data structures (exchanged
      messages) and as such should be expressed as data (by means of an IDL),
      instead of directly codifying it in a specific programming language.
    <tschwinge> Of course, there may be other reasons for doing the latter
      anyway, such as performance/optimization reasons.
    <braunr> tschwinge: well, from my pov, you're justifying the use of an idl
      from the definition of an rpc
    <braunr> i'm not sure it makes much sense for me
    <braunr> in addition, the idl becomes the "specific programming language"
    <tschwinge> Well, I see it as data that has to be translated into several
      formats: different programming languages' stub code.
    <braunr> you could consider c the "common" language :)