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: Andrew Warfield <andrew.warfield@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] have udev create the device for blktap
From: Steven Rostedt <srostedt@xxxxxxxxxx>
Date: Thu, 28 Sep 2006 16:59:55 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 28 Sep 2006 14:03:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <eacc82a40609281323h5c2d37e8n13750116fcf03432@xxxxxxxxxxxxxx>
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> <eacc82a40609281323h5c2d37e8n13750116fcf03432@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060614)
Andrew Warfield wrote:
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?

The class seemed the most reasonable way to organize it in sysfs. The directory is still created by the udev rules, but that is still the norm.

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.

That can be done. I was going to do something with the evtchn but since it was a misc device, it is automatically registered in the sysfs system. And udev uses that to create it. Although we should probably have the evtchn grab a dynamic minor from the misc system. And for those systems without udev, we could have the daemon read the sysfs system to find the minor. (I should probably change the blktapctrl to read sysfs instead of /proc/devices).

As noted in the code, I would have put it else where (perhaps it's own file), but since blktap was the only user (so far) I kept it there. Hmm, I guess I can through that code into its own file. Would be a small file though :) Would that be the preferred method?

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.

That would not be a problem. The tap devices could be stored in a link list. The only time you would need to search the list to find the tap device, is really on open. You would also do it to look for a free device, but that search is already done.

I'll take a look into that too.

-- Steve

Xen-devel mailing list