diff options
Diffstat (limited to 'microkernel/mach/mig/structured_data.mdwn')
| -rw-r--r-- | microkernel/mach/mig/structured_data.mdwn | 119 |
1 files changed, 0 insertions, 119 deletions
diff --git a/microkernel/mach/mig/structured_data.mdwn b/microkernel/mach/mig/structured_data.mdwn deleted file mode 100644 index 1c8abe08..00000000 --- a/microkernel/mach/mig/structured_data.mdwn +++ /dev/null @@ -1,119 +0,0 @@ -[[!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 |