Hiten Pandya hmp at
Sun Oct 26 01:26:16 PST 2003

Kip Macy wrote:

   What was the deal about the posting from the guy (on the freebsd lists)
   who kept losing his partition table?  Was that atapicam related too?

Are you being facetious? ATAPI, to the best of my knowledge,
only applies to CD-ROM/CD-R/CD-RW and probably DVD drives.
	The ataNG code has some serious issues, which are hard to pin
	down in my knowledge; because some are occuring from interrupt
	issues, and some just result in deadlocks and thus are hard to
	For instance, try using Duke University's FStress program (first
	it needs patching to work on FreeBSD), and then see ataNG code
	crash in various places, while this is not a problem in the
	the ATA driver in 4.8 before ATA bus_dma MFC.  Nevertheless,
	Soren has been doing some excellent work, and IIRC he has been
	getting to the bugs, so sooner or later, ataNG will stabilize.
   We will be bringing in ATAng for the SATA and chipset support, but I
   intend to do it under a new driver name with a new major number.  I am
   not going to remove the old ATA driver (though they might end up being
   mutually exclusive).  I've learned the lesson from FreeBSD when Soren
   changed out ATA the first time and broke a lot of people, then did it
   again the second time with ATAng.  That isn't going to happen in
   DragonFly, hopefully.
Wouldn't it be possible to have something like a quirks table in reverse?
The idea being to default to the old driver, only using the new driver in
the presence of SATA or recognized hardware, i.e. hardware that had
already been tested to some degree of comfort. This would get us less
testing, but it would allow it to be a default of sorts and still avoid
using users as unwitting guinea pigs.
	I agree with Matt here, we shouldn't replace the old ataNG code.
	Instead, we should allow boot time selection of which ATA
	subsystem to use, since compile time does not sound practical
	enough.  By default, we can keep ataNG to 1, and old ATA
	This solves two problems, the wider testing, and the multiple
	existence issue.  This is once ataNG has any porting work done.
	Anyways, currently, we are just talking, and no action (but
	don't let me stop y'all from doing the porting work! ;-))

Hiten Pandya
hmp at xxxxxxxxxxxxx

More information about the Kernel mailing list