diff options
Diffstat (limited to 'open_issues/rpc_stub_generator.mdwn')
| -rw-r--r-- | open_issues/rpc_stub_generator.mdwn | 146 |
1 files changed, 0 insertions, 146 deletions
diff --git a/open_issues/rpc_stub_generator.mdwn b/open_issues/rpc_stub_generator.mdwn deleted file mode 100644 index d4622d67..00000000 --- a/open_issues/rpc_stub_generator.mdwn +++ /dev/null @@ -1,146 +0,0 @@ -[[!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 :) |