Subject: Re: proplib changes
To: Martin Husemann <martin@duskware.de>
From: Jachym Holecek <freza@NetBSD.org>
List: tech-kern
Date: 06/11/2007 13:11:04
# Martin Husemann 2007-06-11:
> I have a few remarks:
>
> - in prop_scn.c you need to rename "struct frame" - it collides with
> kernel struct frame for most archs.
>
> - I would suggest to do the "detection" of codecs when internazlizing
> completely differnt, by making it completely internal to the codec.
> prop_codec_guess() should not know anything about the externalized
> data, do not skip whitspace before calling it and pass it a small
> buffer of data (with length) - and then call a codec provided
> probe function.
Fine with me.
> - IMHO an application should have a mean to select the codec when
> externalizing to file at runtime, if different codecs are compiled
> in.
Add a "codec" argument to _externalize_to_file(), when NULL use the
default? (This is source-incompatible change to proplib API -- I'd
prefer that over coming up with an extra function to "externalize
to file with codec".)
> - The make framework should offer different sets of codecs for the
> kernel version. Actually I will suggest that only the upcoming
> "lbd" (local binary data) codec should be available inside the
> kernel.
Just set PROPLIB_CODECS before your Makefile includes proplib's make
fragment.
> - The codec selection for the ioctl handlers should be specialized
> (i.e. if the previous point gets implemented, only "lbd" should
> be used to send ioctl data from userland to kernel).
I don't agree -- imagine you have a security bug in the default kernel
codec, you should be able to recompile the kernel with a different one
and have proplib just deal with it. For this to work, the kernel needs
to expose the list of codecs it supports -- pavel@ suggested a sysctl
with the result of prop_codec_list().
-- Jachym