On Sun, Feb 17, 2002 at 01:04:48PM +1300, Lloyd Parkes wrote:
> I've been digging into ATA/ATAPI because I have been having problems
> with several of my ATAPI devices under NetBSD. I have been able to write
> some quite simple software that drives these devices under DOS, but I
> have had no end of trouble getting the ATA/ATAPI code in NetBSD to drive
> them.
> 
> Why is this? Driving ATA/ATAPI devices isn't difficult, I certainly had
> no trouble doing it outside NetBSD. It is my guess that this is caused
> by the complexity of trying to support all the vagueries of legacy WDC
> style ST506/412 devices as well as all the vagueries of ATA/ATAPI
> devices. The obvious solution is to mothball support for WDC style
> ST506/412 devices. I believe that we can do this without causing a fuss.
> 
> My proposal is as follows:
> 
> 	1) The files dev/ic/wdc* are copied into dev/ata/ and renamed to
> 	   reflect a more ATA view of the world. Personally, I would do
> 	   this by copying the CVS files because I like keeping a full
> 	   history of changes.
> 	2) The GENERIC config files are changed to comment out wdc on
> 	   the ISA bus with appropriate comments explaining that this
> 	   driver and the ata driver are mutually exclusive.
> 	3) We clean up dev/ata/*, removing a lot of accumulated cruft.
> 	   I expect that we would have enough support in dev/ata for
> 	   early (dodgy) ATA devices that well behaved WDC style
> 	   ST506/412 devices will in fact work with it.
> 
> I would also like to point out that a modern NetBSD distribution won't
> fit on most ST506/412 devices.
> 
> I'm about to start working on this in my own CVS tree because I really
> would like to get my ATAPI devices working properly.

I've been thinking about this for some time yet, and there is no need to
separate the drivers. Most of the code specific to pre-ata disks is
segregated in sys/dev/ata/wd.c (exect some code in wdc.c for probe, which
should only be used by the ISA front-end anyway). Most of the conplexity
in the code (expecially code) comes from workaround for broken devices, or
brokeness of the ATA specs (like the 30s delay after a reset).
Ripping out this code would probably break some ATA hardware.

I've been thinking about delaying the probe of ATA devices after inetrupts
enable (like SCSI) exept for non-direct busses (should be only ISA). But at the
same time I'd like to clean up the ATAPI/SCSI interractions (to provide
scsibus-like IOCTL on the ide channels), but I need some more thoughs on this.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--