Date: Tue, 22 Dec 1998 18:15:35 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Mike Smith <mike@smith.net.au> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, "Kaleb S. KEITHLEY" <kaleb@ics.com>, freebsd-alpha@FreeBSD.ORG Subject: Re: Boot kern.flp wedges -- now what? Message-ID: <Pine.BSF.4.01.9812221814460.25052-100000@herring.nlsystems.com> In-Reply-To: <199812202047.MAA46687@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 20 Dec 1998, Mike Smith wrote: > > On Fri, 18 Dec 1998, Mike Smith wrote: > > > > Last I checked, isa devices requiring DMA didn't work yet, and the > > > > new, pci-only driver wasn't yet done. (at least I though somebody was > > > > working on one...) I'd be happy to be wrong about that ;-) > > > > > > This took a hit when Soren's system and his backup tapes were stolen. > > > I'm not sure how much momentum we've lost, but I'd say quite a lot. > > > > Ouch, that hurts. I was daydreaming about writing a CAM driver for atapi > > which would support CD and Zip drives. I spent an hour comparing the > > atapicd and scsi cd drivers and figuring out the differences in the > > protocol and I'm sure that the translation needed for the (few) different > > commands would be minimal. > > ... you could also look at the way that Linux and NetBSD do it. I > would certainly consider hanging ATAPI devices out to the CAM stack a > reasonably good idea. > > > Unfortunately fixed disks don't fit into the > > scsi-like protocol afaik. > > You'd be up for a little more work in the translation process, but not > *really* that much; you could probably get away with implementing: > > Test Unit Ready > Inquiry > Read10 > Write10 > > and a couple of modepages. The actual translation wouldn't be very > expensive. > > I was throwing the whole ATA architecture thing around the other day > (while kidding myself that I had time to work on it); I guess I see > that if we were to integrate it fully with CAM you'd have a layering > arrangement with chipset-specific drivers providing an 'atabus' with > I/O methods etc. suited to the chipset/bus in question. Then you hang > the generic 'ata' client code off the atabus, which offers generic ATA > command services, does device probing, etc. From that hangs 'atadisk' > and 'atapi' drivers to suit, which offer themselves to the CAM layer > as though they were host adapters. > > This is all moderately complex, and adds the extra worry that for an > all-IDE system the code bulk for CAM might be excessive. I'm not sure, > but I do know that I don't have time to implement it, so it's all a bit > too much like fantasy. 8( Unfortunately thats more or less the same place I ended up in after my daydreaming. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.01.9812221814460.25052-100000>