linux-mips
[Top] [All Lists]

Re: [MIPS] Resolve compile issues with msp71xx configuration

To: Florian Fainelli <florian@openwrt.org>
Subject: Re: [MIPS] Resolve compile issues with msp71xx configuration
From: Shane McDonald <mcdonald.shane@gmail.com>
Date: Tue, 28 Apr 2009 09:55:54 -0600
Cc: Christoph Hellwig <hch@lst.de>, 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=ygRXOrYN/gP0iHTARpLlj13G/ja51lidxBibyUDlf3w=; b=IJ2ZOjUaWAxJnqgzfYpKr9N2Y/Ib1kFeeb9Jorvh8gLvmVdnIasKKywIvtKHb5HBbS Dap6F2GLPNCdpT2UJoBMlqsIne6XCmbNcPZAhyH0XqQibi4XOQzSyzUxqZlU/U2U0wss Oo7mJU3Her/34n0gv9U4FPuKwkySB5U8J9LPY=
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=RzMv+8GAra/qgwBVR0vHlMSaOBctF1EM9+9MGn0n9sz3DsY8b2qiCqB28yZ6rl4BHC Ici5BXO9FPMHgyleuans+r1kxI1T2wu9fK3B6Gu4X1qLw279Iq5LgjB/ibPAFwk+2HN9 hP6CUwO3tbTQDROz0kwesTP9MSkpt8IZIPkmo=
In-reply-to: <200904281705.54721.florian@openwrt.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <E1LyQQX-00047N-6E@localhost> <20090428092005.GA2408@lst.de> <b2b2f2320904280748q3a45ecf6r46dcb536877663c@mail.gmail.com> <200904281705.54721.florian@openwrt.org>
Sender: linux-mips-bounce@linux-mips.org
Hello Florian:

On Tue, Apr 28, 2009 at 9:05 AM, Florian Fainelli <florian@openwrt.org> wrote:
Hi Shane,

Le Tuesday 28 April 2009 16:48:52 Shane McDonald, vous avez écrit :
>
> On Tue, Apr 28, 2009 at 3:20 AM, Christoph Hellwig <hch@lst.de> wrote:
> > 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
 
 
Excellent -- it looks like I have a good path forward!  Thanks for the pointer.
 
> 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.
 
Based on your and Ralf's request, I'll prepare a patch tonight to get this compiling again.
 
Shane
<Prev in Thread] Current Thread [Next in Thread>