Future of xenbits Linux trees

Future of xenbits Linux trees

[Keir Fraser]

Folks,

With 3.4 out the door it is time to revisit the state of our Linux
repositories. Currently we have a number of trees in various states of
maintenance:
 - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
tested but increasingly long in the tooth.
 - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
clones tree is not maintained or tested.
 - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
Maintained as part of XCI project.
 - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
tested, but incomplete.

It is probably time to kill the 2.6.18 tree, or at least stop active
development within it. It is increasingly a kludged collection of backports
of more recent kernel patches, and is also missing a lot of drivers for more
modern hardware.

Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
and make it the main user tree. Development and automated testing would
occur on that tree and of course on Jeremy's pv_ops patchset (which we want
to completely move onto at some point in the future).

What do people think of this as a plan?

 -- Keir

Re: Future of xenbits Linux trees

[Jean Guyader]

2009/6/4 Keir Fraser <keir.fraser@eu.citrix.com>:
> Folks,
>
> With 3.4 out the door it is time to revisit the state of our Linux
> repositories. Currently we have a number of trees in various states of
> maintenance:
>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> tested but increasingly long in the tooth.
>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> clones tree is not maintained or tested.
>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> Maintained as part of XCI project.
>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> tested, but incomplete.
>
> It is probably time to kill the 2.6.18 tree, or at least stop active
> development within it. It is increasingly a kludged collection of backports
> of more recent kernel patches, and is also missing a lot of drivers for more
> modern hardware.
>
> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> and make it the main user tree. Development and automated testing would
> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> to completely move onto at some point in the future).
>
> What do people think of this as a plan?
>

This tree is not tied up with XCI at all.
It can be taken as it and runs on the top of mainstream xen.

Jean

Re: Future of xenbits Linux trees

[Tim Post]

On Thu, 2009-06-04 at 16:45 +0100, Keir Fraser wrote:

> What do people think of this as a plan?

Just tell me where to send the beer.

Cheers,
--Tim

Re: Future of xenbits Linux trees

[Espen Skoglund]

Sounds reasonable.  The 2.6.18 tree is getting a bit dated now.

One question: How complete is the XCI tree with respect to the various
Xen related features having been added to the 2.6.18 tree over time?
Is it all in there?

	eSk



[Keir Fraser]
> Folks,
> With 3.4 out the door it is time to revisit the state of our Linux
> repositories. Currently we have a number of trees in various states of
> maintenance:
>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> tested but increasingly long in the tooth.
>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> clones tree is not maintained or tested.
>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> Maintained as part of XCI project.
>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> tested, but incomplete.

> It is probably time to kill the 2.6.18 tree, or at least stop active
> development within it. It is increasingly a kludged collection of
> backports of more recent kernel patches, and is also missing a lot
> of drivers for more modern hardware.

> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI
> subproject and make it the main user tree. Development and automated
> testing would occur on that tree and of course on Jeremy's pv_ops
> patchset (which we want to completely move onto at some point in the
> future).

> What do people think of this as a plan?

>  -- Keir



> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Keir Fraser]

On 04/06/2009 19:08, "Espen Skoglund" <espen.skoglund@netronome.com> wrote:

> Sounds reasonable.  The 2.6.18 tree is getting a bit dated now.
> 
> One question: How complete is the XCI tree with respect to the various
> Xen related features having been added to the 2.6.18 tree over time?
> Is it all in there?

There may be pieces missing relating to power management and device
passthrough. They can be added down the line however, and the 2.6.18 tree
won't be deleted.

 -- Keir

Re: Future of xenbits Linux trees

[Jean Guyader]

2009/6/4 Keir Fraser <keir.fraser@eu.citrix.com>:
> On 04/06/2009 19:08, "Espen Skoglund" <espen.skoglund@netronome.com> wrote:
>
>> Sounds reasonable.  The 2.6.18 tree is getting a bit dated now.
>>
>> One question: How complete is the XCI tree with respect to the various
>> Xen related features having been added to the 2.6.18 tree over time?
>> Is it all in there?
>
> There may be pieces missing relating to power management and device
> passthrough. They can be added down the line however, and the 2.6.18 tree
> won't be deleted.
>


We have pciback with flr,blktap2 in term of new things.

Jean

Re: Future of xenbits Linux trees

[Andrew Lyon]

On Thu, Jun 4, 2009 at 4:45 PM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> Folks,
>
> With 3.4 out the door it is time to revisit the state of our Linux
> repositories. Currently we have a number of trees in various states of
> maintenance:
>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> tested but increasingly long in the tooth.
>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> clones tree is not maintained or tested.
>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> Maintained as part of XCI project.
>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> tested, but incomplete.
>
> It is probably time to kill the 2.6.18 tree, or at least stop active
> development within it. It is increasingly a kludged collection of backports
> of more recent kernel patches, and is also missing a lot of drivers for more
> modern hardware.
>
> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> and make it the main user tree. Development and automated testing would
> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> to completely move onto at some point in the future).
>
> What do people think of this as a plan?
>
>  -- Keir

I think 2.6.27 is already out of date and you should start with 2.6.29
using my rebased patches, people have been using them since I did
2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
does, I'm sure that could be fixed but right now I dont know of any
issues with 2.6.29 at all, so why not make the jump to the current
stable kernel :).

XCI should update to 2.6.29 as well.

I use pci passthrough with a pci express usb2 card, I also use scsi
passthrough with a ultrium tape drive, usually running several windows
hvm's and a couple of 2.6.29 pv domU's as well, no problems.

Andy

Re: Future of xenbits Linux trees

[Pasi Kärkkäinen]

On Fri, Jun 05, 2009 at 08:32:21AM +0100, Andrew Lyon wrote:
> On Thu, Jun 4, 2009 at 4:45 PM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> > Folks,
> >
> > With 3.4 out the door it is time to revisit the state of our Linux
> > repositories. Currently we have a number of trees in various states of
> > maintenance:
> >  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> > tested but increasingly long in the tooth.
> >  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> > clones tree is not maintained or tested.
> >  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> > Maintained as part of XCI project.
> >  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> > tested, but incomplete.
> >
> > It is probably time to kill the 2.6.18 tree, or at least stop active
> > development within it. It is increasingly a kludged collection of backports
> > of more recent kernel patches, and is also missing a lot of drivers for more
> > modern hardware.
> >
> > Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> > and make it the main user tree. Development and automated testing would
> > occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> > to completely move onto at some point in the future).
> >
> > What do people think of this as a plan?
> >
> >  -- Keir
> 
> I think 2.6.27 is already out of date and you should start with 2.6.29
> using my rebased patches, people have been using them since I did
> 2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
> thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
> does, I'm sure that could be fixed but right now I dont know of any
> issues with 2.6.29 at all, so why not make the jump to the current
> stable kernel :).
> 
> XCI should update to 2.6.29 as well.
> 

Just to clear it up, Keir proposed to use the XCI 2.6.27-git tree as a
starting point, not the unmaintained and buggy 2.6.27-xen.

But anyway, I think the best option would be to start with Andrew's patches
for 2.6.29.

> I use pci passthrough with a pci express usb2 card, I also use scsi
> passthrough with a ultrium tape drive, usually running several windows
> hvm's and a couple of 2.6.29 pv domU's as well, no problems.
> 

That's good.

-- Pasi

Re: Future of xenbits Linux trees

[Keir Fraser]

On 05/06/2009 08:32, "Andrew Lyon" <andrew.lyon@gmail.com> wrote:

> I think 2.6.27 is already out of date and you should start with 2.6.29
> using my rebased patches, people have been using them since I did
> 2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
> thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
> does, I'm sure that could be fixed but right now I dont know of any
> issues with 2.6.29 at all, so why not make the jump to the current
> stable kernel :).
> 
> XCI should update to 2.6.29 as well.
> 
> I use pci passthrough with a pci express usb2 card, I also use scsi
> passthrough with a ultrium tape drive, usually running several windows
> hvm's and a couple of 2.6.29 pv domU's as well, no problems.

That's certainly an option, especially if it has stuff like pciback,
blktap2, and various patches for device passthrough (e.g., using VT-d)
already ported to it, similar to the XCI 2.6.27 tree.

 -- Keir

Re: Future of xenbits Linux trees

[Jean Guyader]

2009/6/5 Andrew Lyon <andrew.lyon@gmail.com>:
> On Thu, Jun 4, 2009 at 4:45 PM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
>> Folks,
>>
>> With 3.4 out the door it is time to revisit the state of our Linux
>> repositories. Currently we have a number of trees in various states of
>> maintenance:
>>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
>> tested but increasingly long in the tooth.
>>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
>> clones tree is not maintained or tested.
>>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
>> Maintained as part of XCI project.
>>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
>> tested, but incomplete.
>>
>> It is probably time to kill the 2.6.18 tree, or at least stop active
>> development within it. It is increasingly a kludged collection of backports
>> of more recent kernel patches, and is also missing a lot of drivers for more
>> modern hardware.
>>
>> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
>> and make it the main user tree. Development and automated testing would
>> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
>> to completely move onto at some point in the future).
>>
>> What do people think of this as a plan?
>>
>>  -- Keir
>
> I think 2.6.27 is already out of date and you should start with 2.6.29
> using my rebased patches, people have been using them since I did
> 2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
> thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
> does, I'm sure that could be fixed but right now I dont know of any
> issues with 2.6.29 at all, so why not make the jump to the current
> stable kernel :).
>
> XCI should update to 2.6.29 as well.
>
> I use pci passthrough with a pci express usb2 card, I also use scsi
> passthrough with a ultrium tape drive, usually running several windows
> hvm's and a couple of 2.6.29 pv domU's as well, no problems.
>

Hi Andy,

Where could I get this 2.6.29 from?

Thanks,
Jean

Re: Future of xenbits Linux trees

[Pasi Kärkkäinen]

On Fri, Jun 05, 2009 at 08:58:01AM +0100, Jean Guyader wrote:
> 2009/6/5 Andrew Lyon <andrew.lyon@gmail.com>:
> > On Thu, Jun 4, 2009 at 4:45 PM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> >> Folks,
> >>
> >> With 3.4 out the door it is time to revisit the state of our Linux
> >> repositories. Currently we have a number of trees in various states of
> >> maintenance:
> >>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> >> tested but increasingly long in the tooth.
> >>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> >> clones tree is not maintained or tested.
> >>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> >> Maintained as part of XCI project.
> >>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> >> tested, but incomplete.
> >>
> >> It is probably time to kill the 2.6.18 tree, or at least stop active
> >> development within it. It is increasingly a kludged collection of backports
> >> of more recent kernel patches, and is also missing a lot of drivers for more
> >> modern hardware.
> >>
> >> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> >> and make it the main user tree. Development and automated testing would
> >> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> >> to completely move onto at some point in the future).
> >>
> >> What do people think of this as a plan?
> >>
> >>  -- Keir
> >
> > I think 2.6.27 is already out of date and you should start with 2.6.29
> > using my rebased patches, people have been using them since I did
> > 2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
> > thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
> > does, I'm sure that could be fixed but right now I dont know of any
> > issues with 2.6.29 at all, so why not make the jump to the current
> > stable kernel :).
> >
> > XCI should update to 2.6.29 as well.
> >
> > I use pci passthrough with a pci express usb2 card, I also use scsi
> > passthrough with a ultrium tape drive, usually running several windows
> > hvm's and a couple of 2.6.29 pv domU's as well, no problems.
> >
> 
> Hi Andy,
> 
> Where could I get this 2.6.29 from?
> 

I believe from here:
http://gentoo-xen-kernel.googlecode.com/files/xen-patches-2.6.29-6.tar.bz2

At least that URL he posted in the other recent dom0 kernel thread.

-- Pasi

Re: Future of xenbits Linux trees

[Andy Burns]

2009/6/5 Andrew Lyon <andrew.lyon@gmail.com>:

> I think 2.6.27 is already out of date and you should start with 2.6.29
> using my rebased patches,

Whilst newer is better, did I hear that it's likely RHEL6/CentOS6 will
be 2.6.27 based? If so then 2.6.27 would be a "long lived" kernel.

> I use pci passthrough with a pci express usb2 card

is that PV or VT-d?

Re: Future of xenbits Linux trees

[Pasi Kärkkäinen]

On Fri, Jun 05, 2009 at 07:51:44PM +0100, Andy Burns wrote:
> 2009/6/5 Andrew Lyon <andrew.lyon@gmail.com>:
> 
> > I think 2.6.27 is already out of date and you should start with 2.6.29
> > using my rebased patches,
> 
> Whilst newer is better, did I hear that it's likely RHEL6/CentOS6 will
> be 2.6.27 based? If so then 2.6.27 would be a "long lived" kernel.
> 

Where did you hear that? 

I don't have any facts, but I'd _assume_ RHEL6 will have 2.6.29 or 2.6.30 ..

Fedora 10 has 2.6.29 kernel in updates-testing, and Fedora 11 will be based
on 2.6.29 .. But dunno :)

-- Pasi

Re: Future of xenbits Linux trees

[M A Young]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 877 bytes --]

On Sun, 7 Jun 2009, Pasi Kärkkäinen wrote:

> On Fri, Jun 05, 2009 at 07:51:44PM +0100, Andy Burns wrote:
>> Whilst newer is better, did I hear that it's likely RHEL6/CentOS6 will
>> be 2.6.27 based? If so then 2.6.27 would be a "long lived" kernel.
>>
>
> Where did you hear that?
>
> I don't have any facts, but I'd _assume_ RHEL6 will have 2.6.29 or 2.6.30 ..
>
> Fedora 10 has 2.6.29 kernel in updates-testing, and Fedora 11 will be based
> on 2.6.29 .. But dunno :)

2.6.27 has long term upstream support according to this post
https://www.redhat.com/archives/fedora-kernel-list/2009-January/msg00098.html
Also this post suggests that RHEL6 will be based on F10 and F11
https://www.redhat.com/archives/fedora-advisory-board/2008-November/msg00037.html
though what this means with regard to which kernel RHEL6 will have I am 
not sure.

 	Michael Young

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Andy Burns]

2009/6/7 Pasi Kärkkäinen <pasik@iki.fi>:

> On Fri, Jun 05, 2009 at 07:51:44PM +0100, Andy Burns wrote:
>>
>> did I hear that it's likely RHEL6/CentOS6 will
>> be 2.6.27 based?
>
> Where did you hear that?

On a mailing list somewhere, but I couldn't find it to post a
reference, I've just had another look and I still can't find it,
perhaps I was mistaken.

> I don't have any facts, but I'd _assume_ RHEL6 will have 2.6.29 or 2.6.30 ..

Actually I can see plenty of hints that RHEL6 will be ~2.6.30, so if
RH plans on having dom0 in RHEL6 then building some form of
"out-of-tree" coalition around 2.6.30+pvops patches would be nice, and
maybe dom0 will be accepted into mainstream before ~2.6.42 when RHEL7
gets frozen ;-)

Re: Future of xenbits Linux trees

[Christian Tramnitz]

Keir Fraser wrote:
> What do people think of this as a plan?

I'd opt for an approach based on the available 2.6.29 tree from Andrew 
but delayed until 2.6.30 is out.

Simple reason, there are so many fundamental changes in/before 2.6.29 
i.e. ext4 and in terms of video support (KMS, GEM) that anything before 
2.6.29 (such as the 2.6.27 XCI tree) will be a waste of efforts if that 
will be the next tree that should have long-term (until pvops merges 
upstream, haha) support.
On the other hand it might make sense to use the same kernel version 
that RHEL6 will be using to take advantage of their (driver-) 
backporting efforts (not sure how heavily that has been utilized in 
2.6.18). Any insider infos from the RH guys here on the list what kernel 
that might be? ;-)



As a side-note, there is known issue with Andrew's tree not compiling on 
x86_32 with a recent gcc. If I remember correctly that was due to 
optimizations, further details here: 
http://forums.gentoo.org/viewtopic-p-5667545.html#5667545


Best regards,
    Christian

Re: Re: Future of xenbits Linux trees

[Keir Fraser]

On 05/06/2009 14:26, "Christian Tramnitz" <chris.ace@gmx.net> wrote:

> Simple reason, there are so many fundamental changes in/before 2.6.29
> i.e. ext4 and in terms of video support (KMS, GEM) that anything before
> 2.6.29 (such as the 2.6.27 XCI tree) will be a waste of efforts if that
> will be the next tree that should have long-term (until pvops merges
> upstream, haha) support.

We don't need to wait for pv_ops to be merged. We just need it to have
near-enough feature parity. Actually now it supports HVM guests I'm tempted
to just move over to it. It would probably make sense to keep Jeremy as
gatekeeper for that tree, which will take some of his time. Otoh I'm not
sure spending 100% of your time banging your head against lkml is much fun.
:-)

Probably the major thing it's missing for a simple complete changeover is
ia64/Xen support. We could continue to point the ia64 build target at
linux-2.6.18-xen though.

 -- Keir

Re: Re: Future of xenbits Linux trees

[Dulloor]

[-- Attachment #1.1: Type: text/plain, Size: 1630 bytes --]

Makes perfect sense to move over to pvops (in mainline) directly :
- Many of us have already used pvops-git and it works
- Other branches (2.6.27/29/30 or whatever) would be a single-chunk forward
port, with more scope for latent bugs (and no long-term benefits).
- We anyway need to make pvops happen. The more we wait, greater will be the
feature parity.
... and many more reasons.

Please make it happen !

-dulloor

On Fri, Jun 5, 2009 at 9:36 AM, Keir Fraser <keir.fraser@eu.citrix.com>wrote:

> On 05/06/2009 14:26, "Christian Tramnitz" <chris.ace@gmx.net> wrote:
>
> > Simple reason, there are so many fundamental changes in/before 2.6.29
> > i.e. ext4 and in terms of video support (KMS, GEM) that anything before
> > 2.6.29 (such as the 2.6.27 XCI tree) will be a waste of efforts if that
> > will be the next tree that should have long-term (until pvops merges
> > upstream, haha) support.
>
> We don't need to wait for pv_ops to be merged. We just need it to have
> near-enough feature parity. Actually now it supports HVM guests I'm tempted
> to just move over to it. It would probably make sense to keep Jeremy as
> gatekeeper for that tree, which will take some of his time. Otoh I'm not
> sure spending 100% of your time banging your head against lkml is much fun.
> :-)
>
> Probably the major thing it's missing for a simple complete changeover is
> ia64/Xen support. We could continue to point the ia64 build target at
> linux-2.6.18-xen though.
>
>  -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 2309 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: Re: Future of xenbits Linux trees

[Ian Pratt]

> Makes perfect sense to move over to pvops (in mainline) directly :
> - Many of us have already used pvops-git and it works
> - Other branches (2.6.27/29/30 or whatever) would be a single-chunk
> forward port, with more scope for latent bugs (and no long-term benefits).
> - We anyway need to make pvops happen. The more we wait, greater will be
> the feature parity.
> ... and many more reasons.

One of the reasons cited for sticking on 2.6.18 was that it would hopefully encourage folk to use pv_ops if they wanted anything more modern. I'm not sure that worked out too well...

One argument for using 2.6.27 is that I believe it's the kernel used by SLES11, so there should be good availability of drivers backported to it. It strikes me it's not a bad plan to have two trees, one based off the latest stable enterprise distro (in this case SLES11), and the pvops tree based off the latest kernel.org release.

Ian

Re: Re: Future of xenbits Linux trees

[Gerd Hoffmann]

On 06/05/09 16:37, Ian Pratt wrote:
> One of the reasons cited for sticking on 2.6.18 was that it would
> hopefully encourage folk to use pv_ops if they wanted anything more
> modern. I'm not sure that worked out too well...

Making the pv_ops kernel the officially one in xen-unstable should work 
better I think.

> It strikes me it's not a bad plan to have two trees, one based
> off the latest stable enterprise distro (in this case SLES11), and
> the pvops tree based off the latest kernel.org release.

As you've noticed above having two trees (2.6.18 + pv_ops) didn't work 
out very well so far.  I doubt s/2.6.18/2.6.27/ will change that ...

cheers,
   Gerd

Re: Future of xenbits Linux trees

[Christian Tramnitz]

Keir Fraser wrote:
> We don't need to wait for pv_ops to be merged. We just need it to have
> near-enough feature parity. Actually now it supports HVM guests I'm tempted
> to just move over to it. It would probably make sense to keep Jeremy as
> gatekeeper for that tree, which will take some of his time. Otoh I'm not
> sure spending 100% of your time banging your head against lkml is much fun.
> :-)
> 
> Probably the major thing it's missing for a simple complete changeover is
> ia64/Xen support. We could continue to point the ia64 build target at
> linux-2.6.18-xen though.

Afaik pvops (even /next) also has no pci_backend support yet and even 
the pci_frontend support is mainly untested.
Both (front/back) work great with Andrew's 2.6.29 tree, although I 
haven't seen ANY reports of IA64 running off it.

I would also consider pvops to be a moving target (you know... lkml fun) 
so I wouldn't really base anything on it until the structure has been 
approved. Maintaining two different pvops lines (one with all changes as 
requested by mainline maintainers and one "stable") might to much of a 
burden if we already have a working 2.6.29 with (hopefully) not much 
work to do other than extensive testing before announcing it as 2.6.18 
successor.


Best regards,
    Christian

Re: Re: Future of xenbits Linux trees

[Gerd Hoffmann]

On 06/05/09 15:36, Keir Fraser wrote:
> On 05/06/2009 14:26, "Christian Tramnitz"<chris.ace@gmx.net>  wrote:
>
>> Simple reason, there are so many fundamental changes in/before 2.6.29
>> i.e. ext4 and in terms of video support (KMS, GEM) that anything before
>> 2.6.29 (such as the 2.6.27 XCI tree) will be a waste of efforts if that
>> will be the next tree that should have long-term (until pvops merges
>> upstream, haha) support.
>
> We don't need to wait for pv_ops to be merged. We just need it to have
> near-enough feature parity. Actually now it supports HVM guests I'm tempted
> to just move over to it.

Go ahead!  It is really time to stop forward-porting stuff.  The time is 
much better spent in adding the missing features to pv_ops/dom0.  Also 
just after the 3.4 release is the perfect moment for that move, 3.5 
should be able to ship with a pv_ops based kernel then.

cheers,
   Gerd

AW: Re: Re: Future of xenbits Linux trees

[Carsten Schiers]

> Go ahead!  It is really time to stop forward-porting stuff.  The time 
is 
> much better spent in adding the missing features to pv_ops/dom0.  Also 

> just after the 3.4 release is the perfect moment for that move, 3.5 
> should be able to ship with a pv_ops based kernel then.

I'd vote for that, too. Whatever comes out of that discussion on 
"coolness"
on lkml ;o), I guess pv_ops is what will be the outcome. Inside or 
outside
the linux kernel tree.

What I'd like to add is that I would prefer a better tagging of the 
kernel 
repo to identify subversion of the kernel that belong to a certain 
version 
of Xen, whatever kernel that might be. Fixes and improvements are 
happening
so quickly that on the pure user's side the combination can make a 
difference,
no matter how much effort you put in to keep it independent. 

BR,
Carsten.

Re: AW: Re: Re: Future of xenbits Linux trees

[Keir Fraser]

On 05/06/2009 18:58, "Carsten Schiers" <carsten@schiers.de> wrote:

> What I'd like to add is that I would prefer a better tagging of the
> kernel 
> repo to identify subversion of the kernel that belong to a certain
> version 
> of Xen, whatever kernel that might be. Fixes and improvements are
> happening
> so quickly that on the pure user's side the combination can make a
> difference,
> no matter how much effort you put in to keep it independent.

As I've said so many times, the kernel version and Xen version are *not*
tied. We don't do kernel releases tied to Xen versions, at all.

 -- Keir

AW: Re: AW: Re: Re: Future of xenbits Linux trees

[Carsten Schiers]

I know and it's not my decision. But my problems on TSC skew disappeared 
only
by using a combination of recent version pulled at approximately the 
same time. 

You might argue that cpufreq=dom0-kernel moves functionality that should 
belong
to xen into the Dom0 kernel. Yes, you're right. From that point of view 
I have
nothing to put in the balance.

BR,
Carsten.

-----Ursprüngliche Nachricht-----
Von: Keir Fraser [mailto:keir.fraser@eu.citrix.com] 
Gesendet: Freitag, 5. Juni 2009 20:49
An: Carsten Schiers; kraxel
Cc: chris.ace; jeremy; xen-devel; yamahata
Betreff: Re: AW: Re: [Xen-devel] Re: Future of xenbits Linux trees

On 05/06/2009 18:58, "Carsten Schiers" <carsten@schiers.de> wrote:

> What I'd like to add is that I would prefer a better tagging of the
> kernel 
> repo to identify subversion of the kernel that belong to a certain
> version 
> of Xen, whatever kernel that might be. Fixes and improvements are
> happening
> so quickly that on the pure user's side the combination can make a
> difference,
> no matter how much effort you put in to keep it independent.

As I've said so many times, the kernel version and Xen version are *not*
tied. We don't do kernel releases tied to Xen versions, at all.

 -- Keir

Re: Future of xenbits Linux trees

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 2187 bytes --]

>> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
>> and make it the main user tree. Development and automated testing would
. . . . . .

> This tree is not tied up with XCI at all.
> It can be taken as it and runs on the top of mainstream xen.

How to checkout this tree ?

Boris.

--- On Thu, 6/4/09, Jean Guyader <jean.guyader@gmail.com> wrote:

From: Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] Future of xenbits Linux trees
To: "Keir Fraser" <keir.fraser@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thursday, June 4, 2009, 12:09 PM

2009/6/4 Keir Fraser <keir.fraser@eu.citrix.com>:
> Folks,
>
> With 3.4 out the door it is time to revisit the state of our Linux
> repositories. Currently we have a number of trees in various states of
> maintenance:
>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> tested but increasingly long in the tooth.
>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> clones tree is not maintained or tested.
>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> Maintained as part of XCI project.
>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> tested, but incomplete.
>
> It is probably time to kill the 2.6.18 tree, or at least stop active
> development within it. It is increasingly a kludged collection of backports
> of more recent kernel patches, and is also missing a lot of drivers for more
> modern hardware.
>
> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> and make it the main user tree. Development and automated testing would
> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> to completely move onto at some point in the future).
>
> What do people think of this as a plan?
>

This tree is not tied up with XCI at all.
It can be taken as it and runs on the top of mainstream xen.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 2991 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Jean Guyader]

2009/6/4 Boris Derzhavets <bderzhavets@yahoo.com>:
>>> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
>>> and make it the main user tree. Development and automated testing would
> . . . . . .
>
>> This tree is not tied up with XCI at all.
>> It can be taken as it and runs on the top of mainstream xen.
>
> How to checkout this tree ?
>


$ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27.git
$ cd linux-2.6.27
$ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27-pq.git
.git/patches
$ guilt-push -a

Make sure you have a recent enough version of guilt, 0.30 has issue
with big patches.

Jean

Re: Future of xenbits Linux trees

[Keir Fraser]

On 04/06/2009 19:46, "Jean Guyader" <jean.guyader@gmail.com> wrote:

>> How to checkout this tree ?
>> 
> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27.git
> $ cd linux-2.6.27
> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27-pq.git
> .git/patches
> $ guilt-push -a
> 
> Make sure you have a recent enough version of guilt, 0.30 has issue
> with big patches.

The patchqueue is the XCI-specific bits, right? We'd just have a plain
non-patchqueued got tree for mainline development at least, I think.

 -- Keir

Re: Future of xenbits Linux trees

[Jean Guyader]

2009/6/4 Keir Fraser <keir.fraser@eu.citrix.com>:
> On 04/06/2009 19:46, "Jean Guyader" <jean.guyader@gmail.com> wrote:
>
>>> How to checkout this tree ?
>>>
>> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27.git
>> $ cd linux-2.6.27
>> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27-pq.git
>> .git/patches
>> $ guilt-push -a
>>
>> Make sure you have a recent enough version of guilt, 0.30 has issue
>> with big patches.
>
> The patchqueue is the XCI-specific bits, right? We'd just have a plain
> non-patchqueued got tree for mainline development at least, I think.
>

We have a patchqueue for fixes and new stuff but that make sence for
dev to have a non-patchqueued tree.

Jean

Re: Future of xenbits Linux trees

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 2558 bytes --]

Kernel 2.6.29 with Andy's rebased patches seems pretty stable in QA.

Boris.

--- On Fri, 6/5/09, Andrew Lyon <andrew.lyon@gmail.com> wrote:

From: Andrew Lyon <andrew.lyon@gmail.com>
Subject: Re: [Xen-devel] Future of xenbits Linux trees
To: "Keir Fraser" <keir.fraser@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Friday, June 5, 2009, 3:32 AM

On Thu, Jun 4, 2009 at 4:45 PM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> Folks,
>
> With 3.4 out the door it is time to revisit the state of our Linux
> repositories. Currently we have a number of trees in various states of
> maintenance:
>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> tested but increasingly long in the tooth.
>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> clones tree is not maintained or tested.
>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> Maintained as part of XCI project.
>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> tested, but incomplete.
>
> It is probably time to kill the 2.6.18 tree, or at least stop active
> development within it. It is increasingly a kludged collection of backports
> of more recent kernel patches, and is also missing a lot of drivers for more
> modern hardware.
>
> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> and make it the main user tree. Development and automated testing would
> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> to completely move onto at some point in the future).
>
> What do people think of this as a plan?
>
>  -- Keir

I think 2.6.27 is already out of date and you should start with 2.6.29
using my rebased patches, people have been using them since I did
2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
does, I'm sure that could be fixed but right now I dont know of any
issues with 2.6.29 at all, so why not make the jump to the current
stable kernel :).

XCI should update to 2.6.29 as well.

I use pci passthrough with a pci express usb2 card, I also use scsi
passthrough with a ultrium tape drive, usually running several windows
hvm's and a couple of 2.6.29 pv domU's as well, no problems.

Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 3366 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 1575 bytes --]

Kernel: arch/x86/boot/vmlinuz is ready  (#2)
ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko] undefined!
ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko] undefined!
ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
WARNING: modpost: Found 3 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Boris.

--- On Thu, 6/4/09, Jean Guyader <jean.guyader@gmail.com> wrote:

From: Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] Future of xenbits Linux trees
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Keir Fraser" <keir.fraser@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thursday, June 4, 2009, 2:46 PM

2009/6/4 Boris Derzhavets <bderzhavets@yahoo.com>:
>>> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
>>> and make it the main user tree. Development and automated testing would
> . . . . . .
>
>> This tree is not tied up with XCI at all.
>> It can be taken as it and runs on the top of mainstream xen.
>
> How to checkout this tree ?
>


$ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27.git
$ cd linux-2.6.27
$ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27-pq.git
.git/patches
$ guilt-push -a

Make sure you have a recent enough version of guilt, 0.30 has issue
with big patches.

Jean



      

[-- Attachment #1.2: Type: text/html, Size: 2291 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Genki Kuroda]

Hello, Boris,

I had the same error, but I was able to compile after commenting out
the "HACK ALERT" section in /drivers/acpi/ec.c
More information seems to be in wmi.c.

Who is taking care of this kind of issue? This is my first post...

Here is the patch to show where I commented out.

diff –git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 2359480..b2c0221 100644
— a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -387,6 +387,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
address, u8 * data)
/* HACK ALERT
* Please refer to wmi.c for an explanation on why we added this hack.
*/
+/*
if ( in_query_wmi_event_data == TRUE ) {
if ( address == 0×2b ) {
wmi_event_data_index = 0;
@@ -398,6 +399,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
address, u8 * data)
wmi_event_data_index++;
}
}
+*/

return result;
}


-- 
Genki Kuroda
E-mail: genkikuroda@gmail.com
Website: http://mulps.wordpress.com/

On Fri, Jun 5, 2009 at 12:53 AM, Boris Derzhavets<bderzhavets@yahoo.com> wrote:
> Kernel: arch/x86/boot/vmlinuz is ready  (#2)
> ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko] undefined!
> ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko] undefined!
> ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
> ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
> WARNING: modpost: Found 3 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> Boris.

RE: Future of xenbits Linux trees

[Kamala Narasimhan]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

The xen-acpi-wmi patch in XenClient linux 2.6.27 patch queue is tied to XenClient.  I didn't expect this patch to be used outside the scope of XenClient which is why you encounter the below issues.

Could you please momentarily exclude the patch before pushing the rest or revert it if already applied and then build that branch?  Going forward, I will create a XenClient flavor of wmi.c that won't step on the base wmi implementation and configure the two to be mutually exclusive.

Kamala

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Genki Kuroda
> Sent: Friday, June 05, 2009 7:06 PM
> To: Boris Derzhavets
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Future of xenbits Linux trees
> 
> Hello, Boris,
> 
> I had the same error, but I was able to compile after commenting out
> the "HACK ALERT" section in /drivers/acpi/ec.c
> More information seems to be in wmi.c.
> 
> Who is taking care of this kind of issue? This is my first post...
> 
> Here is the patch to show where I commented out.
> 
> diff –git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index 2359480..b2c0221 100644
> — a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -387,6 +387,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
> address, u8 * data)
> /* HACK ALERT
> * Please refer to wmi.c for an explanation on why we added this hack.
> */
> +/*
> if ( in_query_wmi_event_data == TRUE ) {
> if ( address == 0×2b ) {
> wmi_event_data_index = 0;
> @@ -398,6 +399,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
> address, u8 * data)
> wmi_event_data_index++;
> }
> }
> +*/
> 
> return result;
> }
> 
> 
> --
> Genki Kuroda
> E-mail: genkikuroda@gmail.com
> Website: http://mulps.wordpress.com/
> 
> On Fri, Jun 5, 2009 at 12:53 AM, Boris
> Derzhavets<bderzhavets@yahoo.com> wrote:
> > Kernel: arch/x86/boot/vmlinuz is ready  (#2)
> > ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko]
> undefined!
> > ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko]
> undefined!
> > ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
> > ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
> > WARNING: modpost: Found 3 section mismatch(es).
> > To see full details build your kernel with:
> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> > make[1]: *** [__modpost] Error 1
> > make: *** [modules] Error 2
> >
> > Boris.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Genki Kuroda]

Hi, Kamala,

Thank you for the information.
I didn't apply the patch, and I don't have any intention to apply the
patch for this issue.

GK

On Fri, Jun 5, 2009 at 7:17 PM, Kamala
Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
> The xen-acpi-wmi patch in XenClient linux 2.6.27 patch queue is tied to XenClient.  I didn't expect this patch to be used outside the scope of XenClient which is why you encounter the below issues.
>
> Could you please momentarily exclude the patch before pushing the rest or revert it if already applied and then build that branch?  Going forward, I will create a XenClient flavor of wmi.c that won't step on the base wmi implementation and configure the two to be mutually exclusive.
>
> Kamala
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>> bounces@lists.xensource.com] On Behalf Of Genki Kuroda
>> Sent: Friday, June 05, 2009 7:06 PM
>> To: Boris Derzhavets
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] Future of xenbits Linux trees
>>
>> Hello, Boris,
>>
>> I had the same error, but I was able to compile after commenting out
>> the "HACK ALERT" section in /drivers/acpi/ec.c
>> More information seems to be in wmi.c.
>>
>> Who is taking care of this kind of issue? This is my first post...
>>
>> Here is the patch to show where I commented out.
>>
>> diff –git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
>> index 2359480..b2c0221 100644
>> — a/drivers/acpi/ec.c
>> +++ b/drivers/acpi/ec.c
>> @@ -387,6 +387,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>> address, u8 * data)
>> /* HACK ALERT
>> * Please refer to wmi.c for an explanation on why we added this hack.
>> */
>> +/*
>> if ( in_query_wmi_event_data == TRUE ) {
>> if ( address == 0×2b ) {
>> wmi_event_data_index = 0;
>> @@ -398,6 +399,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>> address, u8 * data)
>> wmi_event_data_index++;
>> }
>> }
>> +*/
>>
>> return result;
>> }
>>
>>
>> --
>> Genki Kuroda
>> E-mail: genkikuroda@gmail.com
>> Website: http://mulps.wordpress.com/
>>
>> On Fri, Jun 5, 2009 at 12:53 AM, Boris
>> Derzhavets<bderzhavets@yahoo.com> wrote:
>> > Kernel: arch/x86/boot/vmlinuz is ready  (#2)
>> > ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko]
>> undefined!
>> > ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko]
>> undefined!
>> > ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
>> > ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
>> > WARNING: modpost: Found 3 section mismatch(es).
>> > To see full details build your kernel with:
>> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>> > make[1]: *** [__modpost] Error 1
>> > make: *** [modules] Error 2
>> >
>> > Boris.
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>

RE: Future of xenbits Linux trees

[Kamala Narasimhan]

[-- Attachment #1: Type: text/plain, Size: 3604 bytes --]

Just to clarify - You mean you encounter wmi build issues mentioned below with XenClient Linux 2.6.27 even when you *don't* apply the xen-acpi-wmi patch from XenClient Linux 2.6.27 patch queue?

Kamala

> -----Original Message-----
> From: Genki Kuroda [mailto:sfsugar@gmail.com]
> Sent: Friday, June 05, 2009 10:48 PM
> To: Kamala Narasimhan
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Future of xenbits Linux trees
> 
> Hi, Kamala,
> 
> Thank you for the information.
> I didn't apply the patch, and I don't have any intention to apply the
> patch for this issue.
> 
> GK
> 
> On Fri, Jun 5, 2009 at 7:17 PM, Kamala
> Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
> > The xen-acpi-wmi patch in XenClient linux 2.6.27 patch queue is tied
> to XenClient.  I didn't expect this patch to be used outside the scope
> of XenClient which is why you encounter the below issues.
> >
> > Could you please momentarily exclude the patch before pushing the
> rest or revert it if already applied and then build that branch?  Going
> forward, I will create a XenClient flavor of wmi.c that won't step on
> the base wmi implementation and configure the two to be mutually
> exclusive.
> >
> > Kamala
> >
> >> -----Original Message-----
> >> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> >> bounces@lists.xensource.com] On Behalf Of Genki Kuroda
> >> Sent: Friday, June 05, 2009 7:06 PM
> >> To: Boris Derzhavets
> >> Cc: xen-devel@lists.xensource.com
> >> Subject: Re: [Xen-devel] Future of xenbits Linux trees
> >>
> >> Hello, Boris,
> >>
> >> I had the same error, but I was able to compile after commenting out
> >> the "HACK ALERT" section in /drivers/acpi/ec.c
> >> More information seems to be in wmi.c.
> >>
> >> Who is taking care of this kind of issue? This is my first post...
> >>
> >> Here is the patch to show where I commented out.
> >>
> >> diff –git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> >> index 2359480..b2c0221 100644
> >> — a/drivers/acpi/ec.c
> >> +++ b/drivers/acpi/ec.c
> >> @@ -387,6 +387,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
> >> address, u8 * data)
> >> /* HACK ALERT
> >> * Please refer to wmi.c for an explanation on why we added this
> hack.
> >> */
> >> +/*
> >> if ( in_query_wmi_event_data == TRUE ) {
> >> if ( address == 0×2b ) {
> >> wmi_event_data_index = 0;
> >> @@ -398,6 +399,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
> >> address, u8 * data)
> >> wmi_event_data_index++;
> >> }
> >> }
> >> +*/
> >>
> >> return result;
> >> }
> >>
> >>
> >> --
> >> Genki Kuroda
> >> E-mail: genkikuroda@gmail.com
> >> Website: http://mulps.wordpress.com/
> >>
> >> On Fri, Jun 5, 2009 at 12:53 AM, Boris
> >> Derzhavets<bderzhavets@yahoo.com> wrote:
> >> > Kernel: arch/x86/boot/vmlinuz is ready  (#2)
> >> > ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko]
> >> undefined!
> >> > ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko]
> >> undefined!
> >> > ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
> >> > ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
> >> > WARNING: modpost: Found 3 section mismatch(es).
> >> > To see full details build your kernel with:
> >> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> >> > make[1]: *** [__modpost] Error 1
> >> > make: *** [modules] Error 2
> >> >
> >> > Boris.
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> >

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Genki Kuroda]

Hi Kamala,

I encountered the wmi build issues after applying the linux-2.6.27-pq.git
I have no idea on what happens before applying the linux-2.6.27-pq.git

All I did was:

$ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27.git
$ cd linux-2.6.27
$ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27-pq.git
.git/patches
$ guilt-push -a
$ make --> wmi build issues.

GK

On Fri, Jun 5, 2009 at 7:53 PM, Kamala
Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
> Just to clarify - You mean you encounter wmi build issues mentioned below with XenClient Linux 2.6.27 even when you *don't* apply the xen-acpi-wmi patch from XenClient Linux 2.6.27 patch queue?
>
> Kamala
>
>> -----Original Message-----
>> From: Genki Kuroda [mailto:sfsugar@gmail.com]
>> Sent: Friday, June 05, 2009 10:48 PM
>> To: Kamala Narasimhan
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] Future of xenbits Linux trees
>>
>> Hi, Kamala,
>>
>> Thank you for the information.
>> I didn't apply the patch, and I don't have any intention to apply the
>> patch for this issue.
>>
>> GK
>>
>> On Fri, Jun 5, 2009 at 7:17 PM, Kamala
>> Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
>> > The xen-acpi-wmi patch in XenClient linux 2.6.27 patch queue is tied
>> to XenClient.  I didn't expect this patch to be used outside the scope
>> of XenClient which is why you encounter the below issues.
>> >
>> > Could you please momentarily exclude the patch before pushing the
>> rest or revert it if already applied and then build that branch?  Going
>> forward, I will create a XenClient flavor of wmi.c that won't step on
>> the base wmi implementation and configure the two to be mutually
>> exclusive.
>> >
>> > Kamala
>> >
>> >> -----Original Message-----
>> >> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>> >> bounces@lists.xensource.com] On Behalf Of Genki Kuroda
>> >> Sent: Friday, June 05, 2009 7:06 PM
>> >> To: Boris Derzhavets
>> >> Cc: xen-devel@lists.xensource.com
>> >> Subject: Re: [Xen-devel] Future of xenbits Linux trees
>> >>
>> >> Hello, Boris,
>> >>
>> >> I had the same error, but I was able to compile after commenting out
>> >> the "HACK ALERT" section in /drivers/acpi/ec.c
>> >> More information seems to be in wmi.c.
>> >>
>> >> Who is taking care of this kind of issue? This is my first post...
>> >>
>> >> Here is the patch to show where I commented out.
>> >>
>> >> diff –git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
>> >> index 2359480..b2c0221 100644
>> >> — a/drivers/acpi/ec.c
>> >> +++ b/drivers/acpi/ec.c
>> >> @@ -387,6 +387,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>> >> address, u8 * data)
>> >> /* HACK ALERT
>> >> * Please refer to wmi.c for an explanation on why we added this
>> hack.
>> >> */
>> >> +/*
>> >> if ( in_query_wmi_event_data == TRUE ) {
>> >> if ( address == 0×2b ) {
>> >> wmi_event_data_index = 0;
>> >> @@ -398,6 +399,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>> >> address, u8 * data)
>> >> wmi_event_data_index++;
>> >> }
>> >> }
>> >> +*/
>> >>
>> >> return result;
>> >> }
>> >>
>> >>
>> >> --
>> >> Genki Kuroda
>> >> E-mail: genkikuroda@gmail.com
>> >> Website: http://mulps.wordpress.com/
>> >>
>> >> On Fri, Jun 5, 2009 at 12:53 AM, Boris
>> >> Derzhavets<bderzhavets@yahoo.com> wrote:
>> >> > Kernel: arch/x86/boot/vmlinuz is ready  (#2)
>> >> > ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko]
>> >> undefined!
>> >> > ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko]
>> >> undefined!
>> >> > ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
>> >> > ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
>> >> > WARNING: modpost: Found 3 section mismatch(es).
>> >> > To see full details build your kernel with:
>> >> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>> >> > make[1]: *** [__modpost] Error 1
>> >> > make: *** [modules] Error 2
>> >> >
>> >> > Boris.
>> >>
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> Xen-devel@lists.xensource.com
>> >> http://lists.xensource.com/xen-devel
>> >
>

Re: Future of xenbits Linux trees

[Jean Guyader]

You can disable all the wmi-XCI patch by openning the series file
(.git/patches/master/serie)
and comment out the entry for this patch at the end of the file. Then
you do a guilt-pop -a && guilt-push -a.

2009/6/6 Genki Kuroda <sfsugar@gmail.com>:
> Hi Kamala,
>
> I encountered the wmi build issues after applying the linux-2.6.27-pq.git
> I have no idea on what happens before applying the linux-2.6.27-pq.git
>
> All I did was:
>
> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27.git
> $ cd linux-2.6.27
> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27-pq.git
> .git/patches
> $ guilt-push -a
> $ make --> wmi build issues.
>
> GK
>
> On Fri, Jun 5, 2009 at 7:53 PM, Kamala
> Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
>> Just to clarify - You mean you encounter wmi build issues mentioned below with XenClient Linux 2.6.27 even when you *don't* apply the xen-acpi-wmi patch from XenClient Linux 2.6.27 patch queue?
>>
>> Kamala
>>
>>> -----Original Message-----
>>> From: Genki Kuroda [mailto:sfsugar@gmail.com]
>>> Sent: Friday, June 05, 2009 10:48 PM
>>> To: Kamala Narasimhan
>>> Cc: xen-devel@lists.xensource.com
>>> Subject: Re: [Xen-devel] Future of xenbits Linux trees
>>>
>>> Hi, Kamala,
>>>
>>> Thank you for the information.
>>> I didn't apply the patch, and I don't have any intention to apply the
>>> patch for this issue.
>>>
>>> GK
>>>
>>> On Fri, Jun 5, 2009 at 7:17 PM, Kamala
>>> Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
>>> > The xen-acpi-wmi patch in XenClient linux 2.6.27 patch queue is tied
>>> to XenClient.  I didn't expect this patch to be used outside the scope
>>> of XenClient which is why you encounter the below issues.
>>> >
>>> > Could you please momentarily exclude the patch before pushing the
>>> rest or revert it if already applied and then build that branch?  Going
>>> forward, I will create a XenClient flavor of wmi.c that won't step on
>>> the base wmi implementation and configure the two to be mutually
>>> exclusive.
>>> >
>>> > Kamala
>>> >
>>> >> -----Original Message-----
>>> >> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>>> >> bounces@lists.xensource.com] On Behalf Of Genki Kuroda
>>> >> Sent: Friday, June 05, 2009 7:06 PM
>>> >> To: Boris Derzhavets
>>> >> Cc: xen-devel@lists.xensource.com
>>> >> Subject: Re: [Xen-devel] Future of xenbits Linux trees
>>> >>
>>> >> Hello, Boris,
>>> >>
>>> >> I had the same error, but I was able to compile after commenting out
>>> >> the "HACK ALERT" section in /drivers/acpi/ec.c
>>> >> More information seems to be in wmi.c.
>>> >>
>>> >> Who is taking care of this kind of issue? This is my first post...
>>> >>
>>> >> Here is the patch to show where I commented out.
>>> >>
>>> >> diff –git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
>>> >> index 2359480..b2c0221 100644
>>> >> — a/drivers/acpi/ec.c
>>> >> +++ b/drivers/acpi/ec.c
>>> >> @@ -387,6 +387,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>>> >> address, u8 * data)
>>> >> /* HACK ALERT
>>> >> * Please refer to wmi.c for an explanation on why we added this
>>> hack.
>>> >> */
>>> >> +/*
>>> >> if ( in_query_wmi_event_data == TRUE ) {
>>> >> if ( address == 0×2b ) {
>>> >> wmi_event_data_index = 0;
>>> >> @@ -398,6 +399,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>>> >> address, u8 * data)
>>> >> wmi_event_data_index++;
>>> >> }
>>> >> }
>>> >> +*/
>>> >>
>>> >> return result;
>>> >> }
>>> >>
>>> >>
>>> >> --
>>> >> Genki Kuroda
>>> >> E-mail: genkikuroda@gmail.com
>>> >> Website: http://mulps.wordpress.com/
>>> >>
>>> >> On Fri, Jun 5, 2009 at 12:53 AM, Boris
>>> >> Derzhavets<bderzhavets@yahoo.com> wrote:
>>> >> > Kernel: arch/x86/boot/vmlinuz is ready  (#2)
>>> >> > ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko]
>>> >> undefined!
>>> >> > ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko]
>>> >> undefined!
>>> >> > ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
>>> >> > ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
>>> >> > WARNING: modpost: Found 3 section mismatch(es).
>>> >> > To see full details build your kernel with:
>>> >> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>>> >> > make[1]: *** [__modpost] Error 1
>>> >> > make: *** [modules] Error 2
>>> >> >
>>> >> > Boris.
>>> >>
>>> >> _______________________________________________
>>> >> Xen-devel mailing list
>>> >> Xen-devel@lists.xensource.com
>>> >> http://lists.xensource.com/xen-devel
>>> >
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: Future of xenbits Linux trees

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 164 bytes --]

> Hi Andy,
>Where could I get this 2.6.29 from?
>Thanks,
> Jean

wget http://gentoo-xen-kernel.googlecode.com/files/xen-patches-2.6.29-6.tar.bz2

Boris






      

[-- Attachment #1.2: Type: text/html, Size: 485 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 6844 bytes --]

Works fine.

root@SeverUbuntuJaunty:~# xm info
host                   : SeverUbuntuJaunty
release                : 2.6.27.19-5.1
version                : #1 SMP Sat Jun 6 23:35:05 MSD 2009
machine                : x86_64
nr_cpus                : 4
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 2833
hw_caps                : bfebfbff:20100800:00000000:00000140:0408e3fd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 8191
free_memory            : 7
node_to_cpu            : node0:0-3
node_to_memory         : node0:7
xen_major              : 3
xen_minor              : 4
xen_extra              : .1-rc1-pre
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : Mon Jun 01 14:56:17 2009 +0100 19628:29d7e3522cc5
cc_compiler            : gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) 
cc_compile_by          : root
cc_compile_domain      : 
cc_compile_date        : Thu Jun  4 07:24:19 EDT 2009
xend_config_format     : 4

Boris.

--- On Sat, 6/6/09, Jean Guyader <jean.guyader@gmail.com> wrote:

From: Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] Future of xenbits Linux trees
To: "Genki Kuroda" <sfsugar@gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kamala Narasimhan" <Kamala.Narasimhan@citrix.com>
Date: Saturday, June 6, 2009, 5:54 AM

You can disable all the wmi-XCI patch by openning the series file
(.git/patches/master/serie)
and comment out the entry for this patch at the end of the file. Then
you do a guilt-pop -a && guilt-push -a.

2009/6/6 Genki Kuroda <sfsugar@gmail.com>:
> Hi Kamala,
>
> I encountered the wmi build issues after applying the linux-2.6.27-pq.git
> I have no idea on what happens before applying the linux-2.6.27-pq.git
>
> All I did was:
>
> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27.git
> $ cd linux-2.6.27
> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27-pq.git
> .git/patches
> $ guilt-push -a
> $ make --> wmi build issues.
>
> GK
>
> On Fri, Jun 5, 2009 at 7:53 PM, Kamala
> Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
>> Just to clarify - You mean you encounter wmi build issues mentioned below with XenClient Linux 2.6.27 even when you *don't* apply the xen-acpi-wmi patch from XenClient Linux 2.6.27 patch queue?
>>
>> Kamala
>>
>>> -----Original Message-----
>>> From: Genki Kuroda [mailto:sfsugar@gmail.com]
>>> Sent: Friday, June 05, 2009 10:48 PM
>>> To: Kamala Narasimhan
>>> Cc: xen-devel@lists.xensource.com
>>> Subject: Re: [Xen-devel] Future of xenbits Linux trees
>>>
>>> Hi, Kamala,
>>>
>>> Thank you for the information.
>>> I didn't apply the patch, and I don't have any intention to apply the
>>> patch for this issue.
>>>
>>> GK
>>>
>>> On Fri, Jun 5, 2009 at 7:17 PM, Kamala
>>> Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
>>> > The xen-acpi-wmi patch in XenClient linux 2.6.27 patch queue is tied
>>> to XenClient.  I didn't expect this patch to be used outside the scope
>>> of XenClient which is why you encounter the below issues.
>>> >
>>> > Could you please momentarily exclude the patch before pushing the
>>> rest or revert it if already applied and then build that branch?  Going
>>> forward, I will create a XenClient flavor of wmi.c that won't step on
>>> the base wmi implementation and configure the two to be mutually
>>> exclusive.
>>> >
>>> > Kamala
>>> >
>>> >> -----Original Message-----
>>> >> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>>> >> bounces@lists.xensource.com] On Behalf Of Genki Kuroda
>>> >> Sent: Friday, June 05, 2009 7:06 PM
>>> >> To: Boris Derzhavets
>>> >> Cc: xen-devel@lists.xensource.com
>>> >> Subject: Re: [Xen-devel] Future of xenbits Linux trees
>>> >>
>>> >> Hello, Boris,
>>> >>
>>> >> I had the same error, but I was able to compile after commenting out
>>> >> the "HACK ALERT" section in /drivers/acpi/ec.c
>>> >> More information seems to be in wmi.c.
>>> >>
>>> >> Who is taking care of this kind of issue? This is my first post...
>>> >>
>>> >> Here is the patch to show where I commented out.
>>> >>
>>> >> diff –git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
>>> >> index 2359480..b2c0221 100644
>>> >> — a/drivers/acpi/ec.c
>>> >> +++ b/drivers/acpi/ec.c
>>> >> @@ -387,6 +387,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>>> >> address, u8 * data)
>>> >> /* HACK ALERT
>>> >> * Please refer to wmi.c for an explanation on why we added this
>>> hack.
>>> >> */
>>> >> +/*
>>> >> if ( in_query_wmi_event_data == TRUE ) {
>>> >> if ( address == 0×2b ) {
>>> >> wmi_event_data_index = 0;
>>> >> @@ -398,6 +399,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>>> >> address, u8 * data)
>>> >> wmi_event_data_index++;
>>> >> }
>>> >> }
>>> >> +*/
>>> >>
>>> >> return result;
>>> >> }
>>> >>
>>> >>
>>> >> --
>>> >> Genki Kuroda
>>> >> E-mail: genkikuroda@gmail.com
>>> >> Website: http://mulps.wordpress.com/
>>> >>
>>> >> On Fri, Jun 5, 2009 at 12:53 AM, Boris
>>> >> Derzhavets<bderzhavets@yahoo.com> wrote:
>>> >> > Kernel: arch/x86/boot/vmlinuz is ready  (#2)
>>> >> > ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko]
>>> >> undefined!
>>> >> > ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko]
>>> >> undefined!
>>> >> > ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
>>> >> > ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
>>> >> > WARNING: modpost: Found 3 section mismatch(es).
>>> >> > To see full details build your kernel with:
>>> >> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>>> >> > make[1]: *** [__modpost] Error 1
>>> >> > make: *** [modules] Error 2
>>> >> >
>>> >> > Boris.
>>> >>
>>> >> _______________________________________________
>>> >> Xen-devel mailing list
>>> >> Xen-devel@lists.xensource.com
>>> >> http://lists.xensource.com/xen-devel
>>> >
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 12028 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel