Date: Tue, 28 Jan 2014 22:37:12 +0000 From: Mindaugas Rasiukevicius <rm...@netbsd.org>
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. Then what's the benefit? Switching to nvlist sounds like a step back because it doesn't support nested aggregate structures like are used in hdaudio, envsys, drvctl, &c., and in spite of the hassle to convert everything to nvlist, for compatibility's sake we'd have to keep all the proplib support for a while anyway. 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. We identify the data structures in each case, write down the schema, convert prop_dictionary_set_uint8(msg, "xyz", 32) to msg->xyz = 32, replace prop_dictionary_copyin_ioctl by protobuf_copyin_ioctl, &c. The only substantial difference between proplib (or xdr) and protobuf for this concern is whether the schema is formally written down and checked by the compiler -- the data types are all basically the same.