Re: sarge kernel frozen (2.4.27 and 2.6.8), and plans for post-sarge powerpc kernels.
On Mon, Apr 04, 2005 at 08:41:58AM +0200, Sven Luther wrote:
> It seems as the 2.4.27 and 2.6.8 kernels which are sarge release candidates
> are now frozen, and will be part of sarge as is, complete with all the bugs
> and problems present in them, and maybe even some security issues which will
> not be fixed in d-i, but only in testing/stable-security-updates, due to the
> longish time needed for d-i to regenerate their kernel.
> I thus announce my intentions to stop any work on those kernels, and give them
> over to the sarge security team and/or any other group of people who will be
> handling stable kernels, and focus my attention on the 2.6.11 and beyond
> I will shortly orphan those packages, but will not do an upload setting their
> maintainers to q-a, as they should be maintained by the kernel-team anyway,
> and i will not waste 24+ hours of build and bandwidth for such a small change.
> 2.4 series will be dropped post sarge, at least as far as powerpc is
> concerned, so it would be nice to have someone with interest in the remaining
> 2.4-needing subarches to show up and propose patches for 2.6. These are :
> o oldworld miboot refuses to work with 2.6 for some obscure reason, i got it
> working three times in oldebourg, but it stopped working mysteriously, and
> no positive report since then. well, miboot is non-free and currently
> non-distributable anyway, so ... Maybe the quik-from-a-floppy work will help
> us there.
> o apus kernels. There is some 2.6 work, which i will apply as a subarch
> patch to 2.6 kernels in the future, and build. I have no apus box at the
> moment though (altough i am getting a A(3|)000, but needs a powerup card for
> it still.
> o nubus kernels. Those have been added to 2.4.27 kernels, but i have got no
> report of their working or not. I heard there was willingness to work on 2.6
> nubus kernels, and i would greatly appreciate getting patches for them, and
> people with interest for testing.
> All the other cases will work fine with 2.6 kernels, and there should be no
> problem in dropping 2.4 for them. Anyone still running 2.4 kernels on powerpc
> except for the three above cases needs to think it over seriously, given the
> over one year now abandonement of upstream linuxppc developer of the 2.4
> Plans on my part for 2.6 powerpc kernels are :
> 1) abandonement of the ppc32 power3 and power4 kernels in favour of ppc64
Fine, I don't have any of these, but the rule becomes 64 bit processors
must run 64 bit kernels looks sane.
> 2) migration to a common and single kernel package for all arches.
What do you mean?
Some PPC variants are so fundamentally incompatible that a single
kernel is impossible (completely different MMU). So you mean putting
several kernel images in a single debian package?
OTOH, I'd like to see PowerPlus and MVME5100 being considered
as PreP and not specific. I don't have MVME5100 but 200 series,
the only real difference is the memory map at boot. My bootloader
actually remaps my board to look like an MVME5100 because it
gives more room to map the VME bus and nobody needs 1GB of PCI
> 3) forward porting of the above mentioned patches and inclusion in the main
> 2.6 kernels.
> 4) work on some way to move the serial console and other fbdev drivers to
> modules which are loaded as early as possible from the ramdisk, to further
> reduce the size of the kernel.
> 5) maybe start including some embedded kernels, depending on availability of
> hardware and interest.
As I said above, some embedded CPU really need different mm handling.
BookE is an abomination, and fun with the 64 bit BookE implemetations
if they come one day: they use different instruction encoding than
> Anything else needed for the powerpc post-sarge kernels, please comment here.
As said above, I might try to push upstream patches to merge PreP,
PowerPlus and MVME5100. But these are not really embedded boards,
except for memory size (I have to run in 16MB, root on NFS, no disk,
no swap, serial console only). I'm starting this week to resurrect
my old bootloader which included an x86 emulator to initialize VGA
boards by running their BIOS code.
However, I'll still compile my kernels. So I don't care very much
about what you put in the package.