Date: Sun, 20 Dec 1998 12:47:03 -0800 From: Mike Smith <mike@smith.net.au> To: Doug Rabson <dfr@nlsystems.com> Cc: Mike Smith <mike@smith.net.au>, 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: <199812202047.MAA46687@dingo.cdrom.com> In-Reply-To: Your message of "Sun, 20 Dec 1998 13:29:55 GMT." <Pine.BSF.4.01.9812201326360.392-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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( -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199812202047.MAA46687>