Re: IDE/ATAPI in 2.5

Alan Cox (alan@lxorguk.ukuu.org.uk)
14 Jul 2002 17:45:10 +0100


On Sun, 2002-07-14 at 16:12, Joerg Schilling wrote:
> >From alan@lxorguk.ukuu.org.uk Sun Jul 14 16:18:38 2002
> >> It seems that you miss to understand the needed underlying driver structures.
> >> SCSI is not a block layer, it is a generic transport.
>
> >It is not generic - its handling of sophisticated I/O stuff is non
>
> The fact that you don't know st does not make this statement true.

Try doing the following in SCSI

- Device managed storage layout "Allocate x blocks close to handle y
and give me a new handle"

- Per I/O request readahead hints (please read on xyzK , please dont
readahead)

- Per I/O request writeback hints (write back cache is ok, write back
cache is ok only if NV, don't bother caching, streaming I/O
hint)

Nor are all the FC problems caused by bad transport implementations in
Linux. Physical layer incompatibilities occur everywhere - but aren't
the one I'm talking about. Of more concern are the inability to manage
multiple levels of caches properly.

I have controllers which can do most of the above. I don't want to talk
scsi to them and spend all my cpu time faking, decoding and recoding
command blocks, spoofing error handling and the like.

Its simply inappropriate to consider the SCSI command set as a high
level interface for block and related I/O.

As to your comments on sg. Everyone except you happened to think that
Doug Gilberts very nice sg changes were the right path. I still think it
was the right decision.

> If this discussion stays as it currently looks like, it does not make
> sense for me to try to find a better solution. Let me call it this
> way: this thread was just another proof that it is not possible to
> have a technical based solution with the Linux folks. It seems t be >
> just a waste of time :-(

The Linux development process aggressively filters bad ideas.

Alan

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