On Thursday 12 June 2008, Ian Campbell wrote: > > > > > +drivers/block/virtio_blk.ko > > > > > +drivers/block/xen-blkfront.ko > > > > > +drivers/net/virtio_net.ko > > > > > +drivers/net/xen-netfront.ko > > > > > > I have patches to make the installer work well as a Xen guest so > > > those drivers are needed. > > > > Does that also go for the 486 kernel flavor or only for 686-bigmem > > (if/when we add that)? > > The 486 flavour doesn't have CONFIG_XEN enabled and in fact upstream > recently removed non-PAE 32 bit support from the hypervisor so no need > there. > > > What about amd64? > > Eventually, yes, although the 64 bit kernel doesn't support Xen yet. OK. That means that in this context (updating kernel-wedge for 2.6.25) these modules are irrelevant and Martin was correct as they are not generally needed. > > Should those go in the regular udebs or in one or more separate "xen > > udebs"? > > When I added them locally I stuck the disk driver in the scsi-modules > udeb (a bit arbitrarily) and the net one in nic-modules. We can work that out when we create the 686-bigmem flavor, but that sounds like the correct solution as long as Xen support is tied to 686-bigmem and only supported by separate images [1]. We can easily revisit that if/when Xen support gets integrated. > > > 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... Cheers, FJP [1] I've also been thinking that we should generate the D-I images as "xen" subflavors, i.e. i386/netboot/xen.
Attachment:
signature.asc
Description: This is a digitally signed message part.