WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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