linux-mips
[Top] [All Lists]

Re: [Linux-mips-kernel]PATCH

To: Geoffrey Espin <espin@idiom.com>
Subject: Re: [Linux-mips-kernel]PATCH
From: Pete Popov <ppopov@mvista.com>
Date: 19 Oct 2001 11:13:49 -0700
Cc: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com
In-reply-to: <1003471921.1184.4.camel@adsl.pacbell.net>; from Pete Popov on Thu, Oct 18, 2001 at 11:12:01PM -0700
In-reply-to: <20011019102749.B36916@idiom.com>
References: <3BC24525.8030201@mvista.com> <20011016115059.A29701@idiom.com> <1003471921.1184.4.camel@adsl.pacbell.net>
References: <3BC24525.8030201@mvista.com> <20011016115059.A29701@idiom.com> <1003471921.1184.4.camel@adsl.pacbell.net> <20011019102749.B36916@idiom.com>
Sender: owner-linux-mips@oss.sgi.com
On Fri, 2001-10-19 at 10:27, Geoffrey Espin wrote:
> Pete,
> 
> > I ported the code from arch/ppc/boot, so if you like that scheme, what 
> > is it that you don't like about the patch I sent?  The directory
> > structure is the same as arch/ppc/boot, and the generic code is the same
> > as well.
> 
> I see that PPC now has some of the silly utils where $(shell
> objdump ...) in the Makefile would be a lot tighter.  

Are you talking about the utils in boot/utils?  I suppose you can get
rid of those and put everything in the makefile, but I'm not sure it
would be cleaner.

> Other
> superficial but better ways like subdir-$(CONFIG_<board>) are
> not used (instead ifdef CONFIG_NEC_PB100 $MAKE -- ugh!).  Not
> sure why using CFLAGS/LOADADDR/.. from arch/mips/Makefile is not
> done either... dup'ing this is bad.  

Yes, it is. I tried inheriting LOADADDR from arch/mips/Makefile, but it
didn't work and I didn't want to spend more time on it. I figured we can
clean that up later.

> Use "override CFLAGS" if it
> needs to be re-constructed from GCCFLAGS,CPPFLAGS...
> 
> Apologies for playing "armchair coder".  I'll try to create Korva
> version... but mine does it without benefit of a separate loader
> (standalone vrboot style)... which might be a useful standard
> build option.
> 
> Seems to me this is way more important than vrxx stuff... which
> is already done and over... compression/initrd is in its infancy.

Certainly on embedded mips boards it is. It seems like every other arch
already has compression and initrd support.  What I was shooting for
with that ppc patch is a reasonable start at having compression / kernel
loader support.  

Pete


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