All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <srostedt@redhat.com>
To: Andrew Warfield <andrew.warfield@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] have udev create the device for blktap
Date: Thu, 28 Sep 2006 16:59:55 -0400	[thread overview]
Message-ID: <451C37CB.4070201@redhat.com> (raw)
In-Reply-To: <eacc82a40609281323h5c2d37e8n13750116fcf03432@mail.gmail.com>

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?

Yep.

> 
> 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

  parent reply	other threads:[~2006-09-28 20:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-28 14:03 [PATCH] have udev create the device for blktap Steven Rostedt
2006-09-28 20:23 ` Andrew Warfield
2006-09-28 20:47   ` Andrew Warfield
2006-09-28 20:59   ` Steven Rostedt [this message]
2006-09-28 21:04     ` Andrew Warfield

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=451C37CB.4070201@redhat.com \
    --to=srostedt@redhat.com \
    --cc=andrew.warfield@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.