Re: The lamentation of proplib(3)

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Tue, 28 Jan 2014 22:37:12 +0000
   From: Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>

   If you have taken a look at the manual page and the examples section,
   the API is straightforward.  I do not think that we all need to hold our
   hands and learn together that prop_dictionary_create() would be replaced
   with nvlist_create(), prop_dictionary_set_uint64() with nvlist_add_numer()
   and so on.  The idea is to move to a different (just sane) implementation,
   not a different concept.

Then what's the benefit?  Switching to nvlist sounds like a step back
because it doesn't support nested aggregate structures like are used
in hdaudio, envsys, drvctl, &c., and in spite of the hassle to convert
everything to nvlist, for compatibility's sake we'd have to keep all
the proplib support for a while anyway.

   I am not against such approach per se, but our needs (given the cases in
   NetBSD tree) are quite lower than what Protocol Buffers were designed for.
   Most use cases in our tree are for data transfers between the user and the
   kernel (just as a more convenient alternative to ioctls + structs and kmem
   grovellers).  How do you imagine conversion of the existing proplib uses?
   I doubt it is a realistic choice for this purpose.  In time, XDR was not
   adopted for this purpose either.

We identify the data structures in each case, write down the schema,
convert prop_dictionary_set_uint8(msg, "xyz", 32) to msg->xyz = 32,
replace prop_dictionary_copyin_ioctl by protobuf_copyin_ioctl, &c.
The only substantial difference between proplib (or xdr) and protobuf
for this concern is whether the schema is formally written down and
checked by the compiler -- the data types are all basically the same.