Date: Wed, 14 Aug 1996 10:29:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: phk@critter.tfs.com (Poul-Henning Kamp) Cc: sos@FreeBSD.org, msmith@atrad.adelaide.edu.au, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.org Subject: Re: sio problems with 2.2-960801-SNAP Message-ID: <199608141729.KAA29330@phaeton.artisoft.com> In-Reply-To: <453.840022809@critter.tfs.com> from "Poul-Henning Kamp" at Aug 14, 96 01:40:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> For anybody who looks at the code for the pccard support, and thinks > they can do better, please send email to Nate and tell him that you > will be helping. > > For anybody who think it is trivial: You're wrong. > > The very idea of hardware that comes and goes is so alien to UNIX > as you could possibly make it. This is not simple at all. I agree with Poul. Consider the following: For file system hardware (NFS or real FS via pluggable controller, or floppy disk, etc.), it requires moving to a device notification model for mounts, since the devices are transient, and may come and go -- and not under software control. The software must *react* rather than *initiating* the plug events. This requires handling physical-to-logical and logical-to-logical device mapping as a hierarchy in a devfs style implementation, which triggers on "device arrival" events. The completion of a successful probe for a statically configured device is considered an arrival event for the purposes of this discussion. There are implications for the mount code, which must seperate the concept of volume mounting from the concept of mapping a mounted volume into the existing FS hierarcy, either as an inferior device to the root device, or some subbordinate devie at an even lower level. The concept of volume table management, where a device is the result of a partititoning schema of one kind (DOS partition table) or another (BSD disklabel) or yet another (DOS exetended partition, etc.) fits nicely into this model. So does the concept of volume spanning, whether it consists of mirroring, striping, or simple volume concatentation (everything the CCD driver now does, not quite adequately: an obvious fact to anyone who has tried to use a ccd device for root). There's a significant amount of work simply to support file system hardware, and almost all of it depends on a working devfs as a mandatory system foundation on which to build everything else. And the vast majority of the hardware falls into the category of "typical ISA hardware unrelated to FS operations"... it has it's own set of quirks. Now add to that that the ENPIC hardware (of which there are five popular chip register interfaces currently in use for PCMCIA->ISA bridging), and making the code robust becomes a nightmare. The different chipsets do not all support mapping the same dynamic configuration range of ports and interrupts in the ISA space. I suggest that anyone complaining about the PCMCIA (PCCARD) support code get copies of the PCMCIA documentation from the SIG. This will only cost you as much as a 1G hard drive, like it cost the rest of us, after shipping, etc. is figured in. Then if, after reading that, you are still interested, I will send you a list of the chip interface literature you will need to buy to support the bridge chipsets in common use. Nate and the Nomads (still a good name for a band ;)) have been doing an *excellent* job of abstracting the interfaces at several of the *few* available common abstraction levels which could possible be used to implement a modular architecture at all. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608141729.KAA29330>