Date: Tue, 20 May 1997 13:56:13 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: Doug Rabson <dfr@nlsystems.com> Cc: Michael Smith <msmith@atrad.adelaide.edu.au>, current@FreeBSD.ORG Subject: Re: Backwards compatibiliy for isa_driver Message-ID: <19970520135613.55522@x14.mi.uni-koeln.de> In-Reply-To: <Pine.BSF.3.95q.970520102420.15296L-100000@herring.nlsystems.com>; from Doug Rabson on Tue, May 20, 1997 at 10:43:42AM %2B0100 References: <19970519202743.46906@x14.mi.uni-koeln.de> <Pine.BSF.3.95q.970520102420.15296L-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 20, Doug Rabson <dfr@nlsystems.com> wrote: > I realized this as soon as I started implementing it. I now have two > kinds of operation on a bus, operations which read and write config data > and operations which manipulate resources. The driver never accesses > config data directly (no accesses to struct isa_device) which allows the > bus to change data format or add instance variables while maintaining > binary and source compatability with old drivers. Ok. This seems the right way to do it ... > > I don't think this needs to be put into every driver, if we > > find a good concept. And that's what I'm after :) > > 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 ... (?) 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.) > > Each device and device "location" should have an ops vector. > > The location is not just the bus, it could be a PCI to PCI bridge > > (which behaves slightly different from a CPU to PCI bridge, and > > needs slightly different resource conflict checks for that reason). > > Thats what I meant. If a bus is something to which devices are attached > then a PCI to PCI bridge is a bus. In my current experimentation, I have > a hierarchy of busses. At each level in the hierarchy a bus has both a > device part (attached to the parent bus) and a bus part (for child devices > to attach to). Could you please send me your current data structures for the bus and device data ? I'd like to check the implications on my new PCI code ... > > It should be: > > > > char:13:sd > > sd:0:devfs:0640:ROOT:OPERATOR > > sd:-1:devfs:0600:ROOT:OPERATOR > > > > (This is my suggestion for a wild card unit number, but this would be > > handled by a program asking for the config data in such a way, that > > wherever this is appropriate, config data for unit -1 is retrieved, > > if nothing could be found for the actual unit.) > > I still don't understand. All the entries for different major numbers > would then have a different type: > > char:3:wd > char:13:sd > char:29:mcd Well, I've come to think of the three fields that I've proposed to be used a s selectors in a different way. The "what" parameter selects a table, in the DBMS sense. The "name" and "unit" parameters are keys into the table, and the unit is mainly used to make "name" keys unique. If you look at the example code I sent to the list, there are functions to retrieve a list of tables that contain some key, a list of keys in a table, and finally to fetch a record given a table and a unique key (with unit number). I have been thinking about changing the concept into using just a table and a unique key, but I think that it is better to keep the unit number separate ... In addition to the functions posted yesterday, there should be another one, that returns a vector of unit numbers for a table/key pair. I also considered adding a "skip" parameter, which would allow to operate on a limited number of keys at a time (say 16) and to loop over the retrieval function with skip being incremented accordingly ... > 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 ... > > 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 ... Regards, STefan which in combination with the resources claimed by old ISA cards could be
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970520135613.55522>