From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- .../rpc_stub_generator.mdwn | 146 +++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 service_solahart_jakarta_selatan__082122541663/rpc_stub_generator.mdwn (limited to 'service_solahart_jakarta_selatan__082122541663/rpc_stub_generator.mdwn') diff --git a/service_solahart_jakarta_selatan__082122541663/rpc_stub_generator.mdwn b/service_solahart_jakarta_selatan__082122541663/rpc_stub_generator.mdwn new file mode 100644 index 00000000..d4622d67 --- /dev/null +++ b/service_solahart_jakarta_selatan__082122541663/rpc_stub_generator.mdwn @@ -0,0 +1,146 @@ +[[!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 :) -- cgit v1.2.3