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