Date: Mon, 5 Jul 1999 11:49:05 +0200 (CEST) From: Soren Schmidt <sos@freebsd.dk> To: nick.hibma@jrc.it Cc: 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: <199907050949.LAA54481@freebsd.dk> In-Reply-To: <Pine.GSO.3.95q.990705111928.676j-100000@elect8> from Nick Hibma at "Jul 5, 1999 11:29:50 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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 way. > > 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... Having CAM & ATAPI without the ATA part is real clumsy if you ask me, so.... There are also subtle differences in the way errors & timeouts, not to speak about tagged cmds are handlede by the HW, that probably requieres changes to the way CAM works, or non-trivial translation mechanisems, but I havn't looked too deeply into that (yet).. Besides I can live without the CAM overhead (both speed and size wise). That all boils down to that if somebody is willing to do the job, I'm sure we can integrate it into the ATA driver so that both worlds can be made happy, I just dont have the motivation to do it... > On a related edge: > > Would it make sense to create a UFI command layer (USB floppies use it, > don't know what else) on top of CAM? Or am fundamentally wrong in > assuming that one can stack any command layer on top of CAM and abuse > it as a layer that provides common services, command queueing, error > handling? > > It would like this: > > SCSI UFI_da ATAPI > \ | / > CAM layer > | > USB Mass Storage Driver > / | \ > Bulk CB CBI You better ask Justin that... -Søren 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?199907050949.LAA54481>