GNU Hurd/ open issues/ rpc stub generator

Welcome to... ... the GNU Hurd!

Originally in context of java

  • tschwinge has to read about RMI and CORBA.

  • MIG

    • Hacking 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 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>
  https://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 :)