Re: ataNG

[Kip Macy <kmacy@xxxxxxxxxxx>]

On Sun, 26 Oct 2003, Robert Watson wrote:

>
> Actually, I'm not sure the comment about atapicam is strictly true: the
> early revealed breakage involving atapicam had to do with API assumptions
> that changed.  However, the vast majority of lasting breakage has been a
> property of interrupt handling, and the nasty diversity of ATA hardware
> which makes it difficult to test a driver change thoroughly without a
> comprehensive effort involving literally hundreds (if not thousands) of
> products :-(.

Indeed. That is why the thought of doing it makes me cringe. My
experience in storage, where "thou shalt not lose data", is that
often most of the time is spent in testing. My hope is that, by having
"safe" settings for previously unseen hardware, e.g. not enabling DMA or
setting UDMA lower than the hardware claims is possible, much of the
pain can be avoided. However, because of their low-end nature, there
are many ATA devices that have idiosyncracies that can only be explained
by poor testing on the part of the manufacturer.

> The atapicam issues relating to ATAng in 5.x appear to be
> entirely resolved now,

That was my impression. What I was trying to say (I may suffer in my
writing from implying broader generalizations than intended), is that from
*briefly* skimming the results of a search of the archives for ATAng that
the only major complaints that came in at the time were fundamental
breakage of atapicam. I intended to imply that my impression of ATAng was
that it is now, by and large, a stable subsytem.

Thanks, I genuinely appreciate the information. I feel more comfortable
knowing that an import would not be a "moving target".


				-Kip