From owner-freebsd-hackers Wed Aug 14 10:35:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA16230 for hackers-outgoing; Wed, 14 Aug 1996 10:35:44 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA16223; Wed, 14 Aug 1996 10:35:41 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA29330; Wed, 14 Aug 1996 10:29:47 -0700 From: Terry Lambert Message-Id: <199608141729.KAA29330@phaeton.artisoft.com> Subject: Re: sio problems with 2.2-960801-SNAP To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Wed, 14 Aug 1996 10:29:47 -0700 (MST) Cc: sos@FreeBSD.org, msmith@atrad.adelaide.edu.au, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.org In-Reply-To: <453.840022809@critter.tfs.com> from "Poul-Henning Kamp" at Aug 14, 96 01:40:09 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > 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.