From 9933cec0a18ae2a3d752f269d1bb12c19f51199d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 21 Jul 2013 15:35:02 -0400 Subject: IRC. --- microkernel/mach/mig/structured_data.mdwn | 119 ++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 microkernel/mach/mig/structured_data.mdwn (limited to 'microkernel/mach/mig') diff --git a/microkernel/mach/mig/structured_data.mdwn b/microkernel/mach/mig/structured_data.mdwn new file mode 100644 index 00000000..1c8abe08 --- /dev/null +++ b/microkernel/mach/mig/structured_data.mdwn @@ -0,0 +1,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 + + is there a nice way to get structured data through mig that I + haven't found yet? + say an array of string triples + no + :/ + but you shouldn't need that + my use case is getting info about fs translators from init to + procfs + +[[community/gsoc/project_ideas/mtab]]. + + should I go for an iterator like interface instead? + depends + how many do you need ? + you could go for a variable sized array too + have a look at what already exists + records, maybe 10-15, depends on many fs translators are running + a variable sized array is ok if the size isn't too big (and when i + say too big, i mean hundreds of MiB) + an iterator is ok too if there aren't too many items + you may want to combine both (i think that's what proc does) + be aware that the maximum size of a message is limited to 512 MiB + 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 + how would I send an array of variable length strings? + i'm not sure you can + or maybe out of line + somehow I expected mig to serialize arbitrary data structures, + maybe it's to old for that? + yeah, I read about uot of line, but that seems overkill + it is old yes + and not very user friendly in the end + let me check + we could stuff json into mig... + see proc_getallpids for example + we could get rid of low level serialization altogether :p + hah, exactly what I was looking at + (which is what i'll do in x15) + type pidarray_t = array[] of pid_t; + but that is trivial b/c its array[] of pid_t + and always have the server writing guide near you + yes + well, make one big string and an array of lengths :p + thought about that and said to myself, there must be a better + way that I haven't found yet + or one big string filled with real null-terminated c strings that + you keep parsing until you ate all input bytes + i'm almost certain there isn't + type string_t = c_string[1024]; /* XXX */ + yes + even that isn't really variable sized + you think anyone would object to me putting a json encoder in + /hurd/init? it is probably better than me at serializing stuff... + try with mig anyway + the less dependencies we have for core stuff, the simpler it is + but i agree, mig is painful + would it be too hacky if I abused the argz functions? they do + exactly what I'd need + + +## IRC, freenode, #hurd, 2013-06-26 + + there is https://code.google.com/p/protobuf-c/ and it has a rpc + mechanism and I believe one could plug arbitrary transports easily + please don't think about it + we really don't want to add another layer of serialization + it's better to completely redesign mach ipc anyway + and there is a project for that :p + ive seen x15 + just food for thought + i've studied google protocol buffers + and fyi, no, it wouldn't be easy to plug arbitrary transports on + top of mach + there is a lot of knowledge about mach ports in mig + +[[community/gsoc/project_ideas/mtab]]. + + but again I face the challenge of serializing a arbitrary sized + list of arbitrary sized strings + yes + list of ports is easier ;) but I think its worthwile + so what about abusing argz* for this? you think it's too bad a + hack? + no since it's in glibc + awesome :) + but i don't remember the details well and i'm not sure the way you + use it is safe + yeah, I might have got the details wrong, I hadn't had the + chance to test it ;) + + about this dynamic size problem + a "simple" varying size array should do + you can easily put all your strings in there + seperated by 0? + yes + that's exactly what the argz stuff does + you'll get the size of the array anyway, and consume it until + there is no byte left + good + but be careful with this too + since translators can be run by users, they somtimes can't be + trusted + and even a translator running as root may behave badly + so careful with parsing + noted -- cgit v1.2.3