Re: The lamentation of proplib(3)

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

Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost> wrote:
> I agree on the ugliness/impracticality of proplib(3), and got myself 
> bitten twice. So I am all for alternatives.
> 
> Firstly, one clarification: is your intent to /replace/ proplib(3) or to 
> /provide/ a simpler interchange format for userland/kernel, and keep 
> proplib(3) in its place for historical purposes?
> 
> Replacement ain't that easy, proplib(3) is used throughout the tree in 
> multiple places, and they are parts where a full-scale replacement is 
> not trivial (quotas for one).

The long term objective would be to replace and eliminate proplib(3) from
the tree.  The short to medium term objective is to provide an alternative,
start using it and gradually convert proplib uses.  Yes, we will need to
add compatibility code for the Property List format, which is going to be
very depressive.

Nobody said it is going to be a trivial task.  The riddance is not going
to happen any time soon.  We just have to start somewhere.

> Secondly, they are tons of interchange formats out there. libnv is one 
> more, with its original author stating that it is not really meant as a 
> replacement for XML/JSON.

The library provides an interface to pack and transport the data.  As far
as the caller is concerned, it does not matter what serialisation format
it uses.  There is no reason why it could not use JSON or <insert your
favourite format>.  I think the default format should be binary, though.

> - the error handling is weak IMHO; given the potential large use of such 
> a library, it should support richer semantics than a blunt errno 
> (something equivalent to a gai_strerror(3) maybe);

Why?  Most of the use cases in our tree do not really need granularity on
errors - you either retrieve (or construct) the whole thing or you fail.
That is why accumulated error is so useful, it would simplify many cases
in our tree.  If we add support for schemas, then the schema validation
code is the routine which could be more informative.

> - it does not seem to offer a way to serialize kernel shared structures 
> easily. It is particularly convenient to have because it avoids 
> user/kernel roundtrips when you want to expose kernel structures without 
> syscall overhead (instead of playing with ioctl or low-level mmap).

Can you be more specific?

> Why did they consider rolling out libnv when there are alternatives like 
> protocol buffers or thrift? Granted, those tools are meant for higher 
> level langages and RPCs, but if NetBSD managed to use XML in kernel, I 
> suppose those would fit too...

Google protocol buffers and Apache Thrift work in a different way - they
generate the code for you based on a provided schema, to conveniently and
efficiently implement RPCs.  It is XDR "on steroids" - 1980s technology
refurbished for the modern day (e.g. including some schema versioning,
compression, a bunch of tools, etc).  The libraries we are talking about
merely perform dynamic data serialisation at run-time.  Both approaches
have their merits, but for all intents and purposes we are not going to
shift to a different approach, or rather paradigm, at this point.

Also, proplib uses horrible XML-like looking format, but not XML.  There
is a subtle difference here.

-- 
Mindaugas