On Saturday 12 July 2008, Ian Campbell wrote:
> > As these modules are only going to be used with the i386 -bigmem
> > kernel and even only exist there, I wonder if we want them in
> > kernel-wedge.
>
> They will eventually be needed for the amd64 kernels too, although
> probably not in time for Lenny. There's also a port of Xen to IA64
> which is fairly active and just starting to go into the upstream
> kernel, again probably not for Lenny though.
That's still only a minority of arches where it's actually used.
Note that the jffs2 case was different: there we were talking about
providing the base-definition for new udebs; here we're talking about
minor, specific adjustment of content of existing udebs for a specific
use-case. If it really does become generic or common, it's trivial to
move to kernel-wedge at that time.
(Sidenote: the proposed patch for jffs2 also missed the package
descriptions, basically _because_ it was based on package overrides
instead of proper package definitions.)
> What about retasking the new virtio udebs into virtuali{s,z}ion (or
> just virt) and adding them there?
That could work, but I suspect it could result in a dependency mess. You
can either check /lib/modules/<ver>/modules.dep to see how bad it is or
just try it. If these modules do not depend on anything much then this
could be a good option.
> (aside: how does the installer go from the presence of some piece of
> hardware, virtual or otherwise, to a dependency on a particular udeb??)
It doesn't. Something like that is always scripted: code your test at the
appropriate stage of the installation and call 'anna-install <udeb>'. In
case of kernel modules: make sure depmod -a is run before modprobe.
Things that need to be included in the initrd variants of the pkg-lists
would need to be defined.
> > > Final patch is the the installer itself to cause a 686-bigmem
> > > netboot image to be built. [installer.patch]
> >
> > ! +++ installer/build/config/i386/netboot-bigmem.cfg (revision 0)
> >
> > AFAICT the following is missing to ensure the result lands in a
> > subdir: EXTRANAME = netboot/bigmem/
>
> It currently ends up in installer/build/dest/netboot-bigmem/ we want
> installer/build/dest/netboot/bigmem? That's fine by me (modulo naming
> discussion below).
Yes. It's still a variation on basic netboot and should therefore be in a
subdir and not the top level. That also makes it less likely to confuse
"regular" users.
> > My proposal would be to use "netboot-xen" as internal name (the fact
> > that we need the bigmem kernel for Xen is secondary to the purpose
> > for which we build it IMO) and maybe "netboot/xen-bigmem" for the
> > directory (EXTRANAME).
>
> I really wanted to avoid having a Xen specific image, but you are right
> it will most likely confuse users. I don't suppose there is any support
> for aliases (becoming symlinks or something in the output)? I could add
> that functionality if desired. If not then I'd say either netboot/xen
> or netboot/xen-bigmem would be an appropriate name.
We have had a symlink for netboot-gtk for a while, so it definitely is
possible, though I don't see the need here.
> Other distros (and *bsd etc) would tend to call it either xen or
> xenpae, I think, rather than bigmem (which is something of a Debianism)
> -- what do you think of those names?
I don't have any problem with either of those. As mentioned before, IMO
that the fact it uses the -bigmem kernel is only incidental to its
purpose. Main thing is to be clear to users.
Hmm. You may also want to do a quick check of the manifest texts in the
installer config from that perspective.
> > BTW, I propose that you (if you're interested) are given commit
> > access to the D-I repository on alioth so you can commit this
> > yourself and maintain Xen (and maybe virtualization in general)
> > support directly. I see you already have an account.
>
> That's fine by me although I would still like to keep posting to the
> list first (and you probably want me to anyway). My alioth account is
> ijc-guest.
Yes, that is certainly appreciated and even expected. Though not needed
for really specific, minor or obvious changes/fixes.
I've added you, so you should now have commit access.
> I'll prep a new set of patches and resend once I see your
> base-installer changes.
No need for the full set. Just base-installer and maybe kernel-wedge will
do I think. We'll do quick checks of the final changes anyway based on
the commit mails that get sent out.
Cheers,
FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.