James Bottomley wrote:
On Fri, 2008-06-20 at 13:06 +0900, Tejun Heo wrote:
The biggest problem is how to keep userland happy. hdX -> sdX
transition was painful enough and I have a strong feeling that
everyone will come after and hunt down us if we try something like sdX
-> bdX now. :-)
In theory mounting by label or ID should have fixed a lot of this.
However, if we need to head off a revolt, the sdX allocation algorithm
can be placed into it's own module so both sd and a ULD ata driver could
use it ...
Actually, surely we can mostly dump the SAT layer?
I don't see that we can do that for a long time... And it's not just
the sdX allocation algorithm in question -- SCSI block devices come with
their own partition limits and set of supported ioctls.
Therefore, my recommended path has always been
* create ata_disk block device driver (ULD, in your terminology)
* make SAT an optional piece, which maintains compatibility with
existing SCSI blkdevs, ioctls, command sets
I just don't see a valid path moving forward that breaks userland
/again/... we (ATA hackers) would be drummed out of a job I think :)
Another option that's been discussed is
1) Make SCSI block devices themselves an allocate-able resource (I think
that's what you meant by "placed into it's own module so both sd and a
ULD ata driver could use it"?)
2) Ensure that any ata_disk ULD would support the same partition limits
and ioctl set, enough to ensure binary compatibility.
Because that's the real need -- maintaining binary compatibility with
SCSI block devices, so major/minor, ioctl supported set, partition
limits, and other relevant details need to remain unchanged.
The underlying software we're of course free to change...
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
