From owner-freebsd-current Sat Mar 20 4:56:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (Postfix) with ESMTP id B864814BCD for ; Sat, 20 Mar 1999 04:56:01 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.2/8.9.2/Netplex) with ESMTP id UAA45807; Sat, 20 Mar 1999 20:53:03 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199903201253.UAA45807@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Soren Schmidt Cc: gibbs@narnia.plutotech.com (Justin T. Gibbs), current@FreeBSD.ORG Subject: Re: How to add a new bootdevice to the new boot code ??? In-reply-to: Your message of "Sat, 20 Mar 1999 10:58:56 +0100." <199903200958.KAA35050@freebsd.dk> Date: Sat, 20 Mar 1999 20:53:02 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Soren Schmidt wrote: > It seems Justin T. Gibbs wrote: > > In article <199903171205.NAA25764@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. Exactly.. why reinvent it? It seems a little silly to reinvent the other stuff that cam provides that the ata[pi] driver hasn't finished yet. > > 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. Yes, we know that IDE disks are ATA and not ATAPI, but the cam layer does have a lot of flexibility for dealing with differences even as large as that. You don't really need ``translation'' as such since a lot of the specifics are done by the backend driver and are a "black box" as far as the higher layers are concerned. You basically get to define the interface between cam and the drivers at your convenience. While the "da", "cd" etc upper level drivers do have scsi specific stuff in them (they are in the scsi subdir after all), they largely deal with generic CCB's (CAM Control Blocks) and send special scsi commands as required. Obviously these would need changing so they can send ATA or ATAPI commands instead. > > 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. You shouldn't ever have to "translate" a scsi CCB or SCSI command code into an ATAPI command or ATA command. A correctly functioning system would be sending the ata/atapi backend the in a form suitable for being used directly. > > But hey, I don't have the time to work on ATAPI. Soren does, so he gets > > to call the shots. > > Right :) Yes. Actually, the biggest problem wouldn't be building an ATA/ATAPI set of frontends and backends around the CAM system, I suspect it would be far harder to finish the generalization of the CAM code. There appear to be a lot of SCSI-specific things lurking in the cam* code... Things like the quirks table referring to T_DIRECT etc (which is from scsi/scsi_all.h) and so on. I half suspect that what Justin had in mind at some point was a set of common code that is either #ifdef'ed or otherwise preprocessed to produce a standalone 'SCSI-CAM' system versus an 'ATA[PI]-CAM' system. This would have the advantage of having all the common code together in one place and shared, while at compile time it built two seperate subsystems that were compiled specifically for the target peripheral bus with definitions to suit each so that "translation" was never used. > -Soren Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message