tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: The lamentation of proplib(3)



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


Home | Main Index | Thread Index | Old Index