Re: The lamentation of proplib(3)

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
>>    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?

In this case, the proplib implementation has such major deficiencies that
replacing it itself is a virtue.  Fixing is not the case here, as it would
basically mean rewriting.

> 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.

It does support nesting, see nvlist_add_nvlist().

>>   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.

Which is what XDR does, except it is quite dated by now.  My point was
that the community did not really adapt such approach for the purpose of
user-kernel communication and I am bit sceptic that it will, especially
when it is even more work than migrating to libnv(3).  However, if you
want to prototype a lightweight C implementation of Protocol Buffers and
propose it here for a discussion - why not.  I would prototype XDR 2.0,
but it is just a matter of taste. :)

-- 
Mindaugas