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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2010-06-04 at 16:27 +0100, Dan Magenheimer wrote:
> 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?

The expectation is that things will mostly Just Work. If this turns out
not to be the case then the wiki would be an appropriate place to
document the issues and solutions as we determine what they are.

Ian.

> 
> > -----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