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
next prev 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.