Re: ide errors in 7-rc1-mm1 and later

Jens Axboe
2004-06-06T20:46:42Z

On Sun, Jun 06 2004, Eric D. Mudama wrote:
> On Sat, Jun 5 at 11:24, Jens Axboe wrote:
> >I did suggest this a few years ago. The comment I received was that
> >they didn't take suggestions from OS people, if I didn't have a drive
> >implementation to go with the proposal they couldn't use it for
> >anything. Which was interesting, since that seemed to suggest that t13
> >had little steering in ata development, they mainly put into the ATA
> >specs what drive manufacturers shoved at them. Of course this isn't 100%
> >true, but it does explain a lot of things :-)
>
> If it helps, I'm listening.
>
> Suggestions/proposals for new features etc, if they're a good idea, I
> can help push inside via our SATA/T13 reps. Note that as per all
> long-lived specs with multiple revisions, changing the behavior of an
> existing feature to something incompatible is virtually never
> feasable.

Of course not, you cannot change the way the command works now. This was
at the time when the proposal was being added, however.

There are still the feature register which is reserved for write fua,
that could be used. For some odd reason t13 prefers to add seperate
opcode for the identical command, instead of just using option bits. But
you could just flag an ordered bit for WRITE_DMA_EXT_FUA, that would
work wonders.

> >Andre even tried getting FUA to do what we needed, no such luck there.
> >Some other bigger OS wanted it differently, the rest is history.
>
> Lo siento, I wasn't around when that occurred. Of course, that other
> bigger OS has a very large installed base, and selling a drive that
> breaks it is corporate suicide.

I don't think anyone in their right mind would expect that. Of course in
10 years time we can all laugh at this when the tables have turned :-)

--
Jens Axboe