In article <199903171205.naa25...@freebsd.dk> you wrote: > It seems David O'Brien wrote: >> > Boot from an ata disk on major# 30, device name "ad", plain and simple. >> >> Does this mean ata disks won't come under CAM/da ? > > Not if I can help it :) > It could be done by slamming a translation layer ontop of the existing > wd driver or of cause on top of the new I'm doing, but all it adds > is overhead, both performance wise and codesize wise. There is nothing > that prohibits having both of cause, but it is not a priority for me > to add more complexity into the picture before everything else is done.
My main complaint so far about the new ATAPI stuff is that it duplicates or lacks (assuming it will be implemented) much of what CAM would have given for almost free: - Interrupt driven configuration - Peripheral driver to device routing - debugging/tracing facilities - an extensible error recovery framework - an understanding of command queuing (also relevant for ATAPI) - understanding of hot plug events - an aplication pass-thru interface The question about translation layers is secondary and I would likely choose to not introduce a translation at all. Issuing pure ATAPI commands to atapi devices at the peripheral driver level is somthing that CAM could easily do. I would probably choose to merge ATAPI functionality into the da driver to avoid duplicated code and to ensure that bug fixes only need to be performed in one place. After all, the machinery for talking to an ATAPI or SCSI disk is very similar (If the disk says it needs to be spun up, spin it up; if we have too many transactions outstanding and fear tag starvation, send an ordered tag; when we close the disk or panic, synchronize its cache to stable media; etc. etc.) even if the command op codes and format are slightly different. But hey, I don't have the time to work on ATAPI. Soren does, so he gets to call the shots. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
