[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: linux-kernel-di and powerpc-small



On Thu, Jan 22, 2004 at 09:55:40AM -0600, Steve Langasek wrote:
> On Thu, Jan 22, 2004 at 10:06:07AM +0100, Sven Luther wrote:
> > On Wed, Jan 21, 2004 at 03:46:54PM -0600, Steve Langasek wrote:
> > > On Wed, Jan 21, 2004 at 10:30:06PM +0100, Jeremie Koenig wrote:
> > > > On Wed, Jan 21, 2004 at 03:25:55PM -0500, Joey Hess wrote:
> > > > > Joey Hess wrote:
> > > > > > > +elif [ -d modules/$flavour ]; then
> > > > > > > +	modlistdir=modules/$flavour
> > > > > > 
> > > > > > Looks like this would also allow the i386 xfs kernel to look like this
> > > > > > in kernel-versions:
> 
> > > > > > i386	2.4.22	xfs	...
> 
> > > > > > And use the modules/i386-xfs directory. Steve?
> 
> > > > > Er, no it won't. I suppose the flavor could be 386-xfs though.
> 
> > > > Well, with i386 as the arch and xfs as the falvour, it'll use
> > > > modules/i386-xfs, it's the line just above my own addition.
> 
> > > The issue I've been having is getting the uname output of the
> > > kernel-image packages to match what we need to see, so that package
> > > names can be autodetected by the installer *and* we can simplify the use
> > > of flavor names.
> 
> > > Just needs a bit of attention, I'm sure.
> 
> > Why not use archdetect for this ?
> 
> How in the world would that integrate with archdetect?  It has nothing

You know, do you, that archdetect does also subarch detection ?

> at all to do with the architecture we're on, and everything to do with
> the flavor of kernel that was booted -- which is exposed through uname,
> which is already handled through kernel-installer.

And that it can easily be used by kernel-installer to choose the right
kind of flavor for your subarch/whatever. In this case, subarch could be
the processor kind used.

archdetect does some parsing of /proc/cpuinfo, and thus would be the
right place to do some processing of the /proc/cpuinfo or even uname
output, and then use the result easily afterward, either because it
would be filled in in some place in the debconf database, or because you
use it directly.

And since you were speakind of parsing the output of uname, it is only
natural that you would look at archdetect which is the right tool for
doing this. But then, if you like repeating unecessary work, you are
welcome.

Friendly,

Sven Luther



Reply to: