As I'm sure you know there is no Xen domain 0 kernel present in Lenny. I
think we are currently recommending that people who require a Xen domain
0 stick with the Etch kernel on a Lenny userspace/hypervisor until
"Lenny and a half" at which point we hope dom0 (and 64 bit) support will
be in the paravirt ops kernel. (is there consensus on this in the kernel
team?)

With that in mind what level of updates would we be willing to accept
into an update of the Etch kernel to make this work?

I'm particularly thinking of
http://xenbits.xensource.com/xen-uns...v/c9ac0bace498 which is
pretty much a pure feature patch but will allow a 64 bit domain 0 to
speak disk to 32 bit guests. This is quite handy given Lenny only
supports 32 bit guests...
http://marc.info/?l=linux-kernel&m=121959036719825

If this is unacceptable (probably?) then are there any other
options/plans/ideas for providing an updated 2.6.18 domain 0 kernel? I
hear Bastian has a repo somewhere?

Ian.
--
Ian Campbell

Meekness: Uncommon patience in planning a revenge that is worth while.
-- Ambrose Bierce

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAki1zOwACgkQM0+0qS9rzVnISQCgo003m0+QRf ibK6vs2tqW+c02
GZAAn0PBPsOISNXkxLpWjRL55BqOMJyh
=fMUR
-----END PGP SIGNATURE-----

On Wed, Aug 27, 2008 at 10:53:48PM +0100, Ian Campbell wrote:
> As I'm sure you know there is no Xen domain 0 kernel present in Lenny. I
> think we are currently recommending that people who require a Xen domain
> 0 stick with the Etch kernel on a Lenny userspace/hypervisor until
> "Lenny and a half" at which point we hope dom0 (and 64 bit) support will
> be in the paravirt ops kernel. (is there consensus on this in the kernel
> team?)

hey Ian!

I'm not aware of any well-formed consensus yet - though there are
several ideas. I'll caveat this by saying I don't follow Xen
development at all, and didn't participate in the previous thread
about this (very busy at the time), but I do think the approach that
would be best for our users is to ship a 2.6.18-based kernel in
lenny - aka, Bastian's Option 5:
http://lists.debian.org/debian-devel.../msg00476.html

The problem is that I can pretty much guarantee that I'll not have
time to actively security support this kernel - and as such, we'd need
someone to step up to help with that kernel. I'd be happy to work with
1-2 people to get them up to speed on working with the kernel, share
patches, etc.

> With that in mind what level of updates would we be willing to accept
> into an update of the Etch kernel to make this work?
>
> I'm particularly thinking of
> http://xenbits.xensource.com/xen-uns...v/c9ac0bace498 which is
> pretty much a pure feature patch but will allow a 64 bit domain 0 to
> speak disk to 32 bit guests. This is quite handy given Lenny only
> supports 32 bit guests...
> http://marc.info/?l=linux-kernel&m=121959036719825

Since its neither a >= important bug for etch, nor obviously safe for
existing installs, I don't think it'd be an option for 'etch'. Its
definitely more suited for the mythological lenny-specific 2.6.18.

> If this is unacceptable (probably?) then are there any other
> options/plans/ideas for providing an updated 2.6.18 domain 0 kernel? I
> hear Bastian has a repo somewhere?

Yeah, he maintains a branch under people/waldi, iirc. Not sure where
the builds are though.

--
dann frazier


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Aug 27, 2008 at 05:20:53PM -0600, dann frazier wrote:
> I'm not aware of any well-formed consensus yet - though there are
> several ideas. I'll caveat this by saying I don't follow Xen
> development at all, and didn't participate in the previous thread
> about this (very busy at the time), but I do think the approach that
> would be best for our users is to ship a 2.6.18-based kernel in
> lenny - aka, Bastian's Option 5:
> http://lists.debian.org/debian-devel.../msg00476.html

What is the problem with Option 4?

> Since its neither a >= important bug for etch, nor obviously safe for
> existing installs, I don't think it'd be an option for 'etch'.

It is safe for existing installs. It only adds a new parameter which
changes the behavour if set.

> > If this is unacceptable (probably?) then are there any other
> > options/plans/ideas for providing an updated 2.6.18 domain 0 kernel? I
> > hear Bastian has a repo somewhere?
> Yeah, he maintains a branch under people/waldi, iirc. Not sure where
> the builds are though.

deb http://kernel-archive.buildserver.ne...aldi/xen-extra allmain

Bastian

--
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iEYEARECAAYFAki2VZUACgkQnw66O/MvCNH+twCfcdxFduKs0WBmM8SUWj0bj6o+
sgMAoKGPq7yTUcHy43PpteAJ4/01TZbH
=Z5pX
-----END PGP SIGNATURE-----

On Thu, Aug 28, 2008 at 09:36:53AM +0200, Bastian Blank wrote:
> On Wed, Aug 27, 2008 at 05:20:53PM -0600, dann frazier wrote:
> > I'm not aware of any well-formed consensus yet - though there are
> > several ideas. I'll caveat this by saying I don't follow Xen
> > development at all, and didn't participate in the previous thread
> > about this (very busy at the time), but I do think the approach that
> > would be best for our users is to ship a 2.6.18-based kernel in
> > lenny - aka, Bastian's Option 5:
> > http://lists.debian.org/debian-devel.../msg00476.html
>
> What is the problem with Option 4?

My two concerns with that are:
* Dropping support for a package in a stable release (which we
currently only do due to unforeseen circumstances) and
* forcing users to upgrade to a new upstream version within a stable
release.

> > Since its neither a >= important bug for etch, nor obviously safe for
> > existing installs, I don't think it'd be an option for 'etch'.
>
> It is safe for existing installs. It only adds a new parameter which
> changes the behavour if set.

Well, its not as straightforward as if (opt) { new_behavior; }, but it
is probably something reasonable to verify via code review and
testing. However, it is still a feature change. Certainly, if the
project decides that we need to use the etch kernel directly in lenny
(and not a separate lenny-specific 2.6.18 branch), then I think its
reasonable to argue for an exception for that technicality - but we're
not there yet.

> > > If this is unacceptable (probably?) then are there any other
> > > options/plans/ideas for providing an updated 2.6.18 domain 0 kernel? I
> > > hear Bastian has a repo somewhere?
> > Yeah, he maintains a branch under people/waldi, iirc. Not sure where
> > the builds are though.
>
> deb http://kernel-archive.buildserver.ne...aldi/xen-extra all main
>
> Bastian
>



--
dann frazier


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Aug 28, 2008 at 11:22:19AM -0600, dann frazier wrote:
> On Thu, Aug 28, 2008 at 09:36:53AM +0200, Bastian Blank wrote:
> > On Wed, Aug 27, 2008 at 05:20:53PM -0600, dann frazier wrote:
> > > I'm not aware of any well-formed consensus yet - though there are
> > > several ideas. I'll caveat this by saying I don't follow Xen
> > > development at all, and didn't participate in the previous thread
> > > about this (very busy at the time), but I do think the approach that
> > > would be best for our users is to ship a 2.6.18-based kernel in
> > > lenny - aka, Bastian's Option 5:
> > > http://lists.debian.org/debian-devel.../msg00476.html
> >
> > What is the problem with Option 4?
>
> My two concerns with that are:
> * Dropping support for a package in a stable release (which we
> currently only do due to unforeseen circumstances) and
> * forcing users to upgrade to a new upstream version within a stable
> release.

So nothing in addition to my concerns. So we are back at the decision
between:
- Full support, which currently noone wants to handle.
- Support until we have something new, which breaks with some rules.
- No support.

I know its not really pretty, but for now its the best we can get IMHO.

Bastian

--
It would be illogical to assume that all conditions remain stable.
-- Spock, "The Enterprise Incident", stardate 5027.3


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Aug 28, 2008 at 08:32:21PM +0200, Bastian Blank wrote:
> On Thu, Aug 28, 2008 at 11:22:19AM -0600, dann frazier wrote:
> > On Thu, Aug 28, 2008 at 09:36:53AM +0200, Bastian Blank wrote:
> > > On Wed, Aug 27, 2008 at 05:20:53PM -0600, dann frazier wrote:
> > > > I'm not aware of any well-formed consensus yet - though there are
> > > > several ideas. I'll caveat this by saying I don't follow Xen
> > > > development at all, and didn't participate in the previous thread
> > > > about this (very busy at the time), but I do think the approach that
> > > > would be best for our users is to ship a 2.6.18-based kernel in
> > > > lenny - aka, Bastian's Option 5:
> > > > http://lists.debian.org/debian-devel.../msg00476.html
> > >
> > > What is the problem with Option 4?
> >
> > My two concerns with that are:
> > * Dropping support for a package in a stable release (which we
> > currently only do due to unforeseen circumstances) and
> > * forcing users to upgrade to a new upstream version within a stable
> > release.
>
> So nothing in addition to my concerns. So we are back at the decision
> between:
> - Full support, which currently noone wants to handle.

One plus for #4 is that it gives us the option of doing #5 later, in
case someone steps forward between now and the end of etch support.

> - Support until we have something new, which breaks with some rules.
> - No support.
>
> I know its not really pretty, but for now its the best we can get IMHO.

If we choose to migrate users within a stable release, we'd need to have
some predetermined overlap between lennynhalf availability and 2.6.18
security support so we can communicate to users that, at some point in
the future, they will be asked to migrate and they'll have n months to
do so.

We would also need a pretty good communication plan, that is ideally
in-band of the normal install/upgrade process. For example:
1) 5.0r0: NEWS.Debian that warns of the shorter-than-normal security
support
2) 5.0+half: NEWS.Debian that gives a N month warning to migrate to
lennynhalf kernel
2) 5.0+half+N-months: NEWS.Debian that warns that they are installing
an unsupported package

--
dann frazier


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On 2008-08-28, Bastian Blank wrote:
> On Thu, Aug 28, 2008 at 11:22:19AM -0600, dann frazier wrote:
>> On Thu, Aug 28, 2008 at 09:36:53AM +0200, Bastian Blank wrote:
>> > On Wed, Aug 27, 2008 at 05:20:53PM -0600, dann frazier wrote:
>> > > I'm not aware of any well-formed consensus yet - though there are
>> > > several ideas. I'll caveat this by saying I don't follow Xen
>> > > development at all, and didn't participate in the previous thread
>> > > about this (very busy at the time), but I do think the approach that
>> > > would be best for our users is to ship a 2.6.18-based kernel in
>> > > lenny - aka, Bastian's Option 5:
>> > > http://lists.debian.org/debian-devel.../msg00476.html
>> >
>> > What is the problem with Option 4?
>>
>> My two concerns with that are:
>> * Dropping support for a package in a stable release (which we
>> currently only do due to unforeseen circumstances) and
>> * forcing users to upgrade to a new upstream version within a stable
>> release.
>
> So nothing in addition to my concerns. So we are back at the decision
> between:
> - Full support, which currently noone wants to handle.
> - Support until we have something new, which breaks with some rules.
> - No support.
>
> I know its not really pretty, but for now its the best we can get IMHO.

What about the Novell 2.6.26 forward-port?

Cheers,
Moritz



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Aug 28, 2008 at 10:49:11PM +0200, Moritz Muehlenhoff wrote:
> On 2008-08-28, Bastian Blank wrote:
> > I know its not really pretty, but for now its the best we can get IMHO.
> What about the Novell 2.6.26 forward-port?

Novell did a .25 forward-port.

Bastian

--
There is an order of things in this universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Aug 28, 2008 at 02:25:30PM -0600, dann frazier wrote:
> > - Full support, which currently noone wants to handle.
> One plus for #4 is that it gives us the option of doing #5 later, in
> case someone steps forward between now and the end of etch support.

Yes.

> > I know its not really pretty, but for now its the best we can get IMHO.
>
> If we choose to migrate users within a stable release, we'd need to have
> some predetermined overlap between lennynhalf availability and 2.6.18
> security support so we can communicate to users that, at some point in
> the future, they will be asked to migrate and they'll have n months to
> do so.
>
> We would also need a pretty good communication plan, that is ideally
> in-band of the normal install/upgrade process. For example:
> 1) 5.0r0: NEWS.Debian that warns of the shorter-than-normal security
> support

I also needs to be mentioned in the release notes, which anyone should
read. NEWS.Debian is ignored often.

> 2) 5.0+half: NEWS.Debian that gives a N month warning to migrate to
> lennynhalf kernel

I would use debconf.

> 2) 5.0+half+N-months: NEWS.Debian that warns that they are installing
> an unsupported package

I would just replace it with a dummy package which fails in preinst, so
it can never be configured, but will not remove the old data on upgrade.

Bastian

--
A little suffering is good for the soul.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, 2008-08-28 at 20:32 +0200, Bastian Blank wrote:
> On Thu, Aug 28, 2008 at 11:22:19AM -0600, dann frazier wrote:
> > On Thu, Aug 28, 2008 at 09:36:53AM +0200, Bastian Blank wrote:
> > > On Wed, Aug 27, 2008 at 05:20:53PM -0600, dann frazier wrote:
> > > > I'm not aware of any well-formed consensus yet - though there are
> > > > several ideas. I'll caveat this by saying I don't follow Xen
> > > > development at all, and didn't participate in the previous thread
> > > > about this (very busy at the time), but I do think the approach that
> > > > would be best for our users is to ship a 2.6.18-based kernel in
> > > > lenny - aka, Bastian's Option 5:
> > > > http://lists.debian.org/debian-devel.../msg00476.html
> > >
> > > What is the problem with Option 4?
> >
> > My two concerns with that are:
> > * Dropping support for a package in a stable release (which we
> > currently only do due to unforeseen circumstances) and
> > * forcing users to upgrade to a new upstream version within a stable
> > release.
>
> So nothing in addition to my concerns. So we are back at the decision
> between:
> - Full support, which currently noone wants to handle.
> - Support until we have something new, which breaks with some rules.
> - No support.
>
> I know its not really pretty, but for now its the best we can get IMHO.

I agree (FWIW, I'm only a bit player round here...)

As much as I'd like to help with offering full support I think
realistically I'm not going to have that much time to give to it, at
least not with any guarantee.

I'm not sure that requiring users to upgrade to a new upstream version
within a stable release is all that heinous _iff_ it is well documented
in the original release notes as Bastian suggests. Assuming the andahalf
thing continues with Lenny (why wouldn't it?) it seems like a perfect
vehicle for something like that.

Ian.

--
Ian Campbell

It's hard to keep your shirt on when you're getting something off your chest.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org