Karmic i386 flavour changes

[Tim Gardner]

Colin Watson wrote:
> On Tue, Jun 16, 2009 at 02:05:35PM -0600, Tim Gardner wrote:
>> The next upload will be an ABI bump to 2.6.30-10.11
>>
>> Pursuant to the Karmic flavours Blueprint
>> https://blueprints.launchpad.net/ubuntu/+spec/kernel-karmic-flavours
>> I've implemented the flavour changes.
>>
>> However, I have some questions about upgrading as well as CPU feature
>> detection.
>>
>> 1) Is the installer intelligent enough to detect the relevant CPU
>> features necessary to support PAE, and therefore install the correct
>> kernel version ? (Or at least complain that PAE is not supported).
> 
> Not yet, but it's easy to make it so, especially if somebody tells me
> the thing I need to look for in /proc/cpuinfo. Is it just "pae"?
> 

yes - I believe matching on 'pae' is sufficient.

> The trickier issue is that in order for this to be a useful choice, we
> now need to cram two kernels onto our CDs, otherwise either (a) non-PAE
> users are just screwed or (b) PAE users don't get any advantage unless
> they install via netboot or a DVD. Has this been discussed? I don't see
> a record of it in the specification.
> 

If space is limited, then I think it's enough to carry just the PAE 
kernel on the Live and Alternate CDs (but refuse to install or upgrade a 
non-PAE capable CPU). I believe the use cases for non-PAE capable CPUs 
are few, e.g., Geode and VIA C3 type CPUs in embedded or headless 
motherboards. It should be enough to provide a netboot or DVD install 
solution in that case.

> BTW,
> http://www.mail-archive.com/fedora-kernel-list@redhat.com/msg01682.html
> is what I was referring to obliquely at UDS. Maybe somebody should poke
> Kyle and find out if he has the patch set to hand.
> 

In an earlier thread in that conversation Kyle essentially echoes my 
opinion wherein he wonders how many non-PAE use cases there are. I'm not 
very interested in carrying a patchset to runtime detect and implement 
the second level of page tables necessary to dynamically support PAE. I 
know that most of the code is already there protected by ifdef's, but in 
my opinion the number of use cases simply doesn't warrant the effort.

rtg
-- 
Tim Gardner tim.gardner at canonical.com