On Mar 1, Jonathan Stone wrote
> 
> Perry Metzger writes:
> 
> >The ATAPI code is considered "not quite finished"; perhaps its author
> >can speak about its status?
> 
> I'm not the author, but AFAIK, the unfinished-ness was lack of support
> for audio CDs and audio CD commands.  That's now fixed; I beleive the
> latest ATAPI patches include support for an X-based CD player.

That's rigth, but the driver need to be ported to the latest -current,
and integrate the changes mades by cgd to the wdc driver. I should do the job
in the next few day, now that the VM seems to be working again.

However, if there are some problems (design, implementation, or other) withr
this driver, which prevent it to be integrated in the tree, I'd be happy to
hear about them, and try to fix them !

> 
> 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.
> 

Here are some more technical info about this issue:
first, the scsi commands are of arbitary length, as the atapi command must
be 12 or 16 bit long (depending wether the device accept 12 or 16 bits
commands). This can be easily solved by the atapi layer.
The second is that there is some differences between specific scsi and atapi
commands, here are a few one (related to cdrom devices):
The READ_CD_CAPACITY, READ_SUBCHANNEL, and MODE_SELECT commands have the
same opcode in SCSI or ATAPI, but don't have the same command structure
(here is the example for READ_CD_CAPACITY, for more details, 
see sys/scsi/scsi_cd.h, sys/scsi/scsi_all.h, and sys/atapi/atapi.h)
struct atapi_read_cd_capacity {
    u_int8_t    opcode;
	u_int8_t    reserved1[7];
	u_int8_t    len;
	u_int8_t    reserved2[7];
}; 

struct scsi_read_cd_capacity {
    u_int8_t opcode; 
	u_int8_t byte2;
	u_int8_t addr[4];
	u_int8_t unused[3];
	u_int8_t control;
};  

Another big problem is the "MODE_SENSE" command: they don't have the same
opcode and command structure, but the datas returned have also a completely
different structure !
These are just examples found by reading the sources, I didn't look
at the SCSI and ATAPI specs. There may be more differences.
There may also be some byteorder issue.
There are also some commands wich exists in the SCSI world, but not in
the ATAPI world (the PLAY_TRACK and PLAY_TRACK_REL commands). This is
not the most important issue (we should be able to make a driver which don't
use such commands), but this also breaks the compatibility.

If we want an atapi device to appear as a scsi device connected to a scsi bus,
we must have the atapi layer intercept the scsi commands, decode them,
eventually translate them to atapi commands, and eventually translate the
data returned by the device. This seems inneficient to me, and the
compatibility with the existing SCSI drivers is not automatic, as we need to be
sure that all the commands used by this driver are handled by the atapi layer.
This also add an extra overload to all ATAPI commands, make the kernel
bigger (for those who use atapi), and is a bit ugly, from my point of view.

As an SCSI and an ATAPI bus looks identical, but ARE NOT identical, one way
to share the drivers would be to allow them to attach to either SCSI or
ATAPI bus, and add some "switch(bustype)" for the critical commands.
The drivers should also handle the "NATAPIBUS" and "NSCSIBUS" defines
correctly, to minimise the cost for custom kernel config. But this may need
some severe modifications to the scsi subsystem, I didn't look closer to
this yet.

PS: I think this discussion should now belong to tech-kern, as
    ATAPI stuffs should'nt be i386 specific.

--
Manuel Bouyer, MASI, Universite Paris VI.
email: bouyer@masi.ibp.fr
--