> A more severe problem is that someone in Core wants the ATAPI code to
> be re-written to be layered on top of the existing SCSI code and (if
> memory serves) the existing SCSI cd driver.  Whereas the author of the
> ATAPI patches doesn't agree that's the correct design decision,
> because an  ATAPI CD  isn't *quite* identical to a SCSI CD, and
> the differences  are sufficient to make things ugly.
>
> I don't know the details of the ATAPI CD interface to make a comment,
> but I really wish Manuel Bouyer and Jason Thorpe could reach some
> agreement on that issue. Otherwise Manuel's ATAPI patches may *never*
> be integtated into the tree.  IMHO that would be unfortunte.

It's tough not to agree with Manuel since after all he bit the bullet and
wrote the code, but I really do think that Jason's point of view is the
correct one.

Solaris, SCO, BSDI, and even Microsoft IIRC have taken the approach of
attaching a SCSI interface driver to the IDE disk driver.  In at least one
case, this also allows them to cleanly handle ATAPI tape drives and ATAPI CD-R
writers.  And it's not inconcievable that someday, someone would build an
ATAPI RAID or ATAPI disk drive.  In a proper implementation which treated
ATAPI commands as encapsulated SCSI commands -- which is what they are --
these things should "just work", even if the atapi driver ended up having to
keep some nasty state around to handle some cases.  The current
implementation, however, duplicates quite a bit of code from the SCSI system,
which, were it integrated, would then also mean we had to maintain that code
twice.

Thor