On Thu, Jun 12, 2008 at 10:20:37PM +0200, Frans Pop wrote: > > > > I included virtio too, because, well, why not ;-) > > > > > > Because we're _always_ trying to save on memory usage. If something > > > does not have a definite function in the context of the installer: > > > don't include it. > > > > Well, I guess the installer could be used under KVM as well, which is > > what the virtio drivers target (I'm pretty sure, don't use it > > myself...). Although since kvm is fully virtualised by default I guess > > you can install using emulated devices and switch to virtio afterwards > > -- it'll just mean performance is worse while installing and is an > > extra step admins have to go through. > > Sounds like that is only useful if someone codes detection of a KVM > environment into the installer and we can somehow disable use of the > emulated devices and use virtio instead. Until someone steps up to do > that I'd suggest to leave the module out. Especially as I've recently > seen comments about how nice using KVM is to test installs... I have not done any testing myself, but from what I have understood, hosts exposes totally different devices to the system (= different PCI IDs) when told to use virtio. The only support needed in d-i would be to handle /dev/vd* devices, the module itself would be loaded automatically. I very much welcome the addition of virtio modules, even if it's in a special module udeb, as the speed-ups should be significant when testing installations in qemu/kvm and probably future releases of virtualbox. Cheers, -- Jérémy Bobbio
Attachment:
signature.asc
Description: Digital signature