Re: [patch] v1.01 of /proc/.config (ready to eat)

Tigran Aivazian (tigran@aivazian.demon.co.uk)
Sat, 13 Mar 1999 16:46:21 +0000 (GMT)


Good afternoon Alan,

Thank you for your comments.

On Sat, 13 Mar 1999, Alan Cox wrote:
> Whoops. Fix that to use mktemp. Think about a user who thoughtfully
> symlinks /tmp/dconfig1_whatever to /etc/passwd then you make a kernel
> as root. mktemp easily sorts that with.
>
> tmp1=`mktemp -q /tmp/dconfig1_XXXXXX`
> tmp2=`mktemp -q /tmp/dconfig2_XXXXXX`

The above does not work as is (because there are probably some bugs with
mktemp(1) - I will get a source and start debugging it as soon as I have
time. But yes, I totally agree - I will get rid of $$-approach.

>
> > +rm -f ./kernel/dconfig_buf.c 2> /dev/null
> > +cat $tmp1 .config $tmp2 > ./kernel/dconfig_buf.c
>
> (cat $tmp1; sed -e "s/^CONFIG_//" <.config; cat $tmp2) > ./kernel/dconfig_buf.c

With this I disagree. You get rid of CONFIG_ prefix which violates "binary
identical" feature of /proc/.config = /usr/src/linux/.config.

In your next message you suggest compressing it further getting rid of
#-comments, which also seems unacceptable for the same reason.

I also disagree with Oliver Xymoron whose patch is apparently more clever
(decompressing-on-the-fly) but, imho, for such a simple thing it is better
to keep things simple.

What is more interesting is the idea I discussed with Mark Hemment last
Friday, whereby we could keep some info like .config (any amount) in the
kernel (loaded possibly from a special ELF section like __init stuff)
until some swap space is added and then those pages could be declared free
to be reused by the kernel as long our stuff is recoverable from the swap
somewhere. This is (far) more complex but this kind of complexity I like -
i.e. it may be worth it in the long term (as opposed to ad-hoc complexity
of built-in decompressor just for the humble /proc/.config thingy)

Regards,
Tigran.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/