[lkml]   [2001]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: LANANA: To Pending Device Number Registrants
    On Monday May 14, wrote:
    > On Tue, 15 May 2001, Neil Brown wrote:
    > >
    > > I want to create a new block device - it is a different interface to
    > > the software-raid code that allows the arrays to be partitioned using
    > > normal partition tables.
    > 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.

    Ok, I'm begining to get the idea.
    Ofcourse setting the "queue" function that __blk_get_queue call to do
    a lookup of the minor and choose an appropriate queue for the "real"
    device wont work as you need to munge bh->b_rdev too.
    But you could define a make_request_fn instead which simply
    changes b_rdev from the major/minor of the virtual disk device to the
    (dynamically allocated) major/minor of the real device.

    You would still nee to make sure the blk_size[], blksize_size[],
    hardsect_size[], max_readahead[], max_sectors[] all got handled
    properly. Thats probably not too hard.

    So this would mean that my new driver (mdp) gets a dynamically
    allocated major number which is probably never seen from user-space
    (though I could look in /proc/devices if I wanted to), and it is
    accessed through /dev/diskAN for some value of A and different
    partitions N.

    So far I'm with you (I think).

    Does the minor number for this "disk" layer have N bits for partition
    number and 8-N bits (later to be 20-N bits or similar) for device
    number? If so we are limited to a smallish number of discs for now.
    If not (and partitions are packed densely) then changing the
    partitioning of a drive could be awkward.

    Finally, how do I say that I want the root filesystem to be on a
    particular "mdp" device+partition. I cannot assume that my device
    will be the first to register with the "disk" layer, so I cannot be
    sure that "root=/dev/diska1" will work.
    Maybe a boot line option like:
    could be used. Each device that registers with "disk" defines a
    __setup handler for "disk" which checks if it should register as a
    particular "disk".
    So if "mdp" finds that there is an mdp device 0, and wants to register
    it with "disk" then:
    if "diskX=mdp,0" is a boot option for some X, register it with "disk"
    as device "X-'a'"
    else register it with "disk" as "largest-available-device".

    Does that make sense? It feels a bit ugly though

    The brick wall the I feel that I am hitting is that there needs to
    be a name space to communicate device identities between kernelspace
    and userspace. You are saying that major numbers are no longer to be
    that namespace (at least, not for new drivers) so we have to come up
    with a new namespace, which will obviously involve textual names.
    There seem to be three options:

    1/ devfs - but not everybody likes that (and there are certainly
    aspects that I am uncomfortable with)
    2/ ugly hacks like the above and like name_to_kdev_t
    3/ "something else" which either hasn't been proposed or hasn't been
    agreed on. (I have my own ideasbut insufficient time).

    I guess your goal in establishing the moratorium on new majors is to
    force people to break down this brick wall, either by accepting devfs,
    pushing through ugly hacks, or finding that "something else".

    I'll keep looking for a sledgehammer:-)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:53    [W:0.025 / U:17.152 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site