See the other posts about creating a "disk" layer. Think of it as just a
simple "lvm" thing, except on a higher level (ie not on the request level,
but on the level _before_ we get to queuing the thing at all).
Plug the thing in at "__blk_get_queue()", and you're done.
> So I need a major number - to give to devfs_register_blkdev at least.
> You don't want me to have a hardcoded one (which is fine) so I need a
> dynamically allocated one - yes?
If you are willing to use devfs, you can just use a major nr of zero, and
devfs will allocate a device for you.
Not everybody likes devfs, and there are bootstrap issues with this
approach, but it is the simple "get things working quickly" approach that
needs _zero_ changes or infrastructure.
> This means that we need some analogue to {get,put}_unnamed_dev that
> manages a range of dynamically allocated majors.
We already do have that. And have had it for a long time. It's pretty much
been part of "register_blkdev()" since day one (not quite true, but I bet
that code has been there since the days of Linux-1.0.x).
You just pass in a major number of zero to "register_blkdev()", and it
will make one up for you.
devfs inherited this behaviour from the first version, I think.
> Am I missing something obvious here?
The fact that it already exists, and has existed for 5+ years, but that
nobody really uses it?
Nobody really uses it because it would require you to add a line or two to
your init scripts to pick up the major number from /proc/devices, and
that's obviously too hard. Much better to just hardcode randome numbers,
right?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/