Am Montag, den 22.05.2006, 10:51 -0400 schrieb Jeremy Katz: > On Sat, 2006-05-20 at 17:40 +0200, Thorsten Leemhuis wrote: > > Am Samstag, den 20.05.2006, 16:14 +0200 schrieb Axel Thimm: > > > On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz 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 > > > [...] > > > > 2) Switch the 32-bit xen kernels to require PAE. For most "current" > > > > non-laptop hardware, this is a non-issue. It does mean that xen won't > > > > work a lot of earlier PentiumM laptops > > > [...] > > > > Given these, we're looking at going with #2 and thus only having Xen > > > > work on PAE-capable hardware in the development tree. And we're > > > > planning to try to execute this switchover the beginning of next week. > > > > Note that this will not affect bare metal installs at all. > > > [...] > > > So maybe rawhide should continue with both PAE and non-PAE kernels and > > > decide on dropping the non-PAE when a release is about to be cut? > > > Otherwise you will keep out a large amount of (admittedly casual) > > > testers. > > > > Well, I was always against kernel's in Fedora Extras (and I still am, > > [mostly]). But having a Xen non-PAE kernel in Extras sounds like the > > proper solution for the above problem. But having kernels in Extras > > would only be okay for me if > > - they are build with the same spec-file as the other kernels > > - they are build on the same build system in the same step as the other > > kernels > > - they are moved to the proper Extras repo in the same moment as the > > other kernels are pushed out > > This involves huge fundamental changes to the build infrastructure that > I'm really not sure are worth doing Well, that could be nice for other aspects, too. E.g. moving some devel packages and/or not that important sub-packages/language packs/whatever to Extras sound like a good idea in my eyes in general (at least in the long term). > > There are some technical problems that probably would need to be solved > > before the above could be realized, but that should be possible if we > > really want to. > The other problem is the kernel binaries *have* to be with the > installer, too -- otherwise, you can't install the guest as everything > (HV + dom0 kernel + domU kernel) has to either be PAE or not. Mixing > and matching can't happen :( Okay, that's a good argument :-/ CU thl -- Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
