| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Help/problems with blktap on xen-unstable
The current device allocation code is pretty crap, and I completely
agree that the fixed assignments suck. I think my inclination would
be towards everything being dynamically assigned, and that the tapdisk
devices be allocated on demand. This would clean up a bunch of the
kernel code -- get rid of the fixed array of tap structs/device nodes
and let us scale up to larger numbers of active devices in the future.
If you're offering to cook a patch, we'd be delighted to see it. I
could also be argued into an interim solution to fix the current
conflict problems in advance of a more substantial effort. ;)
Thanks for the comments Steve, sorry for the slowish reply.
a.
On 9/21/06, Steven Rostedt <srostedt@xxxxxxxxxx> wrote:
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home