It seems Justin T. Gibbs wrote: > 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
That there allready, if we mean the same thing here. > - Peripheral driver to device routing Such as ? > - debugging/tracing facilities Well, there is a little of that allready, more to come. > - an extensible error recovery framework Well, here is room for improvement, I haven't put any real error checking code in there by now, it will just fail and report that for now. This is alpha level code remember. > - an understanding of command queuing (also relevant for ATAPI) Hmm, well, yes, but I'm not sure that what ATA/ATAPI has to offer here is comaptible with the CAM framwork. I plan to support tagged queueing on ATA disks though. > - understanding of hot plug events This really isn't an issue on ATA/ATAPI devices in most cases, but in the mobile world there is a need for this, but that is already being worked on. We need alot of work in other places in the kernel, before this can be really utilized though. > - an aplication pass-thru interface Hmm, what for ?? ATAPI commands could esily be passed through, but I'd like a driver to be in charge here, and besides we allready have drivers for most existing ATAPI HW. > 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. ATAPI has nothing to do in the da driver, well maybe for ZIP/LS120 drives, but disks are ATA, and that needs translation. > 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. Thats correct, but there is enough differences that it still is a pain. > But hey, I don't have the time to work on ATAPI. Soren does, so he gets > to call the shots. Right :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
