Hi Shane, Le Tuesday 28 April 2009 16:48:52 Shane McDonald, vous avez écrit : > Hello: > > On Tue, Apr 28, 2009 at 3:20 AM, Christoph Hellwig <hch@xxxxxx> wrote: > > On Mon, Apr 27, 2009 at 03:22:33PM +0200, Geert Uytterhoeven wrote: > > > He needs the definition of struct squashfs_super_block to access the > > > > .bytes_used > > > > > field. Alternatively, the offset of that field must be hardcoded. > > > > No, that whole crap needs to go. FS code has no business poking into fs > > internal structures. BTW, this whole setup is really, really gross, > > it's mtd map driver calling arch code to get base + size for mapping, > > poking into fs internal structures. I really wonder what people have > > been smoking to come up with crap like that. > > > > We should just leave it uncompilable as a sign for future generations > > not to such stupid stuff. > > So, just so I'm clear, you prefer option 4 of removing the entire > get_ramroot() code? :-) > > > If the rootfs really is in ram only (and thus you discard any changes to > > it) you can just use an initramfs which is a lot simpler than any of the > > cramfs and squashfs hacks and supported by platform-independent code. > > The rootfs is ram only with a union mount of a jffs2 filesystem to retain > changes. The target system is a resource-constrained router board, and we > were trying to keep everything as small as possible. If I remember > correctly, this code originally came over from an internal 2.4 port on an > even more resource-constrained platform; perhaps there are better options > in today's world. Initramfs is supposed to address that kind of issue, coupled to the use of mini_fo/unionfs with a jffs2 partition for instance. If you want to compress initramfs even more you may want to have a look at the patch we maintain here: https://dev.openwrt.org/browser/trunk/target/linux/brcm47xx/patches-2.6.28/500-lzma_initramfs.patch > > I will look into a better solution to this problem. In the meantime, I'm > hesitant to remove the existing code -- I think I prefer to leave it > uncompilable until that solution is found. It is likely to confuse people that may want to try get it compiling again, removing sounds like a safe bet to me. -- Best regards, Florian Fainelli Email : florian@xxxxxxxxxxx http://openwrt.org -------------------------------
