[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 :
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.
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
- 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...
Main Index |
Thread Index |