http://www.xensource.com/xen/downloads/index.html The XenSource site seems to think so but I haven''t seen an announcement here. Is rc4 tag the same changeset for 3.0.3? Regards, Anthony Liguori _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
18 Eki 2006 Çar 00:06 tarihinde, Anthony Liguori şunları yazmıştı:> http://www.xensource.com/xen/downloads/index.html > > The XenSource site seems to think so but I haven''t seen an announcement > here. Is rc4 tag the same changeset for 3.0.3?It seems (i already downloaded and prepared a package) rc5 tag is the same changeset for 3.0.3. -- S.Çağlar Onur <caglar@pardus.org.tr> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 17/10/06 11:02 pm, "John Levon" <levon@movementarian.org> wrote:>> We''ve just released in fact - the xen-3.0.3-testing.hg has been updated >> with a new version number and mercurial tag. You obviously hit the >> unsynchronized website/hg update window of small-ness. > > It has 3.0.3-rc5 as its tag and Makefile version. Shouldn''t this be > "3.0.3" ?It''ll take a few hours for the change to run our regression tests and get pushed to the public tree. Every changeset goes to an internal staging tree in the first instance. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 17/10/06 11:01 pm, "Aron Griffis" <aron@hp.com> wrote:> Will xen-unstable move forward to (at least) 2.6.18 now?This is certainly planned before 3.0.4.> Will the tree structure change from the current sparse model to > a fully-populated kernel? IMHO it wouldn''t be too hard to use > something similar to > http://xenbits.xensource.com/ext/linux-2.6.tip-xen.hg plus a top-level > xen directory containing the hypervisor. Alternatively, since Xen > isn''t just Linux, maybe the hypervisor and kernels should be in > separate repositories?Perhaps. We might at least separate the kernel bits from the hypervisor bits. We like working with a sparse tree as it''s much quicker than cloning entire Linux repos. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>http://www.xensource.com/xen/downloads/index.html > >The XenSource site seems to think so but I haven''t seen an announcement >here. Is rc4 tag the same changeset for 3.0.3?We''ve just released in fact - the xen-3.0.3-testing.hg has been updated with a new version number and mercurial tag. You obviously hit the unsynchronized website/hg update window of small-ness. Ian has sent (is sending) an announce email now. Please try out 3.0.3-0; we rely on your feedback to make these stable releases of Xen as good as possible! cheers, S. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
And a couple follow-up questions... Will xen-unstable move forward to (at least) 2.6.18 now? Will the tree structure change from the current sparse model to a fully-populated kernel? IMHO it wouldn''t be too hard to use something similar to http://xenbits.xensource.com/ext/linux-2.6.tip-xen.hg plus a top-level xen directory containing the hypervisor. Alternatively, since Xen isn''t just Linux, maybe the hypervisor and kernels should be in separate repositories? Aron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Oct 17, 2006 at 10:57:28PM +0100, Steven Hand wrote:> >http://www.xensource.com/xen/downloads/index.html > > > >The XenSource site seems to think so but I haven''t seen an announcement > >here. Is rc4 tag the same changeset for 3.0.3? > > We''ve just released in fact - the xen-3.0.3-testing.hg has been updated > with a new version number and mercurial tag. You obviously hit the > unsynchronized website/hg update window of small-ness.It has 3.0.3-rc5 as its tag and Makefile version. Shouldn''t this be "3.0.3" ? xenbld:xen-3.0.3-testing-ref.hg $ hg tip | grep changeset changeset: 11772:b2f2b7738aa2 xenbld:xen-3.0.3-testing-ref.hg $ hg pull -uv pulling from http://xenbits.xensource.com/xen-3.0.3-testing.hg searching for changes no changes found regards john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> On 17/10/06 11:02 pm, "John Levon" <levon@movementarian.org> wrote: > >>> We''ve just released in fact - the xen-3.0.3-testing.hg has been updated >>> with a new version number and mercurial tag. You obviously hit the >>> unsynchronized website/hg update window of small-ness. >> It has 3.0.3-rc5 as its tag and Makefile version. Shouldn''t this be >> "3.0.3" ? > > It''ll take a few hours for the change to run our regression tests and get > pushed to the public tree. Every changeset goes to an internal staging tree > in the first instance.Then why not wait until it hits the public tree to send an announce? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote: [Tue Oct 17 2006, 05:55:20PM EDT]> > Will the tree structure change from the current sparse model to > > a fully-populated kernel? IMHO it wouldn''t be too hard to use > > something similar to > > http://xenbits.xensource.com/ext/linux-2.6.tip-xen.hg plus a top-level > > xen directory containing the hypervisor. Alternatively, since Xen > > isn''t just Linux, maybe the hypervisor and kernels should be in > > separate repositories? > > Perhaps. We might at least separate the kernel bits from the > hypervisor bits. We like working with a sparse tree as it''s much > quicker than cloning entire Linux repos.I suppose xen/include/public synchronization also poses a challenge, unless it''s okay for the kernel to #include files outside of the kernel tree. Aron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>>> We''ve just released in fact - the xen-3.0.3-testing.hg has been updated >>>> with a new version number and mercurial tag. You obviously hit the >>>> unsynchronized website/hg update window of small-ness. >>> It has 3.0.3-rc5 as its tag and Makefile version. Shouldn''t this be >>> "3.0.3" ? >> >> It''ll take a few hours for the change to run our regression tests and get >> pushed to the public tree. Every changeset goes to an internal staging >> tree >> in the first instance. > > Then why not wait until it hits the public tree to send an announce?Everything has hit the public tree now. cheers, S. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Oct 17, 2006 at 11:32:13PM +0100, Steven Hand wrote:> >>>>We''ve just released in fact - the xen-3.0.3-testing.hg has been updated > >>>>with a new version number and mercurial tag. You obviously hit the > >>>>unsynchronized website/hg update window of small-ness. > >>>It has 3.0.3-rc5 as its tag and Makefile version. Shouldn''t this be > >>>"3.0.3" ? > >> > >>It''ll take a few hours for the change to run our regression tests and get > >>pushed to the public tree. Every changeset goes to an internal staging > >>tree > >>in the first instance. > > > >Then why not wait until it hits the public tree to send an announce? > > Everything has hit the public tree now. >http://www.cl.cam.ac.uk/research/srg/netos/xen/ http://www.cl.cam.ac.uk/research/srg/netos/xen/downloads.html Still have 3.0.2 stuff.. -- Pasi ^ . . Linux / - \ Choice.of.the .Next.Generation. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> Everything has hit the public tree now. >> > > http://www.cl.cam.ac.uk/research/srg/netos/xen/ > http://www.cl.cam.ac.uk/research/srg/netos/xen/downloads.html > > Still have 3.0.2 stuff..Thanks - now fixed. cheers, S. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:> On 17/10/06 11:01 pm, "Aron Griffis" <aron@hp.com> wrote: > >> Will xen-unstable move forward to (at least) 2.6.18 now? > > This is certainly planned before 3.0.4.Do you expect it to fall behind again during the development cycle, and how much?>> Will the tree structure change from the current sparse model to >> a fully-populated kernel? IMHO it wouldn''t be too hard to use >> something similar to >> http://xenbits.xensource.com/ext/linux-2.6.tip-xen.hg plus a top-level >> xen directory containing the hypervisor. Alternatively, since Xen >> isn''t just Linux, maybe the hypervisor and kernels should be in >> separate repositories? > > Perhaps. We might at least separate the kernel bits from the hypervisor > bits. We like working with a sparse tree as it''s much quicker than cloning > entire Linux repos.Ahem. Isn''t there enough suffering in the world? The sparse tree has been an enourmous pain in the neck for me and many others. If all that pain is outweighed by quicker cloning of Linux repos, then you must do that much more often than I can imagine. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18/10/06 13:43, "Markus Armbruster" <armbru@redhat.com> wrote:>>> Will xen-unstable move forward to (at least) 2.6.18 now? >> >> This is certainly planned before 3.0.4. > > Do you expect it to fall behind again during the development cycle, > and how much?It depend when we do it and how much time we find to keep track of new Linux versions. Certainly we only intend to track major Linux dot releases.>> Perhaps. We might at least separate the kernel bits from the hypervisor >> bits. We like working with a sparse tree as it''s much quicker than cloning >> entire Linux repos. > > Ahem. Isn''t there enough suffering in the world? > > The sparse tree has been an enourmous pain in the neck for me and many > others. If all that pain is outweighed by quicker cloning of Linux > repos, then you must do that much more often than I can imagine.Yes we do. One option is for us to keep a private sparse tree and have a script that pulls out patches and applies them to a public full Linux tree. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Oct 18, 2006 at 01:51:05PM +0100, Keir Fraser wrote:> > The sparse tree has been an enourmous pain in the neck for me and many > > others. If all that pain is outweighed by quicker cloning of Linux > > repos, then you must do that much more often than I can imagine. > > Yes we do. One option is for us to keep a private sparse tree and have a > script that pulls out patches and applies them to a public full > Linux tree.Yes please! I''ve been using such a script locally since linux-2.6-xen has gone stale and it works very well, but I''d rather linux-2.6-xen returned to life. I''ll be happy to help maintain it (automatically push changes to it and/or make sure the script keeps working). Unfortunately for various reasons I can''t host such a tree myself, or I would''ve done so already. Cheers, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote: [Wed Oct 18 2006, 08:51:05AM EDT]> > The sparse tree has been an enourmous pain in the neck for me and > > many others. If all that pain is outweighed by quicker cloning of > > Linux repos, then you must do that much more often than I can > > imagine. > > Yes we do. One option is for us to keep a private sparse tree and > have a script that pulls out patches and applies them to a public > full Linux tree.This may be well-known already, but if the issue is with the time/space taken by "hg clone", you can make clones faster with "cp -al". Normally "hg clone" will create hard links of everything in the .hg directory, but it makes copies for the working set. Using "cp -al" doubles the savings by making the working set hard links as well. All the normal tools (patch for example) will handle hard links correctly, treating them as COW. AFAIK the only tool that needs special configuration is vim: set backupcopy+=breakhardlink $ time hg clone xen-unstable.hg xen-unstable.hg-clone real 0m8.293s $ time cp -al xen-unstable.hg xen-unstable.hg-clone2 real 0m0.408s $ time cp -al linux-2.6 linux-2.6-clone real 0m1.644s Aron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel