linux-mips
[Top] [All Lists]

Re: [MIPS] Resolve compile issues with msp71xx configuration

To: Christoph Hellwig <hch@lst.de>
Subject: Re: [MIPS] Resolve compile issues with msp71xx configuration
From: Shane McDonald <mcdonald.shane@gmail.com>
Date: Tue, 28 Apr 2009 08:48:52 -0600
Cc: Geert Uytterhoeven <geert@linux-m68k.org>, Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=l6mN8KoGosSZmYiFyRkVnCjwqOL9aV0U8+zmjmN29X4=; b=OMkfc5J/A66CfjNP0xlle2hRkbgmMpciOQH6tTkv5it1sq9ppUQMA+tpS/iPiqnKK8 7WObL9WDUUQG266CUhlekxaCEcqN+/Rqutzikvmf54Maj8YehhPm5/DVA+oQmckoczlN 81Us+YrFT9sroSDB39GgcLZkV3Q7jaCZKkF1k=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nbFN2JDs0k6wK6a/nxNO3a85ckB3UO0jMf613ZG3RI8JBATT1ZTrNdmgLPIOA1mAUo I0JuxlNHS2d0UVruHGMgOYvwE5hdyn9qXiuww7RkwQZUEAXOwGY/2RBYrtwA425Y0kTn Cqg00DE3qRGIMIf+JjJTd3jy4s4Iue+gd8FF8=
In-reply-to: <20090428092005.GA2408@lst.de>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <E1LyQQX-00047N-6E@localhost> <20090427130952.GA30817@linux-mips.org> <10f740e80904270622u730ba067g660257847dc526de@mail.gmail.com> <20090428092005.GA2408@lst.de>
Sender: linux-mips-bounce@linux-mips.org
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.
 
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
<Prev in Thread] Current Thread [Next in Thread>