hal and "criss-crossed" atapicam

[Thomas Quinot]

* Andriy Gapon, 2008-02-17 :

> On the other hand, is it possible for atapicam to somehow query
> underlying ATA channel numbers and hard-derive unit numbers from that ?
> Something like ATA layer does when ATA_STATIC_ID kernel option is given.
> Well, maybe this is not applicable to atapi, so I might be just mumbling
> nonsense here.

Well the main issue here is that the unit numbers are not assigned by
ATAPI/CAM but by the CAM subsystem, ATAPI/CAM just provides a transport
layer, and it would be a violation of abstraction to special-case ATAPI
devices in the CAM device drivers.

> No, no :-) HAL actually sees 4 devices, but its default behavior is to
> be smart and protective and to mark atapi devices as "ignored" if they
> have atapicam partners.

Well this sounds a bit questionable to me. If the user wants to take the
responsibility of enabling both acd and cd in the same kernel, there is
no reason to try to outguess him and disable half of the devices he
configured his system for. Also note that what is specifically advised
against in the atapicam man page is not enabling both interfaces (which
can come in handy -- neither interface claims complete superiority
over the other, each has merits of its own and a preferred domain of
applicability), it's only *simultaneously* accessing the same device
using the two interfaces.

> As the manual page warns, it is indeed a bad thing to access the same
> device via two interface simultaneously. And hald is very active at
> tasting devices, so people experienced crashes and other weird things.

You shouldn't count on inquiry data being consistent between ATA
and ATAPI/CAM as some devices report different data for both.
Example on this host:

(root at melamine) ~ # atacontrol list|grep DVD
    Master: acd0 <PHILIPS DVD+/-RW DVD8701/5D24> ATA/ATAPI revision 0
(root at melamine) ~ # camcontrol inq cd0
pass4: <PHILIPS DVD+-RW DVD8701 5D24> Removable CD-ROM SCSI-0 device 

Thomas.