Re: [BK PATCHES] add ata scsi driver

Jeff Garzik (jgarzik@pobox.com)
Mon, 26 May 2003 02:21:21 -0400


Jeff Garzik wrote:
> Linus Torvalds wrote:
>> In other words: I'd really like to see what you can do with a _native_
>> request queue driver, and what the probloems are. And maybe port
>> _those_ parts of SCSI to it.

> Actually getting down to coding, I see it as a huge amount of work for
> little gain. You have to consider all the userspace interfaces, sysfs
> and device model support that wants coding, -after- you're done with the
> basic SATA block driver. Userland proggies already exist for scsi.

Tangenting a bit:

What does the block layer need, that it doesn't have now?

Each major subsystem right now is re-creating driver classes (floppy,
tape, disk, ...) and that should be moved up and made more general.
People should use /dev/diskX, /dev/floppyX, /dev/cdromX etc. without
having to worry about IDE or SCSI or Jeff's SATA or whatever.
Registration of majors/minors/CIDR/etc. sysfs. host
controller-specific struct request_queue settings. All these have to be
recreated each time a new native block driver is created. If you peer
closely at some scsi drivers already merged, you see that too chose to
translate SCSI rather than re-create all the junk necessary for a native
block driver. I'm definitely not the first to do what I did. :)

When such code moves up into the block layer, then we can have a unified
userland for doing class-specific activities, and then have a few
bus-specific tools for the ATA- or SCSI-specific needs not met by
class-general code.

As it stands now, I think a new native block driver creates more user
confusion and pain than it solves, in addition to saving developer pain,
if you consider all the device classes and userland tools and such that
need writing.

Jeff

-
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/