Re: [RFR] a new SCSI driver

[Ishikawa <ishikawa@yk.rim.or.jp>]

Hi,

> Thinking about how existing applications such as
> hdparm and smartmontools will cope with an ATA device
> (e.g. a disk) with a device node like "/dev/sdb".
> Those apps would make the assumption from the device
> name that such a device should be sent a SCSI command
> set. So perhaps we need a "transport" indicator in
> the sysfs directory for that device (dare I mention
> another ioctl).

As of now, smartmontools uses /etc/smartd.conf in which
we can specify a device type is ata or scsi
if the device name is not clear enough. (-d scsi or
-d ata). I am not sure why this feature is there. Maybe
devfs name thing.

Upon cursor examination, 
I am not entirely sure whether we can
*always* put a meaningful "transport indicator" in the sysfs
directory when there will be multiple
combination of transport layer(s) over the long term/haul.
For this particular situation of SATA and SCSI, yes, though.
(As the technology trend goes, I won't be surprised to
find a home PC that hooks SCSI device via a few different
transport layers such as serial, another different serial,
say, USB, and other transport layer, say, firewire
with some glue gadgets in between. 
Whether such beast will be supported
under linux, I am not sure. But we do support USB 
storage device as a SCSI device, so there may be some demand.
I am sure there will be some cheap interface boxes that probably
work under some other OSs when everything works perfectly.
I am not recommending it,  but some people will be hooked to
such setup.)




-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */