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:No, that whole crap needs to go. FS code has no business poking into fs
> He needs the definition of struct squashfs_super_block to access the .bytes_used
> field. Alternatively, the offset of that field must be hardcoded.
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.
> 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.
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.
Shane
