From 51c95fc11727532e3b0d98c8470a6b60907a0680 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 8 Jan 2013 21:31:31 +0100 Subject: IRC. --- open_issues/rpc_stub_generator.mdwn | 99 +++++++++++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 open_issues/rpc_stub_generator.mdwn (limited to 'open_issues/rpc_stub_generator.mdwn') diff --git a/open_issues/rpc_stub_generator.mdwn b/open_issues/rpc_stub_generator.mdwn new file mode 100644 index 00000000..05eb53b8 --- /dev/null +++ b/open_issues/rpc_stub_generator.mdwn @@ -0,0 +1,99 @@ +[[!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]] + + +# 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 -- cgit v1.2.3