1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
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
<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 :)
|
