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 ;-).
-
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/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:54 EST