Date: Tue, 20 May 1997 22:47:07 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: dfr@nlsystems.com (Doug Rabson) Cc: se@freebsd.org, msmith@atrad.adelaide.edu.au, current@freebsd.org Subject: Re: Backwards compatibiliy for isa_driver Message-ID: <199705201317.WAA02812@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.BSF.3.95q.970520134341.15296O-100000@herring.nlsystems.com> from Doug Rabson at "May 20, 97 02:03:03 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705201317.WAA02812>