[lkml]   [2002]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] 2.5.18 IDE 73
    Linus Torvalds wrote:
    > On Thu, 30 May 2002, Martin Dalecki wrote:
    >>Every body out there: watch out to use LABEL= in /etc/fstab or you will
    >>not be able to reboot between 2.4 and 2.5 soon!
    > Absolutely not, Martin. We need to have people be able to upgrade easily,
    > we're already scaring away too many people from this.
    >>1. Extract device registration from SCSI code.
    >>2. Let the ATA/ATAPI code hook up on it. (ide-cs is the most difficult one.)
    >>3. Let the old ATA/ATAPI major go down the bin...
    > The minor/major numbers should stay the same, they are just "mappings".
    > Device drivers shouldn't even care, and in fact we should aim for a setup
    > where we have a new cleaned-up "disk major", but at the same time we
    > should support the old major/minors so that people can easily use the same
    > disk images across different kernel versions.
    > That should be fairly easy to do, by just making sure that we (a) remove
    > the kdev_t from "struct request", (b) replace it with a controller and
    > disk index and (c) make "open()" do some fairly trivial mapping and save
    > that mapping in the "bdev", so that make_request() and friends can
    > trivially just fill in the data.
    > Voila, end of minor/major problems, and you can suddenly do things like
    > show the _same_ device on many minor/major numbers (so that you can have
    > it _both_ on a backwards-compatible place _and_ a new cleaned-up place).
    > And the device drivers wouldn't ever even _know_ what device number the
    > user saw on disk was.

    I was more thinking along the way of the way ide-scsi is highjacking the
    SCSI major numbers becouse the above scheme you describe would basically
    mean the we just reinvent different major/minor numbers with just new names
    "controller_index", and "disk_index" where due to the driver dispatching issues
    the whole IDE mess would still just preveal under the hood.
    But the goal should be more along the way of trying to
    actually remove the usage of those arbitrary values all around inside the

    Plese note as well that there are other IDE alike interfaces which basically
    already do the same: USB solidstate, and ParPort attached IDE disks come
    first in to mind.

    So it's absolutely worthwhile to extract the SCSI major number
    registration code and to reuse it as a generic kind of thing.
    At least it would relief the dependance of the above drivers on the
    SCSI code. Of course here it would make much sense to preserve some
    kind of double access to the IDE stuff. Alternatively *this*
    could be indeed handled by a kind of generic mapping on
    device open path, since basically those major numbers would
    be obsoleted, but this is just a second tought. (Yes indeed LABEL isn't
    supported on quite a lot of filesystems, so one can't hope
    of it to resolve the beckward compatibility or dual boot issue.)

    Anyway I'm looking at the ugly childs in blk.h alreay, so
    basically the DEVICE_NR macro definitions show where once would have
    to do go look after.

    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 13:26    [W:0.029 / U:11.524 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site