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
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
[[!meta copyright="Copyright © 2011, 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]]
# IRC, freenode, #hurd, 2011-11-14
<braunr> also, what's the best way to deal with types such as
<braunr> type cache_info_t = struct[23] of integer_t;
<braunr> whereas cache_info_t contains longs, which are obviously not
integer-wide on 64-bits processors
<braunr> ?
<youpi> you mean, to port mach to 64bit?
<braunr> no, to make the RPC declaration portable
<braunr> just in case :)
<youpi> refine integer_t into something more precise
<youpi> such as size_t, off_t, etc.
<braunr> i can't use a single line then
<braunr> struct cache_info contains ints, vm_size_t, longs
<braunr> should i just use the maximum size it can get ?
<braunr> or declare two sizes depending on the word size ?
<youpi> well, I'd say three
<braunr> youpi: three ?
<youpi> the ints, the vm_size_ts, and the longs
<braunr> youpi: i don't get it
<braunr> youpi: how would i write it in mig language ?
<youpi> I don't know the mig language
<braunr> me neither :)
<youpi> but I'd say don't lie
<braunr> i just see struct[23] of smething
<braunr> the original zone_info struct includes both integer_t and
vm_size_t, and declares it as
<braunr> type zone_info_t = struct[9] of integer_t;
<braunr> in its mig defs file
<braunr> i don't have a good example to reuse
<youpi> which is lying
<braunr> yes
<braunr> which is why i was wondering if mach architects themselves
actually solved that problem :)
<braunr> "There is no way to specify the fields of a
<braunr> C structure to MIG. The size and type-desc are just used to
give the size of
<braunr> the structure.
<braunr> "
<braunr> well, this sucks :/
<braunr> well, i'll do what the rest of the code seems to do, and let it
rot until a viable solution is available
<antrik> braunr: we discussed the problem of expressing structs with MIG in
the libburn thread
<antrik> (which I still need to follow up on... [sigh])
# IRC, freenode, #hurd, 2013-06-25
<teythoon> is there a nice way to get structured data through mig that I
haven't found yet?
<teythoon> say an array of string triples
<braunr> no
<teythoon> :/
<braunr> but you shouldn't need that
<teythoon> my use case is getting info about fs translators from init to
procfs
[[hurd/translator/mtab]], [[hurd/translator/mtab/discussion]].
<teythoon> should I go for an iterator like interface instead?
<braunr> depends
<braunr> how many do you need ?
<braunr> you could go for a variable sized array too
<braunr> have a look at what already exists
<teythoon> records, maybe 10-15, depends on many fs translators are running
<braunr> a variable sized array is ok if the size isn't too big (and when i
say too big, i mean hundreds of MiB)
<braunr> an iterator is ok too if there aren't too many items
<braunr> you may want to combine both (i think that's what proc does)
<braunr> be aware that the maximum size of a message is limited to 512 MiB
<teythoon> yeah I saw the array[] of stuff stuff, but array[] of string_t
does not work, I guess b/c string_t is also an array
<teythoon> how would I send an array of variable length strings?
<braunr> i'm not sure you can
<braunr> or maybe out of line
<teythoon> somehow I expected mig to serialize arbitrary data structures,
maybe it's to old for that?
<teythoon> yeah, I read about uot of line, but that seems overkill
<braunr> it is old yes
<braunr> and not very user friendly in the end
<braunr> let me check
<teythoon> we could stuff json into mig...
<braunr> see proc_getallpids for example
<braunr> we could get rid of low level serialization altogether :p
<teythoon> hah, exactly what I was looking at
<braunr> (which is what i'll do in x15)
<braunr> type pidarray_t = array[] of pid_t;
<teythoon> but that is trivial b/c its array[] of pid_t
<braunr> and always have the server writing guide near you
<teythoon> yes
<braunr> well, make one big string and an array of lengths :p
<teythoon> thought about that and said to myself, there must be a better
way that I haven't found yet
<braunr> or one big string filled with real null-terminated c strings that
you keep parsing until you ate all input bytes
<braunr> i'm almost certain there isn't
<braunr> type string_t = c_string[1024]; /* XXX */
<teythoon> yes
<braunr> even that isn't really variable sized
<teythoon> you think anyone would object to me putting a json encoder in
/hurd/init? it is probably better than me at serializing stuff...
<braunr> try with mig anyway
<braunr> the less dependencies we have for core stuff, the simpler it is
<braunr> but i agree, mig is painful
<teythoon> would it be too hacky if I abused the argz functions? they do
exactly what I'd need
## IRC, freenode, #hurd, 2013-06-26
<teythoon> there is https://code.google.com/p/protobuf-c/ and it has a rpc
mechanism and I believe one could plug arbitrary transports easily
<braunr> please don't think about it
<braunr> we really don't want to add another layer of serialization
<braunr> it's better to completely redesign mach ipc anyway
<braunr> and there is a project for that :p
<teythoon> ive seen x15
<teythoon> just food for thought
<braunr> i've studied google protocol buffers
<braunr> and fyi, no, it wouldn't be easy to plug arbitrary transports on
top of mach
<braunr> there is a lot of knowledge about mach ports in mig
[[hurd/translator/mtab]], [[hurd/translator/mtab/discussion]].
<teythoon> but again I face the challenge of serializing a arbitrary sized
list of arbitrary sized strings
<braunr> yes
<teythoon> list of ports is easier ;) but I think its worthwile
<teythoon> so what about abusing argz* for this? you think it's too bad a
hack?
<braunr> no since it's in glibc
<teythoon> awesome :)
<braunr> but i don't remember the details well and i'm not sure the way you
use it is safe
<teythoon> yeah, I might have got the details wrong, I hadn't had the
chance to test it ;)
<braunr> about this dynamic size problem
<braunr> a "simple" varying size array should do
<braunr> you can easily put all your strings in there
<teythoon> seperated by 0?
<braunr> yes
<teythoon> that's exactly what the argz stuff does
<braunr> you'll get the size of the array anyway, and consume it until
there is no byte left
<braunr> good
<braunr> but be careful with this too
<braunr> since translators can be run by users, they somtimes can't be
trusted
<braunr> and even a translator running as root may behave badly
<braunr> so careful with parsing
<teythoon> noted
|
