Re: [BK PATCHES] add ata scsi driver

From: James Bottomley (James.Bottomley@steeleye.com)
Date: Tue May 27 2003 - 10:03:17 EST


On Tue, 2003-05-27 at 10:36, Linus Torvalds wrote:
Btw, in case you wonder why I care about names and organization, it's
because with the names and organization comes assumptions and
expectations.

One prime example of this is cdrecord, and the incredible braindamage that
the name "SCSI" foisted upon it. Why? Because everybody (ie schily)
_knows_ that SCSI is addressed by bus/id/lun, and thinks that anything
else is wrong. So you have total idiocies like the "cdrecord -scanbus"
crap for finding your device, and totally useless naming that makes no
sense in any sane environment.

Calling something SCSI when it isn't brings on these kinds of bad things:
people make assuptions that aren't sensible or desireable.

Names have power. There's baggage and assumptions in a name. In the case
of SCSI, there is a _lot_ of baggage.

I took this one on board a long time ago. Even in the SCSI world, FC
devices don't think in terms of PUN, they think in terms of WWN.

If you look at the mid layer (and I don't promise this to be complete
yet) we're moving away from referring to things by host/channel/id/lun.
Now we just have host/device list in most places. About the only place
we convert back to the numbers is to print messages.

We're certainly not there yet, since we need to support legacy
interfaces like /proc/scsi/scsi. But eventually you'll probably see us
using the sysfs name instead of the id (FC devices will probably stuff
WWNs in here, other things may use numbers) and lun (not sure how we'll
represent SCSI-3 LUN hierarchies yet). Hopefully, it will be possible
to make the mid layer entirely unaware of any id/lun distinction so it
could be configured for a flatter host/device space instead.

James




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/