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


[Xen-devel] Re: [PATCH] have udev create the device for blktap

To: "Steven Rostedt" <srostedt@xxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] have udev create the device for blktap
From: "Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>
Date: Thu, 28 Sep 2006 13:23:30 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 28 Sep 2006 13:34:17 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=lFl72QSpvBe7sgMbPlTfXo39JXVnwOVrmib3R6OzbuVZvHBZl5V6LLVhKLd+klJhBwVxhmWYjU8ojlfY3PaPTv56N70j5JyUmyr5He4g5hZiEMjzQ01O0poDepidcUzwMR2MeaXLNwrZPq3HcqPQ3ekynW2c226ctzfxh3hD6eI=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <451BD64B.4040500@xxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <451BD64B.4040500@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I'm wondering about this one a bit, as I'm not so familiar with the
class stuff.  This patch isn't changing any of the device creation
code -- it's just adding calls to publish the existence of the
tap-related device nodes through sysfs so that udev creates them for
us, right?

Can you explain what the new 'xen' class does -- is it just to keep
things organized within /sys?  the /dev/xen subdirectory is created
through the udev rules, and not implicitly through having the class,
isn't it?

Assuming this is true, I wonder if it's worth broadening this patch
slightly to also incorporate the event channel driver, and to pull the
xen class stuff out into drivers/xen/core/sysfs_class.c or similar.

Also, on the blocktap side, it would be nice (in a later patch) to
kill the static allocation of the data-path devices and allocate them
on demand, as you do with the associed sysfs entries.


On 9/28/06, Steven Rostedt <srostedt@xxxxxxxxxx> wrote:
This patch makes blktap Do The Right Thing(TM).  It allows udev to
create the /dev/xen/blktap[0-9] devices.

It creates a sysfs class called "xen".  This part may later be placed
someplace else, but currently blktap is the only user so it is placed in
the blktap code.

When blktap is initialized, a blktap0 sysfs class device is made.  The
other devices blktapX (X > 0) are made when the BLKTAP_IOCTL_NEWINTF
ioctl is called.  This way we don't flood the sysfs and /dev/xen with
unnecessary devices.

I added a rule in the xen-backend.rules to allow for udev to create the
blktap devices.

With this, we can really remove the code to search and create the
/dev/xen/blktap[0-9]*, but I'll leave it in for now. With the use of
udev, we really should remove that code as well as the code for creating
the evtchn device.  udev works for both of these now.  But that removal
will have to be in another patch.

-- Steve

Xen-devel mailing list