Modular Kernel Packaging for Cloud

[Josh Boyer]

On Wed, Mar 5, 2014 at 9:59 AM, Gerd Hoffmann <kraxel at redhat.com> wrote:
>
>   Hi,
>
>> 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
> pieces.
>
>> - 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
> yes.
>
>> - 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
>> ext4).
>
> 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.

josh