Re: LSF Papers online?

[Jeff Garzik <jeff@garzik.org>]

Bartlomiej Zolnierkiewicz wrote:
> I've started reading it and immediately noticed a thing which made by day. :-)
> 
> Sorry if it will sound off-topic or undiplomatic but it is the best occasion
> to straighten up some facts:
> 
>  "Discussion then moved on to the current status of getting libata out of
>   SCSI: we have had several successes, notably timer handling and pieces of
>   error handling have moved up to block. Unfortunately, the current progress
>   has reached the point where it's being impeded by the legacy IDE subsystem
> 
> Heh, you can also blame the lack of world peace on the legacy IDE subsystem.
> 
> I wonder who came up with this ridiculous excuse (I'm sure it wasn't James!).
> 
> The thing is that during last _five_ years almost nothing was done in this
> direction.  Despite the fact that it was #1 condition under which the whole
> code has been merged.  Sorry to say it but it seems like the whole merge
> strategy was to over-promise things now and worry about delivery later.

Yet, shockingly, users have been happily using libata despite all these 
horrors.


> To make things worse all the "successes" quoted above are nothing else
> like back-ridding on block layer and SCSI improvements which were done by
> non-libata developers.

False.  Tejun authored many of the changesets getting timer and error 
handling "moved up the stack."


>   which is still relying on some very old fields and undocumented behavior
>   of the block layer, since the next step is to simplify the block to low level
> 
> When it comes to block layer interactions the legacy IDE subsystem is just
> another "dumb" (== very simple) block layer driver.

Hardly.  The IDE driver has all sorts of special cases that no other 
block driver has.  One must roll dice to see which of rq->special, 
->buffer, ->data and ->sense is filled in, and at what times. Is 
->buffer, ->data, etc. pointing to a buffer... or an opaque kernel data 
structure?  None of this is clear or documented.

REQ_TYPE_ATA_* is still around.  Overall the consistency of request 
handling across the IDE class drivers is low.  ide-tape sticks out like 
a sore thumb with its use of current_nr_sectors.

IDE's interactions with the block layer are quite complex and opaque, 
compared to other block drivers.

	Jeff