Re: The lamentation of proplib(3)

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

Le 28/01/2014 19:44, Mindaugas Rasiukevicius a écrit :
> Hello,

Hi,

> Many developers have been dissatisfied with proplib(3) for quite a while
> and my own dissatisfaction has reached the point where I decided to raise
> the question.  The question of replacing proplib(3) with a better library.
> There were ideas by some developers to write a new library from scratch.
> The FreeBSD project has recently developed a general purpose key-value pair
> library, which is quite similar to nvpair library in Solaris.
>
> [snip]
>
> Discuss.
>
> [1] http://lists.freebsd.org/pipermail/freebsd-arch/2013-July/014464.html
> [2] http://nxr.netbsd.org/xref/src-freebsd/lib/libnv/
> [3] http://www.freebsd.org/cgi/man.cgi?query=nv&manpath=FreeBSD+11-current

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

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.

To bring some momentum to the discussion, here are some remarks 
regarding libnv:
- I like the idea of offering an easy way to pass forth file descriptors;
- 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);
- 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).

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

Cheers,

--
Jean-Yves Migeon