[oe] [oe-commits] Roman I Khimov : (e)glibc-package: fix kernel version passed to qemu

[Roman I Khimov]

On Monday 18 May 2009 17:41:29 Phil Blundell wrote:
> On Mon, 2009-05-18 at 17:16 +0400, Roman I Khimov wrote:
> > On Monday 18 May 2009 16:15:33 Florian Boor wrote:
> > > Hi,
> > >
> > > GIT User account schrieb:
> > > > +		kernel_ver = bb.data.getVar("OLDEST_KERNEL", d, 1)
> > > > +		if kernel_ver is None:
> > > > +			qemu = "qemu-%s  -s 1048576" % target_arch
> > > > +		else:
> > > > +			qemu = "qemu-%s  -s 1048576 -r %s" % (target_arch, kernel_ver)
> > >
> > > are you sure this is a good idea?
> > > OLDEST_KERNEL defaults to "2.4.0", so this change is likely to break
> > > locale generation for every machine that doesn't have OLDEST_KERNEL
> > > set.
> >
> > I've not heard yet of this really breaking something. And frankly I don't
> > see any reason for that. If it actually does - feel free to shout and
> > scream of course, we'll think how to handle it better.
>
> I guess it'd break on targets where OLDEST_KERNEL isn't set (and hence
> defaults to 2.4.0) but you need a kernel newer than 2.4.0 for correct
> operation.  Presumably all ARM EABI targets fall into that latter
> category, since the TLS syscalls weren't in 2.4.x, and there might be
> some others where glibc's default setting for --enable-kernel is
> something newer than 2.4.0.

If any target device requires kernel version not less then $SMTH, it must set 
it via OLDEST_KERNEL, isn't it? So if target device doesn't specify any 
OLDEST_KERNEL, it should be OK with 2.4.0. And then if glibc is configured for 
2.4.0 it either runs on host's 2.6.smth or not (presumably runs fine), 
regardless of what it thinks about the kernel version. Or am I missing 
something?

> Incidentally, if there is a default value for OLDEST_KERNEL in
> bitbake.conf then checking the retrieved value against None seems fairly
> futile since that will never be true.

Well, things happen. We can change it to

if kernel_ver is None:
	bb.fatal("Your config is completely broken")
...

of course.