On Sat, 13 Mar 1999, Alan Cox wrote:
> > 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.
>
> Not when it costs no kernel space. (ok 3 bytes of space for .gz on the end
> of the .config) to save 2 pages of memory. Oliver's approach is the best
> so far
Your above comment on 3 bytes gives me expression that I must have
expressed my thoughts very poorly and thus was completely misunderstood.
Therefore I ask your permission to allow me to explain myself clearer.
I can see the following alternatives:
1. Appending stuff to zImage.
This is bad because being not .config-specific forces a (user-space)
reader to validate info. An app has to seek and find it first too.
2. /proc/.config.gz
This is bad because a reader must decompress it himself. That is *every*
reader (unless he uses some shared library to do it transparently).
3. decompress-on-the-fly /proc/.config (not the same as /proc/.config.gz!)
This is the case where the kernel presents data in such a way that the
user can lseek()/read() at any position without knowing that internally it
is actually compressed. This (and not .config.gz) is what I meant by
decompress-on-the-fly approach and believed it to be wrong because I have
not seen a piece of code which can provide such elegant abstraction for a
10K buffer which itself (including data) would fit in 10K.
4. plain text /proc/.config (as per my patches)
This is bad because we unconditionally use up a couple of pages of
physical memory. But we don't do much else other than provide user space
with data correctly positioned for them to lseek() and get at it.
As we see, everything is bad, in which case, we choose the least evil,
which is 4. :)
Am I still wrong?
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/