[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Steven Rostedt" <srostedt@xxxxxxxxxx>
  • From: "Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>
  • Date: Thu, 28 Sep 2006 13:47:53 -0700
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 28 Sep 2006 13:50:19 -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=mcAfLR42Xxk+BcLkwUuzSj7cHcVnZX6rVwSrxRjG/n3QjoBtpRbhZWo64U4mSCgvk8PVOe2IrViqJ0mTDROWrc/cqXRSF7dfFUPA552tNbdmCuZPNXFrGn6G1DGR7SxRyBuofgvf6MCjSXoKCB9mERPv38wcYEIzTAlrmxs3BtE=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

New plan -- after looking at the sysfs stuff a bit more and chatting
to Keir, I've applied the patch as-is.  the event channel is probably
okay for the moment as a misc device, and we can abstract out the xen
class from blktap if/when there's something else that wants to use it.

Pretty much as you said in your original submission. ;)

cheers,
a.

On 9/28/06, Andrew Warfield <andrew.warfield@xxxxxxxxxxxx> 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?

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.

a.

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.