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 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. 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. _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
