Mailing List Archive

On Wed, Jan 11, 2006 at 10:42:29AM +0100, Jan Beulich wrote:
> I just updated my local tree, and saw over a thousand changesets. Where's that coming from? Did you do a partial early
> 2.6.16 import? If so, why isn't that reflected in the top level Makefile? Thanks, Jan

I update the merge tree to the kernel.org tree about once or twice
a week. On the last update, there were almost 1000 changes but no
change to the top level Makefile yet.

christian


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

>>> Christian Limpach <Christian.Limpach@cl.cam.ac.uk> 11.01.06 10:51:16 >>>
>On Wed, Jan 11, 2006 at 10:42:29AM +0100, Jan Beulich wrote:
>> I just updated my local tree, and saw over a thousand changesets. Where's that coming from? Did you do a partial
early
>> 2.6.16 import? If so, why isn't that reflected in the top level Makefile? Thanks, Jan
>
>I update the merge tree to the kernel.org tree about once or twice
>a week. On the last update, there were almost 1000 changes but no
>change to the top level Makefile yet.

Then how would I identify the kernel.org baseline that the merge tree uses at a given point in time?

Jan

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

On Wed, Jan 11, 2006 at 11:32:05AM +0100, Jan Beulich wrote:
> >>> Christian Limpach <Christian.Limpach@cl.cam.ac.uk> 11.01.06 10:51:16 >>>
> >On Wed, Jan 11, 2006 at 10:42:29AM +0100, Jan Beulich wrote:
> >> I just updated my local tree, and saw over a thousand changesets. Where's that coming from? Did you do a partial
> early
> >> 2.6.16 import? If so, why isn't that reflected in the top level Makefile? Thanks, Jan
> >
> >I update the merge tree to the kernel.org tree about once or twice
> >a week. On the last update, there were almost 1000 changes but no
> >change to the top level Makefile yet.
>
> Then how would I identify the kernel.org baseline that the merge tree uses at a given point in time?

Not 100% sure what you mean -- I pull from the
http://www.kernel.org/hg/linux-2.6 repository, I guess the baseline
is the latest changeset from that tree, which would be one of the
parents of the latest changeset with the "Merge with Linux trunk."
checkin message. It should also be the latest changeset on the
branch from the latest Linux tag in the repository (currently v2.6.15)

christian


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

>> Then how would I identify the kernel.org baseline that the merge tree uses at a given point in time?
>
>Not 100% sure what you mean -- I pull from the
>http://www.kernel.org/hg/linux-2.6 repository, I guess the baseline
>is the latest changeset from that tree, which would be one of the
>parents of the latest changeset with the "Merge with Linux trunk."
>checkin message. It should also be the latest changeset on the
>branch from the latest Linux tag in the repository (currently v2.6.15)

The underlying problem is that in order to use the Xen changes in SLES10, we need to have them in patch form. That
means we need to have a way to generate one or more patches that collectively represent exactly the changes Xen does on
top of kernel.org. To generate such a patch it would be very helpful to have precise knowledge on the underlying
kernel.org tree; without that it would mean we'd have to compare to kernel.org 2.6.15 (or some of the 2.6.15-git*
snapshots) and then go through the resulting patch(es) and remove everything that originates from kernel.org - obviously
quite a tedious and error prone task.

Of course, I'm in no way a mercurial expert, so I might easily not know of a simple way to obtain what we need.

Jan

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

On Wed, Jan 11, 2006 at 06:25:40PM +0100, Jan Beulich wrote:
> >> Then how would I identify the kernel.org baseline that the merge tree uses at a given point in time?
> >
> >Not 100% sure what you mean -- I pull from the
> >http://www.kernel.org/hg/linux-2.6 repository, I guess the baseline
> >is the latest changeset from that tree, which would be one of the
> >parents of the latest changeset with the "Merge with Linux trunk."
> >checkin message. It should also be the latest changeset on the
> >branch from the latest Linux tag in the repository (currently v2.6.15)
>
> The underlying problem is that in order to use the Xen changes in SLES10, we need to have them in patch form. That
> means we need to have a way to generate one or more patches that collectively represent exactly the changes Xen does on
> top of kernel.org. To generate such a patch it would be very helpful to have precise knowledge on the underlying
> kernel.org tree; without that it would mean we'd have to compare to kernel.org 2.6.15 (or some of the 2.6.15-git*
> snapshots) and then go through the resulting patch(es) and remove everything that originates from kernel.org - obviously
> quite a tedious and error prone task.

You might be better off using the linux-2.6-xen.hg tree then which is based
on 2.6.15. (http://xenbits.xensource.com/linux-2.6-xen.hg)

christian


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

> You might be better off using the linux-2.6-xen.hg tree then
> which is based
> on 2.6.15. (http://xenbits.xensource.com/linux-2.6-xen.hg)

Reminds me... Is there any plan or schedule for (or list of tasks
to be done before) this tree gets merged back into xen-unstable
(if ever)? Now that it is 2.6.15 and xen-unstable -sparse is
2.6.12, it seems overdue.

Reason: I will eventually need to get the ia64 changes into
one tree or the other and don't want to be surprised when/if
the -sparse tree suddenly no longer has Xen/ia64 support.

Thanks,
Dan

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

> > You might be better off using the linux-2.6-xen.hg tree
> then which is
> > based on 2.6.15. (http://xenbits.xensource.com/linux-2.6-xen.hg)
>
> Reminds me... Is there any plan or schedule for (or list of
> tasks to be done before) this tree gets merged back into
> xen-unstable (if ever)? Now that it is 2.6.15 and
> xen-unstable -sparse is 2.6.12, it seems overdue.

There's a known x86_64 dom0 regression that is proving a very slow
process to track down -- NIC interrupts seem to occasionally lock up,
requiring the tx watchdog to run and recover the card. I suspect it's a
latent ioapic problem.

It's almost worth checking it in so we get some help debugging it...
The plan is to get it in as soon as its stable.

Ian

> Reason: I will eventually need to get the ia64 changes into
> one tree or the other and don't want to be surprised when/if
> the -sparse tree suddenly no longer has Xen/ia64 support.
>
> Thanks,
> Dan
>
> _______________________________________________
> Xen-merge mailing list
> Xen-merge@lists.xensource.com
> http://lists.xensource.com/xen-merge
>

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

Hi,

On Wed, 2006-01-11 at 18:25 +0100, Jan Beulich wrote:

> The underlying problem is that in order to use the Xen changes in
> SLES10, we need to have them in patch form. That means we need to have
> a way to generate one or more patches that collectively represent
> exactly the changes Xen does on top of kernel.org. To generate such a
> patch it would be very helpful to have precise knowledge on the
> underlying kernel.org tree;

That knowledge is already there in the linux-2.6-merge.hg tree.

That tree is based off the linux-2.6.hg mercurial tree that gets
mirrored from the master git repository (the hg tree is at
http://www.kernel.org/hg/linux-2.6/ if you want to track it.) To move
to a newer 2.6 base, that upstream 2.6 hg tree just gets pulled into the
-merge tree. So all of the changesets from upstream are already there
in the -merge tree.

Looking at the -merge tree from a pull just a moment ago, the top
changesets I can see are:

2 merge changesets bringing xen-unstable fixes into -merge
3 fixes from -unstable
2 merge changesets bringing in the linux-2.6.hg upstream tree

then this one:

changeset: 18601:c90267e4a29b47d40fa4cb968be75670c8cdb703
parent: 18579:7897f5a689c4c91cb6c4b7e99f7f723a224f6310
parent: 18600:367dadf1afbca21e0bd27af57f17d5e60c348318
user: Linus Torvalds <torvalds@g5.osdl.org>
date: Wed Jan 11 13:31:24 2006 +0800
files:
description:
Merge
master.kernel.org:/pub/scm/linux/kernel/git/kyle/parisc-2.6

which is a genuine upstream cset from the 2.6 main hg tree. If you hg
clone the 2.6 tree, you'll be able to find the cset with that hash in
there (though with a different hg cset number: the number on the left of
the ":" in the changeset ID is the sequence number that's local to this
repository, but the hash on the RHS is a unique ID for the changeset
that should be constant whatever repository the cset gets pulled into.)

So, after finding the most recent upstream 2.6 cset in the -merge tree,
it's trivial to generate a Xen diff against that; in this case it was
cset number 18601 so:

$ hg diff -r 18601 -r tip > /tmp/linux-2.6-merge.patch

will do it for you.

Of course, that gives you a patch against a very specific upstream
revision, but in general I've found that any conflicts if you apply it
to a different relatively-recent kernel base are usually pretty minor
and easy to resolve.

--Stephen



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