Re: Including a low-latency kernel images in Debian for use with CDD DeMuDi.
On Mon, Feb 13, 2006 at 11:39:50AM +0100, Bastian Blank wrote:
> On Sun, Feb 12, 2006 at 10:10:51PM +0100, Sven Luther wrote:
> > Well, they could change the boxes to use fast machines, i guess it should be
> > no major problem, it is just that i386 users are spoiled by the majority of
> > DDs uploading x86.
>
> I can build the 5 images in 1:20 on the power5 with 4 cores.
>
> > the idea is to build a few flavours with the -RT patches, not all images, the
> > same as you only built a few flavours for the vserver patches, and i guess
> > only powerpc, i386 and amd64 need to be considered for now. So, you don't risk
> > an explosion of the number of flavours.
>
> Okay. Lets take a look at the images:
> i386:
> * available:
> - 486
> - 686 (maybe we can adopt the lock-noop patch, see the xen repo for
> references)
> - 686-smp
> - k7 (the same)
> - k7-smp
> * ready for merge:
> - vserver-686 (here, I think, we really should add the mentioned
> patch, as i386 have a too large overhead for locking)
> - vserver-k7
> * wanted:
> - amd64-k8
> - emt64-$bla
> * requested for -media (I think):
> - rt-686
> - rt-k7
> * pending:
> - xen-686
> - xen-k7
>
> This are 13 images. Also I got requests for openvz but rejected them
> because they don't follow upstream.
13 images is something we can handle i believe, going much more would be
problematic, the idea is for xen and vserver to be merged inside mainline
anyway, no ?
> powerpc:
> * available
- apus
> - powerpc
> - powerpc-miboot
> - powerpc-smp
> - powerpc64
> * ready for merge:
> - vserver-powerpc
> - vserver-powerpc64
i think the idea is to have rt-powerpc too, probably not rt-powerpc64 though,
as the rt patch seem to not be smp ready yet and powerpc64 is smp only. Maybe
we could have a rt-powerpc64 up flavour though.
not sure about xen on powerpc though.
Still, that you have those flavours inside the common package, or as a
separate source package, there is not really much difference in build time,
and it will be more of a mess in security issues later on, so let's include
them, i would say.
Friendly,
Sven Luther
Reply to: