diff options
Diffstat (limited to 'open_issues/mig_portable_rpc_declarations.mdwn')
| -rw-r--r-- | open_issues/mig_portable_rpc_declarations.mdwn | 111 |
1 files changed, 110 insertions, 1 deletions
diff --git a/open_issues/mig_portable_rpc_declarations.mdwn b/open_issues/mig_portable_rpc_declarations.mdwn index 084d7454..ecfa06ae 100644 --- a/open_issues/mig_portable_rpc_declarations.mdwn +++ b/open_issues/mig_portable_rpc_declarations.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!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 @@ -56,3 +56,112 @@ License|/fdl]]."]]"""]] <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 |