On Wed, Mar 5, 2014 at 6:58 PM, drago01 <drago01@xxxxxxxxx> wrote: > On Wed, Mar 5, 2014 at 8:48 AM, Sandro "red" Mathys > <red@xxxxxxxxxxxxxxxxx> wrote: >> Heads-up: I've taken ownership over the Cloud SIG's planned >> "Cloud-Friendly Kernel Packaging" (aka "Modular Kernel Packaging for >> Cloud") Change [0]. >> >> (Sorry for cross-posting this on the kernel and cloud lists, but both >> the kernel team and the cloud SIG need to be involved in this >> discussion). >> >> Obviously, we wish for modular kernel packaging and Josh Boyer already >> reached out to the cloud SIG in this regard a while ago when we didn't >> really know what we want yet [1]. We do now know that somewhat better >> [2] but details could still require additional discussion. Our >> motivation is to save space, time and bandwidth (the latter two >> referring to required updates) as in the cloud, all three equal to >> costs. And yes, we also target things other than the kernel to save >> space. >> >> So, in our case hardware drivers are rather unnecessary and the kernel >> experts might know other ways to shrink the footprint for our limited >> use cases. The kernel we require supports all primary architectures >> (i686 and x86_64 right now, ARM likely later) and is able to run on a >> hypervisor (primarily KVM and Xen but support for ESXi and Hyper-V are >> becoming crucial in private clouds). Only. No bare-metal. We also >> require support for Linux Containers (LXC) to enable the use of >> Docker. >> >> Now, I heard some people screaming when I said HW drivers are >> unnecessary. Some people will want to make use of PCI passthrough and >> while I think we don't want to ship the necessary modules by default, >> they should be easily installable through a separate package. If some >> more granularity is acceptable (and makes sense), I think one package >> for SRIOV NICs, one for graphic cards (to enable mathematical >> computation stuff) and one for everything else PCI passthrough (plus >> one for all other HW drivers for the non-cloud products) would be >> totally nice. >> >> What does everybody think about this? Can it be done? How is it best >> done? What's the timeframe (we'd really like to see this implemented >> in F21 Beta but obviously the earlier modular kernels can be tested, >> the better)? Do you require additional input? >> >> Please try to keep the discussion as simple as possible (in terms of >> us non-kernel hackers should be able to follow it). Just like Josh >> requested when reaching out to us: "Explain it to me like I'm a >> child." > > Some drivers are built inside the kernel (for various reasons) so if > we keep them in they can't really be modular. If there are reasons they are built-in (and I think currently nothing is being built-in without good reasons), that should not be changed. Only just talking about what is currently a module (or otherwise a separate file - if applicable). The vmlinuz should be kept as-is and stay the same for all products (server, workstation and cloud). > If we are going down this route (ex. kernel-hw-drivers sub package) we > should have a way to handle upgrades. > You don't want to upgrade and be left out without any hardware support > because it is now a sub package that nothing pulls in. Yes, that's only too true. But it should be possible to guarantee proper upgrades through means of packaging. And of course this will be tested. > How much are you trying to save by this? All modules (excluding extra > which is already a sub package) are ~115MB here on x86_64. As much as is sensibly possible. Every MB counts but we don't want to drive the kernel team members insane. :) -- Sandro _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
