[Top] [All Lists]

Re: [MIPS] Resolve compile issues with msp71xx configuration

To: Shane McDonald <>
Subject: Re: [MIPS] Resolve compile issues with msp71xx configuration
From: Florian Fainelli <>
Date: Tue, 28 Apr 2009 17:05:53 +0200
Cc: Christoph Hellwig <>, Geert Uytterhoeven <>, Ralf Baechle <>,
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=p75UIDRrPv7eO9Z2TdOccwKnyuw/v5r/8YjrE9BP3x0=; b=jw7UP02aNneuFJL+I01g6J91Mau9wUQXEtvnbwOQKzju/yhOJpcMWbIYU+tjWdxA08 szwfPZQXtAms9KQtjwdQnc6h1Rl69izDts5E+U2dgBIWoXLMN0BmAGC2LSHIvY8EwYOT 0l5tJz1Zi39lU72ErnlyA1rKoWPck7kRC14KY=
Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=Yn18ZsY7JUDSIDHHvAih2lTX/5gsB8huqbe4MsxTl4e3ueF48u4ba17nwAc+gkOsPH xoYIhX6/8b0D+PNTBB3+t9OI/OgC0EU6XEp+SzTHprd7Aof1ad4hEmzfNH5VUDGtzQ10 DZv1+CU4LCRYBJhhkCYDVBstTbeoC2L0yMXgg=
In-reply-to: <>
Original-recipient: rfc822;
References: <E1LyQQX-00047N-6E@localhost> <> <>
User-agent: KMail/1.9.9
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 <> 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 :

<Prev in Thread] Current Thread [Next in Thread>