All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <srostedt@redhat.com>
To: Roland Paterson-Jones <roland@rolandpj.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Help/problems with blktap on xen-unstable
Date: Thu, 21 Sep 2006 07:58:18 -0400	[thread overview]
Message-ID: <45127E5A.1090202@redhat.com> (raw)
In-Reply-To: <45123C4B.1020205@rolandpj.com>

Roland Paterson-Jones wrote:
> Steven Rostedt wrote:

>> Any thought about making blktap a miscellaneous device and have 
>> blkctrl just read /proc/misc to find the node?  I could easily write 
>> up a patch, if others think this is appropriate.
> 
> I don't understand the technical details, but this sounds like it would 
> avoid both hardcoded or configured major number, so if that's the case 
> I'd be very keen for the patch.
> 

There's a few issues.

As a miscellaneous device, it no longer has a major number.  All 
versions would become a miscellaneous device. So instead of having a 
blktap major, and the minor pointing to each of the blktap descriptors 
in the array, you would record the minor in the descriptor, and among 
opening the device, you need to search the descriptors to find the minor 
that matches the opened device.

So you might get something like:

# cat /proc/misc
35 blktap0
39 blktap1
40 blktap2
84 blktap3

Where the index no longer matches the inode minor increment.  It 
probably wont be this bad, and usually would increment, but you don't 
know if another device has jumped in.

But the search is only on opening the device and not an the operations, 
because once you find the descriptor in blktap_open you save that in the 
private date field of the file descriptor.


Another solution is to just make it a dynamic major, and then put the 
result somewhere that a tool can find it.  Most acceptable now, I guess, 
is in /sys.  Even though I find working in the /proc is easier.

Or, have a blktapctl as a miscellaneous device, and this can tell you 
where the major number was. Finding the blktapctl would be easy, since 
it would be in /proc/misc.

So there's several solutions to this.  It's just a matter of which is 
most acceptable.

-- Steve

  parent reply	other threads:[~2006-09-21 11:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-20  6:37 Help/problems with blktap on xen-unstable Roland Paterson-Jones
2006-09-20 10:18 ` Christophe Saout
2006-09-20 12:06   ` Roland Paterson-Jones
2006-09-20 12:10     ` Petersson, Mats
2006-09-20 12:10     ` Christophe Saout
2006-09-20 12:19       ` Roland Paterson-Jones
2006-09-20 13:44         ` Roland Paterson-Jones
2006-09-20 13:53           ` Petersson, Mats
2006-09-20 12:21       ` Roland Paterson-Jones
2006-09-20 18:35   ` Steven Rostedt
     [not found]     ` <45123C4B.1020205@rolandpj.com>
2006-09-21 11:58       ` Steven Rostedt [this message]
2006-09-21 18:57         ` Andrew Warfield
2006-09-26 11:40         ` Stephen C. Tweedie

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=45127E5A.1090202@redhat.com \
    --to=srostedt@redhat.com \
    --cc=roland@rolandpj.com \
    --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.