Date: Tue, 20 May 1997 14:03:03 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Stefan Esser <se@freebsd.org> Cc: Michael Smith <msmith@atrad.adelaide.edu.au>, current@freebsd.org Subject: Re: Backwards compatibiliy for isa_driver Message-ID: <Pine.BSF.3.95q.970520134341.15296O-100000@herring.nlsystems.com> In-Reply-To: <19970520135613.55522@x14.mi.uni-koeln.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 May 1997, Stefan Esser wrote: > > The problem for ISA devices is that the number of ports used isn't known > > until after the probe. The bus can't manage the resources since it > > doesn't know how large they are. > > The number of ports you talk about, that is the decoded > address range, if I understand you correctly ... (?) Thats right. > > 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? > > > I hate major numbers anyway. Devfs should dynamically allocate majors and > > everyone should use devfs. That means making devfs work properly... > > Yes, but as has been discussed before, people expect > DEVFS to provide the semantics of /dev, and that may > could mean, that we need to be able to hardwire major > device numbers. This is not meant to be used by default, > I just wanted to give more examples for things other > than ISA cards ... 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'. > > > > 1) compiled in > > > 2) loaded into RAM by the boot loader > > > 3) dynamically allocated by userconfig > > > > > > and config data should be preferred from the higher number "texts". > > > > As long as there is some config data compiled into the kernel to fall back > > to, I don't care what form its in. This sounds fine to me. It should > > also be possible to add config data at runtime for dynamically loaded > > devices. > > Yes, that might go into 3), or it might become 4) ... :) > I was thinking about this a be a way around the problem > of choosing optimal parameters for ISA PnP cards, which > must take into account the capabilities and preferred > settings of all other such cards in a system. There could > be a program run on information as supplied by pnpinfo > and the resources claimed by non-PnP ISA cards, which > would create a configuration that fits all PnP cards' > needs. This seems too complex to put into the kernel, > right now, given the complexity of the PnP info and > the interdependence of such cards ... 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. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970520134341.15296O-100000>