On Thursday 18 May 2006 03:00pm, Jeremy Katz wrote: > On Thu, 2006-05-18 at 16:52 -0400, James Morris wrote: > > Jeremy wrote: > > > As we move forward with Xen enablement, there's a desire for > > > being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The > > > options for handling this are > > > 1) Another kernel. This is bad due to > > > a) we're running out of CD space already > > > b) keeping things matched up between the HV and the guest kernels > > > c) migration is worlds of pain with two types of kernels > > > > What about leaving the non-pae kernel out of the core distro and > > distributing it online only via extras? > > You have to have it in the base set because the installation tree has to > include PAE install bits if you're going to support PAE hosts. HV + > dom0 kernel + domU kernel have to match here. > > Ignoring that, you're saying that you want to maintain a second kernel > package in sync with security errata? It's insanity. Also, it will > break down a lot in terms of allowing kernel module packages, etc. What if the modules were somehow packaged separate from the kernel images? The image packages could depend on the correct kernel modules package. Obviously, this will require a little fine tuning of kernel package names and probably making 'uname -r' report the same thing under the Xen and non-Xen kernels. Or, the kernel image packages could create a symlink with the "right" name in /lib/modules/ to the shared modules directory. Could that trim things down enough to make it sensible to carry PAE and non-PAE kernels in Core? -- Lamont R. Peterson <lamont@xxxxxxxxxxxx> Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409
Attachment:
pgp7pRQvKtNKA.pgp
Description: PGP signature
