On Wed, Mar 5, 2014 at 9:59 AM, Gerd Hoffmann <kraxel(a)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