On Thu, 2008-06-12 at 22:20 +0200, Frans Pop wrote: > 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. True. I guess I was making a more general comment about the future... > > > 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. Should I resend my patches for this? > [1] I've also been thinking that we should generate the D-I images > as "xen" subflavors, i.e. i386/netboot/xen. Well, they aren't only usable on Xen since they will work fine on native PAE too, although it could be argued they are only useful on Xen (or other virtualisation solutions). Ian. -- Ian Campbell It has been said that man is a rational animal. All my life I have been searching for evidence which could support this. -- Bertrand Russell
Attachment:
signature.asc
Description: This is a digitally signed message part