What is the stable release policy going to be is there is a securty hole that a later (than current) kernel fixes? For instance 2.0.5 has 2.6.10, whereas both 2.6.11.2 and 2.6.11 have mentions of security related patches. Nicholas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> What is the stable release policy going to be is there is a securty > hole that a later (than current) kernel fixes? > > For instance 2.0.5 has 2.6.10, whereas both 2.6.11.2 and 2.6.11 have > mentions of security related patches.You''ll find that the vast majority of Linux security patches will apply cleanly to one of our arch-xen kernels. Now that mainstream Linux has moved over to a point release scheme I guess we could modify our build procedure to go looking to see whether there are updates available. It''ll just be a pain on the very rare ocasions where this breaks the build. It''s really an issue for whoever is doing the packaging. In the not-so-long-term, this will hopefully be an issue for the vendor of your favourite distribution rather than us. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > What is the stable release policy going to be is there is a securty > > hole that a later (than current) kernel fixes? > > > > For instance 2.0.5 has 2.6.10, whereas both 2.6.11.2 and 2.6.11 have > > mentions of security related patches. > > You''ll find that the vast majority of Linux security patches will apply > cleanly to one of our arch-xen kernels.From what I''ve seen of the new stable patches, they rarely modify arch-dependent code. Have you tried just applying them? The only problematic changes are ones under arch/i386. Cheers, Mark> Now that mainstream Linux has moved over to a point release scheme I > guess we could modify our build procedure to go looking to see whether > there are updates available. > It''ll just be a pain on the very rare ocasions where this breaks the > build. > > It''s really an issue for whoever is doing the packaging. In the > not-so-long-term, this will hopefully be an issue for the vendor of your > favourite distribution rather than us. > > Ian > > > > > > _______________________________________________ > 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
On Tue, 29 Mar 2005, Ian Pratt wrote:> It''s really an issue for whoever is doing the packaging. In the > not-so-long-term, this will hopefully be an issue for the vendor of > your favourite distribution rather than us.Absolutely. This isn''t something an upstream project should spend too much time on, IMHO. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 29 Mar 2005 22:33:11 +0100, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:> Have you tried just applying them? The only problematic changes are ones > under arch/i386.[nic@stateless:/usr/src/linux-2.6.11.6] patch -p1 -s < ../xen/xen-2.0.bk/patch-2.6.10-xen0 Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] 3 out of 3 hunks ignored -- saving rejects to file include/linux/skbuff.h.rej 1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej>From the looks of include/linux/skbuff.h it should be fine to ignoreskbuff.h.rej. I assume that everything else should be fine. Nicholas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> [nic@stateless:/usr/src/linux-2.6.11.6] patch -p1 -s < > ../xen/xen-2.0.bk/patch-2.6.10-xen0 > Reversed (or previously applied) patch detected! Assume -R? [n] > Apply anyway? [n] > 3 out of 3 hunks ignored -- saving rejects to file > include/linux/skbuff.h.rej 1 out of 1 hunk FAILED -- saving rejects to file > Makefile.rej > > >From the looks of include/linux/skbuff.h it should be fine to ignore > > skbuff.h.rej.This may be because one of the Xen support patches has been intergrated into the mainline (anyone know if this is the case?). If so, then it''s fine.> I assume that everything else should be fine.FYI, the 2.6.11.6 patch applies fine to 2.6.11-xen0 in the 2.0-testing tree (ie. the only reject is on the top level makefile). Cheers, Mark> _______________________________________________ > 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
On Apr 1, 2005 1:14 AM, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:> FYI, the 2.6.11.6 patch applies fine to 2.6.11-xen0 in the 2.0-testing tree > (ie. the only reject is on the top level makefile).How stable is -testing at the moment? Had some compile issues with my patch. Which I haven''t had a chance to track down. Nicholas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> On Apr 1, 2005 1:14 AM, Mark Williamson > <mark.williamson@cl.cam.ac.uk> wrote: > > FYI, the 2.6.11.6 patch applies fine to 2.6.11-xen0 in the > 2.0-testing > > tree (ie. the only reject is on the top level makefile). > > How stable is -testing at the moment? Had some compile > issues with my patch. Which I haven''t had a chance to track down.-testing is generally very stable since it''s mainly bug fixes to the previous release, plus certain new features that look ''safe''. Having said that, it went through a wobble yesterday while the correct fix to the blk device performance problem was being found, but that was the first time in ages. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel