Le Tuesday 28 April 2009 16:48:52 Shane McDonald, vous avez écrit :
> On Tue, Apr 28, 2009 at 3:20 AM, Christoph Hellwig <firstname.lastname@example.org> 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:
> 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 : email@example.com