Re: [PATCH] 2.5.6-pre2 IDE cleanup 16

[Martin Dalecki <dalecki@evision-ventures.com>]

benh@kernel.crashing.org wrote:

> I would add to that than rather than killing the taskfile stuff, it
> should instead be generalized and any IDE access be done via a taskfile.
> 
> I don't comment on the actual implementation quality as I didn't look
> into it closely, but the point of passing requests as taskfile's
> down to the lowest level driver allow more consistency between the
> various pieces of the driver, more easily hooking of the low level
> taskfile "apply" code to accomodate MMIO or strangely mapped IDE
> controllers, etc...
> 
> Alan: BTW, Apple's Darwin has a nice ATA layer implementation that
> happens to be completely taskfile based :) Ask Andre what he thinks
> about their ATA & SCSI layer, except from bloat due to their C++
> implementation, their overall design is actually really nice !

I have looked at it and come to the following conclusions:

1. Indeed the code quality found there is *excellent* nothing comparable
    with the messy crude found currently in linux.

    The state machine (the finite automata one i mean) is *sweet*
    and can be even a subject to proper formal validation. This is
    quite contrary to the interrupt handler pointer passing games done
    under linux right now. There are clearly defined command
    categories determined by device state instead of the particular
    transport layer. (reset, synchroneous, asynchronous).
    There is proper separation between the device types using the
    same hardware bus layer but completely different transport
    layers (ATA vers ATAPI - which is SCSI in disguise).

2. It convinced me that the current task-file interface in linux
    is inadequate. So Alan please bear with me if your CF format
    microdrive will have to not wakeup properly for some time...
    The current mess will just have to go before something more
    adequate can go in.

3. Someone had too much time at apple, becouse the C++ found
    there doesn't apparently contain anything that couldn't
    be expressed without any pain in plain C with structs containing
    function pointers ;-).