Modular Kernel Packaging for Cloud
jwboyer at fedoraproject.org
Wed Mar 5 15:08:04 UTC 2014
On Wed, Mar 5, 2014 at 9:59 AM, Gerd Hoffmann <kraxel at redhat.com> wrote:
>> I'm not overly thrilled with having multi-tiered driver packages.
>> That leads to major headaches when we start shuffling things around
>> from one driver package to another. The current solution I have
>> prototyped is a kernel-core/kernel-drivers split. Here "core" could
>> be analogous to "cloud", but I imagine it will be useful for other
>> things. People wanting to do PCI passthrough can just install the
>> kernel-drivers package.
> Agree, I don't think it makes much sense to split things into many small
>> - Do you need/want a firewall (requires iptables, etc)?
> I'd say yes by default, but being able to remove it might be useful
> (kernel-netfilter subpackage)?
So you agree multi-tiered subpackages is a bad idea, but then you
propose a netfilter specific subpackage? ... Probably not. They'll
likely just be in kernel-core.
>> - Do you need/want NFS or other cloudy storage things (for gluster?)?
> I'm personally using NFS for host/guest filesystem sharing, so I'd vote
>> - Do you need/want openvswitch?
> I think no. That's a host side thing and this is about the guest
> kernel, right?
Nested virt? I dunno, it was mentioned at one point so I thought I'd
bring it up for discussion again.
>> The list of modules I have in my local rawhide KVM guest is below.
>> The snd_* related drivers probably aren't necessary. The btrfs and
>> things it depends on can be ignored (unless you plan on switching from
> Depends on what is targeted. Strictly cloud? Or also someone running
> Fedora as a guest in virt-manager / boxes?
I'm of the opinion the latter is probably what we should shoot for.
It's going to be the broadest target that is still reasonably small.
> I'd tend to include drivers for pretty much everything qemu can emulate.
>> uinput 17708 1
> spice guest agent uses this.
>> bluetooth 445507 5 bnep
>> cfg80211 583354 0
> bluetooth+wireless are not needed, dunno why they are loaded.
Me either. I'm guessing because systemd/NetworkManager on my KVM
guest auto-loads them.
>> snd_hda_codec_generic 66943 1
>> snd_hda_intel 56588 4
> For the qemu HDA soundcard. Should be included if desktop usecase
> should be covered too.
>> qxl 74078 2
> gpu driver. There are also cirrus + bochs-drm for qemu.
> vmware vga has a drm driver too. They should be included.
>> ata_generic 12910 0
>> pata_acpi 13038 0
> IDE. Needed. Qemu can emulate AHCI too, should be included (but I
> think that is =y anyway).
> Qemu can emulate a bunch of SCSI HBAs. Don't think we need the drivers
> for them (except virtio-scsi). vmware emulates SCSI HBAs too. pvscsi
> should be included. Dunno about the older ones, there was for example
> some buslogic emulation in older vmware workstation versions ...
> USB: Qemu can also emulate uhci + ehci + xhci, should be included. Also
> usb-storage and generic hid support (for the usb tablet). IIRC most of
> this is =y anyway.
> NIC: e1000, rtl8139 (qemu), tulip (hyperv), dunno about vmware. qemu
> can also emulate a bunch of other nics such as ne2k, but I think those
> are not relevant in practice and not needed.
> Of course all paravirtual drivers should be included too, i.e.
> * all virtio (for qemu)
> * all xen frontend (for xen, the backend drivers are for the host
> side and are not needed in the guest).
> * all hyperv (for hyperv)
OK. Was planning on that already.
More information about the cloud