Re: [PATCH] 2.5.18 IDE 73

[Martin Dalecki <dalecki@evision-ventures.com>]

Linus Torvalds wrote:
> 
> On Thu, 30 May 2002, Martin Dalecki wrote:
> 
>>LAST WARNING:
>>
>>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
kernel.

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.