On Wed, Mar 5, 2014 at 9:59 AM, Gerd Hoffmann <kraxel@xxxxxxxxxx> 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 _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
