Re: [patch] My AMD IDE driver, v2.7

[Linus Torvalds]

On Mon, 11 Mar 2002, Erik Andersen wrote:
>
> Essentially, if I understand what you are saying,  you are
> looking for a uniform low-level mass-storage layer that does all
> the normal low-level drive access stuff.

Well, yes and no.

It's not really low-level - it's at the same level as the current
"ll_rw_block()" in that it doesn't per se know any real details of any
drivers - it is nothing but a "build this request" layer (with a way of
getting the data back, of course).

So from a driver perspective (or even driver subsystem like IDE or SCSI)
it's actually a high-level request generator.

Now, let me say outright that I have a very specific reason why I'd like
this thing to be done at this level - which really has nothing to do with
Jeff's wishes to create a IDE command parser.

The reason I want to see stuff done _above_ the level of the request queue
is that I really count on the "struct request" as being the abstraction
layer that the current block driver interfaces so sadly lack.

Right now, block drivers are not very well abstracted at all: and this is
a large part of the reason for why we even _have_ things like the SCSI
midlevel layer or the IDE layer in the first place. But both the SCSI
layer and the IDE layer are just fairly messy - with no good way to share
code (no common interfaces) and with very inflexible setups (just look at
how hard it is to do a high-performance SCSI driver, because if you do a
SCSI driver at all you have to do all the interface crap that comes with
the job).

I'm really hoping that some day, if the _only_ interface to the block
driver is "struct request", you can write truly interchangable block
drivers - the same way you can write truly independent network drivers
today. None of this "IDE vs SCSI midlevel layer" crap.

Yes, "struct request" is slightly more complex than just being handed a
packet to send out, but I think that is unavoidable - block devices just
_are_ more complex than sending out a packet on a network. So while it's
not a really simple interface, at least it is a clear border between
drivers. And a SCSI driver would be nothing more than a driver that
accepts at least a subset of the kinds of requests that some scsi module
can push to it.

None of this complex function call interface with common complex
structures that are imposed by hundreds of different drivers that each
have slightly different issues. Just a queue.

"Everything is a stream of bytes" - except in this case the stream just
happens to have enough structure that you can re-order the packets and try
to sort them while they haven't been committed yet.

		Linus