Date: Mon, 05 Jul 1999 21:53:09 +0800 From: Peter Wemm <peter@netplex.com.au> To: Soren Schmidt <sos@freebsd.dk> Cc: nick.hibma@jrc.it, des@flood.ping.uio.no, green@FreeBSD.ORG, richard@cogsci.ed.ac.uk, phk@critter.freebsd.dk, freebsd-current@FreeBSD.ORG Subject: Re: IBM-DJNA drives on FreeBSD Message-ID: <19990705135309.E857D78@overcee.netplex.com.au> In-Reply-To: Your message of "Mon, 05 Jul 1999 11:49:05 %2B0200." <199907050949.LAA54481@freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Soren Schmidt wrote:
> It seems Nick Hibma wrote:
> > > > I should have said "known bad configuration". I know Søren's ATA
> > > > driver supports UDMA on the Aladdin, but I don't have the luxury of
> > > > expendable file systems, so I don't use it. I also think it's the
> > > > wrong direction to go off in; if we're going to totally rewrite our
> > > > IDE driver, we should do it within the CAM framework.
> > >
> > > Do I hear a volounteer here ??
> > > What the new ATA/ATAPI driver is all about is mostly a rewrite of all
> > > the low level code, and that is still needed if you want to go the CAM w
ay.
> > > The higher levels of the new ATA driver is simply a port of my allready
> > > done ATAPI drivers.
> > > There is nothing in the way of screwing a CAM interface ontop of that
> > > lowlevel code instead of/in parallel to the current highlvel code....
> >
> > Yes yes yes! CAM on top of ATAPI. If we keep the command
> > creation/conversion layer in CAM and make CCB come out at the lower end,
> > we could instantly screw it on top of the USB Mass Storage driver (that
> > supports SCSI through CAM at the moment).
> >
>
> Well, CAM & ATAPI is "fairly" easy, the only problem being all the
> little details that are different enough to make it non-trivial to
> maintain. I once sat down and tried to get all the details on how
> the CCB's where different, and decided that I wouldn't want to engage
> in that.
> Another story is ATA disks, there you either have to teach CAM about
> a new lowlevel protocol, or write a SCSI<>ATA translator, which I
> also decided I didn't want to do...
Well, that's assuming you use scsi ccb's... you could use atapi ccb's.
We have cam/* which is the generic transport handler. cam/scsi/* which
is the scsi peripheral drivers that use scsi ccbs, and then we could
have cam/ata/* which uses atapi ccb's and ata disk info. Then you have
cam/ata/ata_ad.c, cam/ata/atapi_cd.c etc. Your backend ata controller code
then gets requests sent to it in atapi format and/or something suitable for
ata disks.
This approach is quite efficient and you get to use the common queueing, error
recovery, etc etc stuff. You don't have to do ccb translation or anything.
You get your own disk, tape, cd etc driver with their own names and major
numbers. They would look *very* similar to the scsi counterparts but would
be seperate as they use different ccbs, different backend-specific hooks, etc.
Things like umass, vpo etc have it easy since they basically bulk send the
scsi ccb's to the device as they use the scsi protocol directly. The ATAPI
protocol is similar but would require translation if it used the common top
end drivers. So, it either requires different top end drivers or has to do
translation.
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
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?19990705135309.E857D78>