Re: [MIPS] Resolve compile issues with msp71xx configuration

[Florian Fainelli <florian@openwrt.org>]

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@lst.de> 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@openwrt.org
http://openwrt.org
-------------------------------