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/
Home Products Support Community News


Re: [Xen-devel] Name of event-channel and other devices vs. udev

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Name of event-channel and other devices vs. udev
From: Bastian Blank <waldi@xxxxxxxxxx>
Date: Fri, 28 May 2010 00:26:41 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 27 May 2010 15:27:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4BFEEC96.3010207@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: Bastian Blank <waldi@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
References: <20100526105144.GA28280@xxxxxxxxxxxxxxxxxxxxxxx> <20100527073512.GA17135@xxxxxxxxxxxxxxxxxxxxxxx> <20100527143104.GB6040@xxxxxxxxxxxxxxxxxxxxxxx> <4BFEEC96.3010207@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Thu, May 27, 2010 at 03:05:10PM -0700, Jeremy Fitzhardinge wrote:
> On 05/27/2010 07:31 AM, Bastian Blank wrote:
> > Xen themself is responsible for this behaviour.
> You presumably don't mean the hypervisor.

No. But Xen as delivered == hypervisor + tools.

>                                            Do you mean the toolstack is
> doing something bad when the misc device has a '/' in it?  I noticed
> when I applied your change it does things like look in
> /sys/class/xen/evtchn (or something).

It does the following:
- Search in /sys/**/evtchn for the device number, this fails.
- Compares the existing /dev/xen/evtchn with the error and unlinks it.
- Tries to mknod it again with the error value, this fails.

> What other changes are needed to keep things working after this change?

To possibilities:
- Fix the error detection in this crude device creation code.
- Rip it out and always rely on the system to provide the devices.

For Debian I already decided to use the later one.


We'll pivot at warp 2 and bring all tubes to bear, Mr. Sulu!

Xen-devel mailing list