[[!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 i'll soon have userspace on x15, and begin system calls, and of course IPC and, since i personally have a strong disgust for IDLs, i was thinking of manually writing the RPC "stubs", with helper functions and macros what do you think of that ? IDLs could have the advantage you can generate any kind of language output out of them I'd not recommend that as ugly as IDLs are, they are useful maybe pick something with proper per-arch types and structs... :) youpi: what feature do you consider that important in an IDL ? i mean important enough to want to keep it argument matching between client and server code well obviously, but system wide protocols such as the hurd's tend not to change much we've still seen bugs about that even without changing the protocol pinotree: i agree about the language thing, but wrapping libraries also do what IDL would you then recommend ? corba! :p * pinotree runs well don't run it's actually at the top of my list :p the parser is free, and allows writing custom backends and there is already support for many languages * pinotree some time ago fixed omniorb in debian (to compile on hurd, i mean) i thought i could delay this problem some more but it's actually coming quite fast :/ i suppose it would make sense to use an already popular IDL so that support for other languages is readily available and/or people already know it hm that's secondary imo it's not that hard to learn an idl (providing it's simple, i.e. not mig-like) hm how about google protocol buffers ? wow, not bad at a first glance (never seen it) structs, optional fields, builtin strings 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 it may still be overkill for a microkernel based system otoh rpc is everything in a microkernel-based os when i say overkill, i mean too slow we still have 1024-sized string_t... yes, mig is totally hairy ... hum, c++ only, no c :/ there seems to be a C compiler, install protobuf-c-compiler v0.15, doesn't seem widely used even on 0.14 (currently in debian) it also seems to rely on contiguous messages, whereas i want scatter-gather to be used with x15 once more, i fell back on omg idl oh, there is also flick that looks interesting # IRC, freenode, #hurd, 2013-13-16 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. it probably isn't easy to port to Mach genode has an ipc generator as well which is written in a real langugage that might be worth checking out as well (note: I haven't followed the conversation at all.) i was considering using macros only too actually (i thought genode had switched to complex c++ templates) dunno I'm not up to date macros are nice, but marshalling complicated data structures is hard why implement it with just macros ?? no lexer, no parser no special special tools the first are a burden the latter is a pain 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 in the same directory, you there are headers that use it neal: cf. http://genode.org/documentation/release-notes/11.05 tschwinge: why do you recommend an IDL ? braunr: What about it? 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 ok 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. Of course, there may be other reasons for doing the latter anyway, such as performance/optimization reasons. tschwinge: well, from my pov, you're justifying the use of an idl from the definition of an rpc i'm not sure it makes much sense for me in addition, the idl becomes the "specific programming language" Well, I see it as data that has to be translated into several formats: different programming languages' stub code. you could consider c the "common" language :)