Re: [Angstrom-devel] [RFC] Get rid of adhoc machine-specific messing with [linux-handhelds-2.6] kernel packages

[Richard Purdie <rpurdie@rpsys.net>]

On Thu, 2007-01-04 at 21:03 +0200, Paul Sokolovsky wrote:
>   No. My original mail said that it lead to broken snapshots released
> for hx4700, so I RFCed its removal for it, and for another PocketPC
> machine, htcuniversal, because I'm pretty sure it can live without it.

Why were the snapshots broken? Was the problem not the total lack of a
zImage file. The fact that doesn't automatically deploy atm is actually
a bitbake trunk issue as it doesn't see any dependency to trigger that.
If those devices don't boot from a kernel within the image and need a
separate one, this would appear to be an unrelated problem as most users
are not going to extract the zImage from the image file.

> > Machine config files set information that is specific to the machine.
> > Whether of not a given machine has a sucky bootloader is a property of
> > the machine.
> 
>   Point of view. It's all just point of view. Many-many people would
> consider you crazy for wanting to install something else, handmade,
> instead of vendor-carved-in stuff. But you smile and do just that. And
> yet you tell that /home partition and bootloader are carved in stone.
> But someone else will flash them away just as easily.

I was thinking of the Zaurus case where the separate zImage is a
property of the machine at this time as there are no practical
alternatives to having a kernel outside the rootfs. The hh.org case is
admittedly less clear cut. There are documented standard methods of
using these handhelds with Linux and its machine specific whether a
separate kernel is required or not. Having this documented on a per
machine basis therefore makes more sense than hardcoding it into the
linux-*.inc files. The example would be when I try a Zaurus kernel from
hh.org. If its set in the machine files, the hh.org kernel would stand a
better chance of working.

At the end of the day its the machine maintainer's choice. You put RFC
in the subject and you got comments. You don't have to agree with them!

>   As argued, on the order of magnitude you'd have been had already.
> But err..., I don't ask Zaurus to switch. Just to let PocketPCs try it,
> and preferably, consistently. We already have user support nightmare
> just because there're few adhoc kernel install/upgrade methods for each of
> the few well supported models, and lack of any booting for the rest.

I said this reply was to both you and Koen. Koen called for one unified
approach which implies the Zaurus would have to follow your proposal. I
took issue with that for the reasons I outlined. 

>   Ok, so it's clear that Zaurus machines need to keep using existing
> methods, and those methods should not be touched. On the other hand, I
> hope I was able to argue that other machines might have other
> requirements. In this regard, I'll still need to argue to machine
> mentors of (PocketPC!) machines in question to drop
> FILES_kernel-image_MACH = "".

You've shown your position, I've not seen other PocketPC machine
maintainers comment. You won't change my view regarding the hx2000
either though ;-).

>   But anyway, I think that ROOTFS_POSTPROCESS_COMMAND +=  "remove_zimages; "
> thing is still useful. It doesn't mean that machines should switch to
> it, but it offers nice, potentially machine-independent, way to remove
> zImage file from the image. So, besides alternative way to produce
> real rootfs image without zImage which will be still possible to
> upgrade with ipkg (even if semi-manually) - and that's considered to
> be a feature, not breakage, it can be useful for other things, like
> initrd creation.

In one breath you complain about the zimage packages being a "hack at
best". You then propose hacking the generated images ;-).

Richard