Buildroot kernel creation

[Vincent Sanders]

On Thu, Mar 09, 2006 at 05:49:02PM -0500, Rob Landley wrote:
> On Thursday 09 March 2006 8:55 am, Brent Cook wrote:
> > > The "hard" issue here is one of configuration, I have provided for
> > > either a user supplied kernel config file or for the the stable list a
> > > set of "working" configurations for each architecture, these are
> > > automatically selected for the default config. Patches for a specific
> > > kernel can also be supplied and will be automatically applied.
> >
> > Kernel configuration and patch information is also specified under these
> > device targets. Look at the example ones in SVN for an idea of how to add
> > your own. I have in my local buildroot tree a target for a generic x86 2.6
> > kernel and a few PPC targets for particular development boards. It's very
> > useful already.
> 
> I'm going to be importing my miniconfig patch into busybox in the 1.1.2 
> timeframe:
> 
> http://lwn.net/Articles/161086/
> 
> And it would be easy for uClibc to sync it from there.  There's also an 
> existing patch against linux-kernel (which still applies and I'll happily fix 
> it up if it stops applying).
> 
> The advantage of miniconfig is that it's not version dependent.  You can 
> supply the same .config to the daily snapshot and life should generally be 
> good.  (It'll die with an error message if it tries to set a config variable 
> that doesn't exist, and if a new config entry shows up that you actually 
> _need_ to set it won't set it.  But to give you an example, my UML 
> mini.config from 2.6.12 still gives me a working 2.6.16-rc4 UML vmlinux.

sorry for the delay rob, been a bit busy (oh theres a surprise ;-) 

I like this idea a lot, did this get merged into 2.6.16? Might have to
improve the miniconfig.sh perf if thats a problem?

Even so I can rejig the kernel building stuff to use it which removes
the need for a kernel config per release - much better. I am hoping to
let the machine support packages select override configs anyway, this
will adress the needs of the specific platforms like the current VIA
solution. 

In general is this approach reasonable and likely to be accepted? or
should I just go back to janitoring the kernel ;-)

-- 
Regards Vincent

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20060330/a9cef968/attachment-0002.pgp