Date: Thu, 15 May 1997 10:50:52 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: se@FreeBSD.ORG (Stefan Esser) Cc: dfr@nlsystems.com, msmith@atrad.adelaide.edu.au, current@FreeBSD.ORG Subject: Re: Backwards compatibiliy for isa_driver Message-ID: <199705151750.KAA15209@phaeton.artisoft.com> In-Reply-To: <19970514224514.26045@x14.mi.uni-koeln.de> from "Stefan Esser" at May 14, 97 10:45:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> [ I want to broaden the topic of this thread, since I think it is > useless to look only at the representation of resources or device > data in the kernel. So this message is about driver data representation > in the kernel, but also about a persistent storage for driver config > parameters and even DEVFS state. Please excuse the long reply, and > please let me know, what you think about it ... ] [ ... ] > For example for ISA, I need to keep a memory addr and size, a port > address and size and IRQ and DMA values. For PCI, there are 6 maps > available, which may be inactive or decode memory or port addresses > in any combination. [ ... ] > Well, I sent mail to a few people a few days ago, in which I > proposed a config database that can be loaded together with the > kernel and might be implemented as follows: I have to say that I still don't "get" the need for a persistent data store for DEVFS, seperate from the agregate initialized kernel data, which should be symbolically editable in any case, if it's a generalized format. I also do not "get" the need for a persistent store for device information, *especially* given that, other than non-PnP ISA, it is possibile for the machine to detect all necessary information about the hardware, provided there exists a driver for the thing in the first place. Even if there doesn't, it's possible to at least disable the device, or know which resources it's going to take with or without your permission, and map around the thing. For ISA cards, we should plan for a future where all ISA cards are PnP. In light of this, we need to make specific exception for ISA cards which are not PnP, and we need to do this at the driver probe level, and then only in the ISA specific driver case. There are a lot of examples of card coniguration data that is, in fact, *already* persistent in the ISA card settings, with nothing we can do to resolve conflicts except to avoid the space used by the card. I would prefer to determine this at probe time, rather than from some static database. For cards which are relocatable, the choice is simple: modify the agregate data so that the only available options from the list of options reflect valid cards. Yes, this means that if you have one ISA ethernet card of a given driver, you modify the driver probe space data to reflect only that card. You do this *only* if the card is giving you trouble. When you do this, you make it harder to later add a second ISA ethernet card for the given driver; but it is only marginally so. The difference is in the destruction of the template data when the first static configuration occurs. To alleviate this, you don't *destroy* the template data, you merely *disable* it. This means that in adding the card, you reenable it later. Couple this with doing the NE2000, and SMC, and etc. probes the way we *should* be doing them (the NE2000 and SMC setup utilities can find the cards without screwing your machine; we should be able to do the same), and you have a *very* small list of "rogue" hardware which you have to treat seperately by restricting the probe space. Finally, for absolutely worst case, obnoxious hardware with no driver, we keep some number of records set aside for a driver for "dummy" devices. Ie: the device space designated and enabled by this driver is assumed to be serviced by the driver, and is thus not available for conflicting mappings. I guess the last piece is to add PnP configuration code to the OS for when the BIOS does not support it. I hesitate to suggest this, because I think the much more sane model is to flash the BIOS in the *vast* majority of cases, instead. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705151750.KAA15209>