From owner-freebsd-current Tue May 20 06:17:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA02837 for current-outgoing; Tue, 20 May 1997 06:17:29 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA02825; Tue, 20 May 1997 06:17:19 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id WAA02812; Tue, 20 May 1997 22:47:07 +0930 (CST) From: Michael Smith Message-Id: <199705201317.WAA02812@genesis.atrad.adelaide.edu.au> Subject: Re: Backwards compatibiliy for isa_driver In-Reply-To: from Doug Rabson at "May 20, 97 02:03:03 pm" To: dfr@nlsystems.com (Doug Rabson) Date: Tue, 20 May 1997 22:47:07 +0930 (CST) Cc: se@freebsd.org, msmith@atrad.adelaide.edu.au, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Doug Rabson stands accused of saying: > > > > If I remember correctly, ISA port addresses are not fully > > decoded on many cards, and thus we have to expect a card > > to be visible multiple times in the address space. There > > should be a way to encode the address range. (I'm using a > > ln2range struct element for this purpose in the PCI code.) > > Ohhh. Thats nasty. Does this mean that reserving a port range for those > cards will also have to reserve all the address where the ports are > visible? It means that "ISA" instances of a device can only be expected in the range 0x100-0x400, but that if the motherboard chipset is broken or old, probes at higher multiples of the device's address may still show it up. This is not normally a problem, as you only go above there for EISA/PCI devices. > I think that most of what people expect for DEVFS is that permission > changes, deletions, hard- and symlinks are preserved. That probably > implies that once a major number is chosen for a given device, it would > 'stick'. Permission changes, yes. Deletions, maybe no. Hardlinks almost _definitely_ no. Symlinks yes. The list is at least partially biassed by what can be easily implemented. 8) Permissions and symlinks could be easily stored in the repository model I mentioned earlier : sys.devfs.tty/d0 owner = root group = dialler mode = 0600 sys.devfs.modem link = tty/d0 You could do a "deletion" with something like : sys.devfs.deleted path = tty/d2 path = disk/sd1 path = disk/sd2 path = disk/rsd1 I think that would be more efficient than creating a node for each deleted item. > I looked at how NetBSD does this. It seems to first allocate resources > for ISA cards and then loops through the configuration sets for the PnP > cards attempting to allocate their resources. This is probably sufficient > if there aren't too many PnP cards. > > It is possible to imagine a situation where a card needs a resource range > which was claimed by a previous card. The conflict could be resolved by > moving the first card if the second hasn't any useful alternatives. You definitely need to allocate for the "legacy" cards beforehand, and then attempt to divvy up the remaining resources between the soft-settable hardware. There's obviously a "want" to deal with half-and-half hardware, but I think that's a rather excessive ask. > Doug Rabson Mail: dfr@nlsystems.com -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[