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
|
[[!meta copyright="Copyright © 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, 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
[[community/gsoc/project_ideas/mtab]].
<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
[[community/gsoc/project_ideas/mtab]].
<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
|
