Date: Sat, 20 Mar 1999 20:53:02 +0800 From: Peter Wemm <peter@netplex.com.au> To: Soren Schmidt <sos@freebsd.dk> Cc: gibbs@narnia.plutotech.com (Justin T. Gibbs), current@FreeBSD.ORG Subject: Re: How to add a new bootdevice to the new boot code ??? Message-ID: <199903201253.UAA45807@spinner.netplex.com.au> In-Reply-To: Your message of "Sat, 20 Mar 1999 10:58:56 %2B0100." <199903200958.KAA35050@freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903201253.UAA45807>