Re: The lamentation of proplib(3)

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

Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> I don't think there's much disagreement that proplib is wrong, but a
> proposal to replace it ought to include concrete examples of how
> current uses of proplib (or C structs or other wire data transmission
> formats) should be replaced, not just general murmuring that proplib
> sucks and there are better options.  That said...

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.

> I'm inclined to say we ought to use protocol buffers -- it supports
> C-enforceable schemas, has been widely adopted in the world, and
> satisfies more or less all your desiderata.  Parts of the wire format
> are a little wacky, but whatever.  The only trouble is we'd have to
> write a C-only implementation, but that shouldn't be too hard.

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.

-- 
Mindaugas