[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH] xc: deal with xen/evtchn and xen/gntdev device names
Since udev magic is something that few developers should need to deal with, would it be too much to ask for a good wiki page to list likely failure conditions and how to solve them BEFORE clueless developers (including me) run into them? > -----Original Message----- > From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx] > Sent: Friday, June 04, 2010 3:55 AM > To: Jeremy Fitzhardinge > Cc: Bastian Blank; Xen-devel > Subject: Re: [Xen-devel] [PATCH] xc: deal with xen/evtchn and > xen/gntdev device names > > On Thu, 2010-06-03 at 20:32 +0100, Jeremy Fitzhardinge wrote: > > On 06/03/2010 01:31 AM, Ian Campbell wrote: > > > On Wed, 2010-06-02 at 17:09 +0100, Jeremy Fitzhardinge wrote: > > > > > >> On 06/02/2010 02:29 AM, Ian Campbell wrote: > > >> > > >>> On Tue, 2010-06-01 at 17:35 +0100, Jeremy Fitzhardinge wrote: > > >>> I don't think we need a flag day. It seems like we already ship a > udev > > >>> rule (in tools/hotplug/Linux/xen-backend.rules) which correctly > > >>> created /dev/xen/evtchn with the current kernel and which is > apparently > > >>> unnecessary (but harmless) with the proposed kernel change. > > >>> > > >>> > > >> My main concern is that an old libxc will screw anyone with new > kernel > > >> and udev. > > >> > > > Is it any more likely to screw them with a new kernel than with an > old > > > one? > > > > > > > Yeah, because libxc's rummage around in sysfs will actually work. If > we > > rename the devices to be correct, it won't find them and it just ends > up > > deleting the old device and either failing to create a new one, or > > creating it with a bogus major/minor. > > That sucks ;-) > > > > If so I think that's an argument for propagating the removal of > this > > > functionality into stable trees sooner rather than later rather > than > > > papering over the craziness for even longer. > > > > > > > Yep. > > Keir has applied my patch so I'll keep an eye out for fallout and > suggest it for backporting to the stable branch when it looks like > we've > gotten away with it. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |