RE: [Xen-devel] [PATCH] xc: deal with xen/evtchn and xen/gntdev device names

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

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