Hi all, Already posted this over in xen-users and Konrad confirms it as a bug and suggested to repost it over here! Issue is that changing the time in dom0 doesn''t take effect on the VMs until a reboot of dom0. The testing example below illustrates what I mean.... Synopsis of testing: Booted the physical machine, date tells me it''s 17:15:45. Hwclock agrees. Booted a VM (using xl as xm seems to be labouring under the impression that blockdev is missing - it isn''t) The login prompt displays the time as 17:17, which is the expected behaviour. Changed the time in dom0 - (date +%T -s 12:00:00), synced to hwclock. Check that date and hwclock match - they do. Destroy the VM and recreate. The login prompt displays the time as 17:22. Unexpected! Kernel: I git cloned tag v3.1 from the kernel.org linux.git, and applied xen-settime patches Also tested with jeremy-git-xen-next-2.6.32 (.41/.46) without patch, they wouldn''t apply. Xen: 4.1.1/4.1.2 Distribution: Gentoo It still doesn''t work. I''ve tested that the issue also exists in Debian Squeeze (with linux-image-3.0.0 from testing as 2.6.32-5 is broken on my hardware). -- *Niall Fleming BSc. (Hons)* Systems Administrator Webanywhere Limited Phone: 0800 862 0131 Ext: 203 Web: http://www.webanywhere.co.uk Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB Registered in England with company number 4881346 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Nov 11, 2011 at 05:25:52PM +0000, Niall Fleming wrote:> Hi all, > > Already posted this over in xen-users and Konrad confirms it as a > bug and suggested to repost > it over here!Laszlo, Paolo, Jan, you guys haven''t seen domething like this? It looks like a hypervisor issue where the wallclock time is not really dispursed in the shared_info.> > Issue is that changing the time in dom0 doesn''t take effect on the > VMs until a reboot of dom0. > The testing example below illustrates what I mean.... > > Synopsis of testing: > > Booted the physical machine, date tells me it''s 17:15:45. Hwclock agrees. > Booted a VM (using xl as xm seems to be labouring under the > impression that blockdev is missing - it isn''t) > The login prompt displays the time as 17:17, which is the expected > behaviour. > Changed the time in dom0 - (date +%T -s 12:00:00), synced to hwclock. > Check that date and hwclock match - they do. > Destroy the VM and recreate. > The login prompt displays the time as 17:22. Unexpected! > > > Kernel: I git cloned tag v3.1 from the kernel.org linux.git, and > applied xen-settime patches > Also tested with jeremy-git-xen-next-2.6.32 (.41/.46) without patch, > they wouldn''t apply. > Xen: 4.1.1/4.1.2 > Distribution: Gentoo > > It still doesn''t work. > > I''ve tested that the issue also exists in Debian Squeeze (with > linux-image-3.0.0 from testing as 2.6.32-5 is broken > on my hardware). > -- > > *Niall Fleming BSc. (Hons)* > Systems Administrator > Webanywhere Limited > > Phone: 0800 862 0131 Ext: 203 > Web: http://www.webanywhere.co.uk > > Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB > Registered in England with company number 4881346> _______________________________________________ > 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 11.11.11 at 19:39, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > On Fri, Nov 11, 2011 at 05:25:52PM +0000, Niall Fleming wrote: >> Hi all, >> >> Already posted this over in xen-users and Konrad confirms it as a >> bug and suggested to repost >> it over here! > > Laszlo, Paolo, Jan, you guys haven''t seen domething like this? It looks > like a hypervisor issue where the wallclock time is not really dispursed > in the shared_info.Hypervisor? Upstream up to and including 3.1 just doesn''t issue the necessary hypercalls. This was fixed only recently through patches from Jeremy. We had a different issue in that respect in the forward ported Linux trees, but that got fixed a couple of months ago, too. This not working in Jeremy''s 2.6.32 tree is odd though, but I''m not certain which branches the necessary code would on.>> >> Issue is that changing the time in dom0 doesn''t take effect on the >> VMs until a reboot of dom0. >> The testing example below illustrates what I mean.... >> >> Synopsis of testing: >> >> Booted the physical machine, date tells me it''s 17:15:45. Hwclock agrees. >> Booted a VM (using xl as xm seems to be labouring under the >> impression that blockdev is missing - it isn''t) >> The login prompt displays the time as 17:17, which is the expected >> behaviour. >> Changed the time in dom0 - (date +%T -s 12:00:00), synced to hwclock. >> Check that date and hwclock match - they do. >> Destroy the VM and recreate. >> The login prompt displays the time as 17:22. Unexpected! >> >> >> Kernel: I git cloned tag v3.1 from the kernel.org linux.git, and >> applied xen-settime patches >> Also tested with jeremy-git-xen-next-2.6.32 (.41/.46) without patch, >> they wouldn''t apply. >> Xen: 4.1.1/4.1.2 >> Distribution: Gentoo >> >> It still doesn''t work. >> >> I''ve tested that the issue also exists in Debian Squeeze (with >> linux-image-3.0.0 from testing as 2.6.32-5 is broken >> on my hardware). >> -- >> >> *Niall Fleming BSc. (Hons)* >> Systems Administrator >> Webanywhere Limited >> >> Phone: 0800 862 0131 Ext: 203 >> Web: http://www.webanywhere.co.uk >> >> Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB >> Registered in England with company number 4881346 > >> _______________________________________________ >> 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 11/11/11 19:39, Konrad Rzeszutek Wilk wrote:> On Fri, Nov 11, 2011 at 05:25:52PM +0000, Niall Fleming wrote:>> Booted the physical machine, date tells me it''s 17:15:45. Hwclock agrees. >> Booted a VM (using xl as xm seems to be labouring under the >> impression that blockdev is missing - it isn''t) >> The login prompt displays the time as 17:17, which is the expected >> behaviour. >> Changed the time in dom0 - (date +%T -s 12:00:00), synced to hwclock. >> Check that date and hwclock match - they do. >> Destroy the VM and recreate. >> The login prompt displays the time as 17:22. Unexpected!I shut the VM down (2.6.32-131.0.15.el6) before the systime/hwclock change in dom0 (2.6.18-286.el5xen), and restarted it afterwards. The guest entered an infinite loop during this boot :( Thanks Laszlo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Nov 14, 2011 at 09:48:45AM +0000, Jan Beulich wrote:> >>> On 11.11.11 at 19:39, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > On Fri, Nov 11, 2011 at 05:25:52PM +0000, Niall Fleming wrote: > >> Hi all, > >> > >> Already posted this over in xen-users and Konrad confirms it as a > >> bug and suggested to repost > >> it over here! > > > > Laszlo, Paolo, Jan, you guys haven''t seen domething like this? It looks > > like a hypervisor issue where the wallclock time is not really dispursed > > in the shared_info. > > Hypervisor? Upstream up to and including 3.1 just doesn''t issue the > necessary hypercalls. This was fixed only recently through patches > from Jeremy. We had a different issue in that respect in the forward > ported Linux trees, but that got fixed a couple of months ago, too.Right. With those patches too (he used the xen-settime patch set which has it). The hypercall is done (and the do_settime gets called) and the results are saved in the RTC. And the wc_sec and wc_nsec are updated and propagated. The problem is that wc_sec and wc_nsec are only propagated to the existing guests. If you launch a new guest after the ''hwclock'', the new guests retains the old wallclock time.> > This not working in Jeremy''s 2.6.32 tree is odd though, but I''m not > certain which branches the necessary code would on. > > >> > >> Issue is that changing the time in dom0 doesn''t take effect on the > >> VMs until a reboot of dom0. > >> The testing example below illustrates what I mean.... > >> > >> Synopsis of testing: > >> > >> Booted the physical machine, date tells me it''s 17:15:45. Hwclock agrees. > >> Booted a VM (using xl as xm seems to be labouring under the > >> impression that blockdev is missing - it isn''t) > >> The login prompt displays the time as 17:17, which is the expected > >> behaviour. > >> Changed the time in dom0 - (date +%T -s 12:00:00), synced to hwclock. > >> Check that date and hwclock match - they do. > >> Destroy the VM and recreate. > >> The login prompt displays the time as 17:22. Unexpected! > >> > >> > >> Kernel: I git cloned tag v3.1 from the kernel.org linux.git, and > >> applied xen-settime patches > >> Also tested with jeremy-git-xen-next-2.6.32 (.41/.46) without patch, > >> they wouldn''t apply. > >> Xen: 4.1.1/4.1.2 > >> Distribution: Gentoo > >> > >> It still doesn''t work. > >> > >> I''ve tested that the issue also exists in Debian Squeeze (with > >> linux-image-3.0.0 from testing as 2.6.32-5 is broken > >> on my hardware). > >> -- > >> > >> *Niall Fleming BSc. (Hons)* > >> Systems Administrator > >> Webanywhere Limited > >> > >> Phone: 0800 862 0131 Ext: 203 > >> Web: http://www.webanywhere.co.uk > >> > >> Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB > >> Registered in England with company number 4881346 > > > >> _______________________________________________ > >> 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 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:> Right. With those patches too (he used the xen-settime patch set which has it). > The hypercall is done (and the do_settime gets called) and the results are saved > in the RTC. And the wc_sec and wc_nsec are updated and propagated. > > The problem is that wc_sec and wc_nsec are only propagated to the > existing guests. > > If you launch a new guest after the ''hwclock'', the new guests > retains the old wallclock time.Existing (pvops) guests shouldn''t see updated wallclock time, because they never look at the hypervisor''s wallclock after boot time. It''s surprising that new guests don''t see the updated wallclock though. That sounds like a Xen issue. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote: > > Right. With those patches too (he used the xen-settime patch set which has it). > > The hypercall is done (and the do_settime gets called) and the results are saved > > in the RTC. And the wc_sec and wc_nsec are updated and propagated. > > > > The problem is that wc_sec and wc_nsec are only propagated to the > > existing guests. > > > > If you launch a new guest after the ''hwclock'', the new guests > > retains the old wallclock time. > > Existing (pvops) guests shouldn''t see updated wallclock time, because > they never look at the hypervisor''s wallclock after boot time. > > It''s surprising that new guests don''t see the updated wallclock though. > That sounds like a Xen issue.<nods> That is what I think is happening here. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
OK, what''s the lead time on getting that patched? *Niall Fleming BSc. (Hons)* Systems Administrator Webanywhere Limited Phone: 0800 862 0131 Ext: 203 Web: http://www.webanywhere.co.uk Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB Registered in England with company number 4881346 On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote: >> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote: >>> Right. With those patches too (he used the xen-settime patch set which has it). >>> The hypercall is done (and the do_settime gets called) and the results are saved >>> in the RTC. And the wc_sec and wc_nsec are updated and propagated. >>> >>> The problem is that wc_sec and wc_nsec are only propagated to the >>> existing guests. >>> >>> If you launch a new guest after the ''hwclock'', the new guests >>> retains the old wallclock time. >> Existing (pvops) guests shouldn''t see updated wallclock time, because >> they never look at the hypervisor''s wallclock after boot time. >> >> It''s surprising that new guests don''t see the updated wallclock though. >> That sounds like a Xen issue. > <nods> That is what I think is happening here. > > _______________________________________________ > 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
ping? *Niall Fleming BSc. (Hons)* Systems Administrator Webanywhere Limited Phone: 0800 862 0131 Ext: 203 Web: http://www.webanywhere.co.uk Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB Registered in England with company number 4881346 On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote: >> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote: >>> Right. With those patches too (he used the xen-settime patch set which has it). >>> The hypercall is done (and the do_settime gets called) and the results are saved >>> in the RTC. And the wc_sec and wc_nsec are updated and propagated. >>> >>> The problem is that wc_sec and wc_nsec are only propagated to the >>> existing guests. >>> >>> If you launch a new guest after the ''hwclock'', the new guests >>> retains the old wallclock time. >> Existing (pvops) guests shouldn''t see updated wallclock time, because >> they never look at the hypervisor''s wallclock after boot time. >> >> It''s surprising that new guests don''t see the updated wallclock though. >> That sounds like a Xen issue. > <nods> That is what I think is happening here. > > _______________________________________________ > 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
Another week, and no response? ping? Please? *Niall Fleming BSc. (Hons)* Systems Administrator Webanywhere Limited Phone: 0800 862 0131 Ext: 203 Web: http://www.webanywhere.co.uk Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB Registered in England with company number 4881346 On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote: >> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote: >>> Right. With those patches too (he used the xen-settime patch set which has it). >>> The hypercall is done (and the do_settime gets called) and the results are saved >>> in the RTC. And the wc_sec and wc_nsec are updated and propagated. >>> >>> The problem is that wc_sec and wc_nsec are only propagated to the >>> existing guests. >>> >>> If you launch a new guest after the ''hwclock'', the new guests >>> retains the old wallclock time. >> Existing (pvops) guests shouldn''t see updated wallclock time, because >> they never look at the hypervisor''s wallclock after boot time. >> >> It''s surprising that new guests don''t see the updated wallclock though. >> That sounds like a Xen issue. > <nods> That is what I think is happening here. > > _______________________________________________ > 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 Wed, Nov 30, 2011 at 05:06:56PM +0000, Niall Fleming wrote:> Another week, and no response?I am sooo tempted to make a time joke :-)> > ping?We are just swamped. <sigh> Wish I had a better response, like: Try this patch, but not yet.> > Please? > > *Niall Fleming BSc. (Hons)* > Systems Administrator > Webanywhere Limited > > Phone: 0800 862 0131 Ext: 203 > Web: http://www.webanywhere.co.uk > > Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB > Registered in England with company number 4881346 > > On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote: > >On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote: > >>On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote: > >>>Right. With those patches too (he used the xen-settime patch set which > >>>has it). > >>>The hypercall is done (and the do_settime gets called) and the results > >>>are saved > >>>in the RTC. And the wc_sec and wc_nsec are updated and propagated. > >>> > >>>The problem is that wc_sec and wc_nsec are only propagated to the > >>>existing guests. > >>> > >>>If you launch a new guest after the ''hwclock'', the new guests > >>>retains the old wallclock time. > >>Existing (pvops) guests shouldn''t see updated wallclock time, because > >>they never look at the hypervisor''s wallclock after boot time. > >> > >>It''s surprising that new guests don''t see the updated wallclock though. > >>That sounds like a Xen issue. > ><nods> That is what I think is happening here. > > > >_______________________________________________ > >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
Cheers, at least I know that someone is still looking at it! If someone could give me a general timeframe, like it''ll be a month, before we fix it, or two weeks or whatever, I just need to give my line manager something so he gets off my case about it! *Niall Fleming BSc. (Hons)* Systems Administrator Webanywhere Limited Phone: 0800 862 0131 Ext: 203 Web: http://www.webanywhere.co.uk Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB Registered in England with company number 4881346 On 30/11/2011 22:26, Konrad Rzeszutek Wilk wrote:> On Wed, Nov 30, 2011 at 05:06:56PM +0000, Niall Fleming wrote: >> Another week, and no response? > I am sooo tempted to make a time joke :-) >> ping? > We are just swamped.<sigh> Wish I had a better response, > like: Try this patch, but not yet. > >> Please? >> >> *Niall Fleming BSc. (Hons)* >> Systems Administrator >> Webanywhere Limited >> >> Phone: 0800 862 0131 Ext: 203 >> Web: http://www.webanywhere.co.uk >> >> Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB >> Registered in England with company number 4881346 >> >> On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote: >>> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote: >>>> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote: >>>>> Right. With those patches too (he used the xen-settime patch set which >>>>> has it). >>>>> The hypercall is done (and the do_settime gets called) and the results >>>>> are saved >>>>> in the RTC. And the wc_sec and wc_nsec are updated and propagated. >>>>> >>>>> The problem is that wc_sec and wc_nsec are only propagated to the >>>>> existing guests. >>>>> >>>>> If you launch a new guest after the ''hwclock'', the new guests >>>>> retains the old wallclock time. >>>> Existing (pvops) guests shouldn''t see updated wallclock time, because >>>> they never look at the hypervisor''s wallclock after boot time. >>>> >>>> It''s surprising that new guests don''t see the updated wallclock though. >>>> That sounds like a Xen issue. >>> <nods> That is what I think is happening here. >>> >>> _______________________________________________ >>> 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2011-12-01 at 08:55 +0000, Niall Fleming wrote:> Cheers, at least I know that someone is still looking at it! > > If someone could give me a general timeframe, like it''ll be a month, > before we fix it, or two weeks or whatever, I just need to give my > line manager something so he gets off my case about it!I''m afraid OSS software doesn''t generally work like that. If you (or your boss) wants something fixed on a specific time scale or priority you''ll have to role your sleeves up and scratch the itch. Otherwise I''m sorry but you will just have to wait until someone has the cycles to look into this issue. Ian.
Hello Niall, On 12/01/11 10:53, Ian Campbell wrote:> On Thu, 2011-12-01 at 08:55 +0000, Niall Fleming wrote: >> Cheers, at least I know that someone is still looking at it! >> >> If someone could give me a general timeframe, like it''ll be a month, >> before we fix it, or two weeks or whatever, I just need to give my >> line manager something so he gets off my case about it! > > I''m afraid OSS software doesn''t generally work like that. If you (or > your boss) wants something fixed on a specific time scale or priority > you''ll have to role your sleeves up and scratch the itch. Otherwise I''m > sorry but you will just have to wait until someone has the cycles to > look into this issue.I shouldn''t comment on this, because - it''ll be off-topic, and - (more importantly) personally I''m not knowledgeable enough to fix the problem, but I feel compelled to point out that *in general* it''s not about the various rights accompanying the bits (ie. proprietary / open source / free software). It''s about who gets to allocate whose resources. Under this aspect it''s irrelevant under what rights the end product will be released, the question is instead who backs the effort & costs of the end product being hammered into existence. Users of FLOSS tend to mix up these two things ("what rights do I have to the code?" vs. "work on this for my sake!"). For the second concept, commercial relationships are (and have always been) the default, even if extremely forthcoming FLOSS developers used to evoke a different impression. (To make it abundantly clear, this is not an advertisment, and I''m speaking *strictly* personally, for myself alone.) Laszlo
I wasn''t expecting anyone to speed up and fix the issue, I just hoped that one or more of people who were involved in the original ticket could respond to a request for an update, I only asked for an update about once a week, even with busy schedules I would have thought that that was possible. I would look into the problem myself, but kernel hacking and hardcore XEN development is not my thing, I did not intend to put anyone''s back up about the issue. I''d love to fix the problem myself, and am quite willing to test and debug stuff. For reference the issue is not a massive deal-breaker for me, but it will be when the hardware clock drifts next, particularly on the production machines which may have up to 100 instances on, it becomes a massive ball-ache to down the server and reboot it just to get the instances to boot with the correct time. *Niall Fleming BSc. (Hons)* Systems Administrator Webanywhere Limited Phone: 0800 862 0131 Ext: 203 Web: http://www.webanywhere.co.uk Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB Registered in England with company number 4881346 On 01/12/2011 10:28, Laszlo Ersek wrote:> Hello Niall, > > On 12/01/11 10:53, Ian Campbell wrote: >> On Thu, 2011-12-01 at 08:55 +0000, Niall Fleming wrote: >>> Cheers, at least I know that someone is still looking at it! >>> >>> If someone could give me a general timeframe, like it''ll be a month, >>> before we fix it, or two weeks or whatever, I just need to give my >>> line manager something so he gets off my case about it! >> >> I''m afraid OSS software doesn''t generally work like that. If you (or >> your boss) wants something fixed on a specific time scale or priority >> you''ll have to role your sleeves up and scratch the itch. Otherwise I''m >> sorry but you will just have to wait until someone has the cycles to >> look into this issue. > > I shouldn''t comment on this, because > - it''ll be off-topic, and > - (more importantly) personally I''m not knowledgeable enough to fix > the problem, > > but I feel compelled to point out that *in general* it''s not about the > various rights accompanying the bits (ie. proprietary / open source / > free software). It''s about who gets to allocate whose resources. Under > this aspect it''s irrelevant under what rights the end product will be > released, the question is instead who backs the effort & costs of the > end product being hammered into existence. > > Users of FLOSS tend to mix up these two things ("what rights do I have > to the code?" vs. "work on this for my sake!"). For the second > concept, commercial relationships are (and have always been) the > default, even if extremely forthcoming FLOSS developers used to evoke > a different impression. > > (To make it abundantly clear, this is not an advertisment, and I''m > speaking *strictly* personally, for myself alone.) > > Laszlo_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel