IRC.

1 files changed, 112 insertions, 1 deletions

diff --git a/open_issues/mig_portable_rpc_declarations.mdwn b/open_issues/mig_portable_rpc_declarations.mdwn
index 084d7454..91838f60 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,114 @@ 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
+
+[[community/gsoc/project_ideas/mtab]],
+[[community/gsoc/project_ideas/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
+
+[[community/gsoc/project_ideas/mtab]],
+[[community/gsoc/project_ideas/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