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


Re: [Xen-devel] Help/problems with blktap on xen-unstable

To: Roland Paterson-Jones <roland@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Help/problems with blktap on xen-unstable
From: Steven Rostedt <srostedt@xxxxxxxxxx>
Date: Thu, 21 Sep 2006 07:58:18 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 21 Sep 2006 04:58:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <45123C4B.1020205@xxxxxxxxxxxx>
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: <4510E1C0.7020405@xxxxxxxxxxxx> <1158747512.32181.7.camel@xxxxxxxxxxxxxxxxxxxx> <45118A05.2030909@xxxxxxxxxx> <45123C4B.1020205@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060614)
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

Xen-devel mailing list