Messages in this thread | | | Date | Fri, 14 Jul 2000 12:05:24 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: Do ramdisk exec's map direct to buffer cache? |
| |
Date: Fri, 14 Jul 2000 15:22:29 +0200 (MET DST) From: Bjorn Wesen <bjorn@sparta.lu.se>
One thing that bugs me is that there seem to be a case of copy/paste in the kernel wrt compression code :) (there are more than one instance of inflate.c in the tree at least)
There is actually only one inflate.c at the moment in the Linux 2.2 tree, although it's #include'd (I know, I know) in two places. One is 16-bit code used to decompress the kernel, and discarded once the kernel is loaded, and the other is used after the kernel has come up and is in 32-bit mode, to actually decompress the ramdisk. I set things up this way, when I was hacking on the compressed ramdisk code long ago.....
In the Linux 2.4 tree, I'm not sure why Linus decided to use the PKZIP inflate routines, instead of the one in /usr/src/linux/lib/inflate.c. The one in lib/inflate.c is certainly much more compact. It *might* be that the one in fs/cramfs/inflate is faster, but I'd to see some benchmarking data before we were to conclude that definitely.
There currently isn't a particularly clean interface to inflate.c, so other users of compression probably would feel that it's easier to include their own copy of the decompression code. Making a clean interface to inflate to head this sort of thing off would be a good Linux 2.5 project....
> (They're very space limited on the amount of flash they have --- which > is not surprising if you're trying to run a complete Linux operating > system plus XFree86 on something that consumers can afford to buy.....)
Couldn't they run cramfs for all the read-only stuff and just use the current JFFS for configuration/params ?
Yes, that's probably the thing to do for now.
- Ted
- 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/
| |