Embedded stage - why kernels and headers 2.4 not 2.6?
 

I would like to compile small system (kernel, busybox, uclibs, some more
little stuff) and wanted to use embedded stage from experimental gentoo
stages. And

I'm curious why in /etc/make.profile/packages in embedded stage I can find:

<sys-kernel/linux-headers-2.5
<sys-kernel/gentoo-sources-2.5
<sys-kernel/hardened-sources-2.5
<sys-kernel/vanilla-sources-2.5
<virtual/linux-sources-2.5

<virtual/pcmcia-2.5

Why all kernels below 2.5 are ok and others are masked? I would really like to
compile against 2.6, so I'm trying to change that. Is it only somewhat
experimental or am I going to break-a-leg?

Thanks,

Janusz
--
gentoo-embedded@gentoo.org mailing list

Embedded stage - why kernels and headers 2.4 not 2.6?
 

> Why all kernels below 2.5 are ok and others are masked?

You look, you find:

"unlike the default-linux and standard hardened profiles we felt it
unneeded to force a 2.6 sub profile or we did not wish to have to
maintain twice as many profiles. Also all the last releases
were for all 2.4.x kernels. upgrading to 2.6.x is easy as -pie
however.. Just update headers, uclibc, kernel and modules.
Then go update everything else where needed. "

by Ned Ludd-2

Janusz
--
gentoo-embedded@gentoo.org mailing list

Embedded stage - why kernels and headers 2.4 not 2.6?
 

On Wednesday 12 December 2007, Janusz Syrytczyk wrote:
> > Why all kernels below 2.5 are ok and others are masked?
>
> You look, you find:
>
> "unlike the default-linux and standard hardened profiles we felt it
> unneeded to force a 2.6 sub profile or we did not wish to have to
> maintain twice as many profiles. Also all the last releases
> were for all 2.4.x kernels. upgrading to 2.6.x is easy as -pie
> however.. Just update headers, uclibc, kernel and modules.
> Then go update everything else where needed. "

the other part is that unlike glibc, uClibc cannot (currently) build against
2.6 headers and run on 2.4 kernels. uClibc will use whatever features are
available. so if 2.6 has a newer way of doing something (like mount), then
uClibc will use whatever your headers say. but try to do it on an older
system where the functionality is not available and you get runtime failures.
glibc on the other hand builds support for every call ands will fallback to
older and older methods until something works.
-mike