Date: Thu, 12 Oct 95 21:19 WET DST From: uhclem%nemesis@fw.ast.com (Frank Durda IV) To: hackers@freebsd.org, msmith@atrad.adelaide.edu.au Subject: I/O port 0 == autoconfig? - RESULTS Message-ID: <m0t3ZiH-000IvuC@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
Ok, here is a summary of the responses (ten by 1900CDT) I got today on the question, which fell neatly into three categories: (please read to the bottom before replying) 1. "No problem with using I/O port 0 to signify devices that (5 rsp) auto configure." At least one person pointed-out that DMA 0 is valid on some systems, but I knew that and specifically said that we were only talking about treating the I/O port field special, not the DMA or IRQ fields. Someone suggested a matching hack to "config" would be to change the meaning of "?" to produce a "0", or whatever number we selected. If we get down to that, a new symbol should be used for "resource not used" that would generate the -1 that ? provides us today. ? should generate the "I'll figure it out myself" value, whatever it is. More on this below. 2. "ACK, that's horrible, use -2 for auto-configuring devices", (3 rsp) even though Mike indicated that handling negative numbers in the "visual" config editor was a problem. This group mentioned no other problems with the rest of the idea. And, (I knew this was coming): 3. "Don't have *ANY* drivers that figure out where the hardware is (2 rsp) by searching for it using a clue list or any other mechanism. Allow only a single-hardcoded location (resource) per driver that is used if -1 is present, and if that isn't where the hardware is, the user must change the setting using config." This group also claims it is easier for the user to figure out what the correct hardware settings are at boot time than to figure out where the driver *might* be looking if the driver looks in multiple places in the event a conflict occurs. I have a hard time believing that part, and in believing that real conflicts happen that often when compared to drivers failing to locate or initialize properly their hardware because they were not "looking" in the right place. "Also, use -2 for these myopic auto-configuring drivers (not 0) and use -1 for 'can not change the parameter value'." Uh, abandoning the use of drivers that hunt for their hardware is a religious issue, not a technical one. For example, the logic in the mail I got was: Assuming X, Y and Z are all unknown (without looking at documentation or source code), having -1 mean a driver looks for the hardware at locations X, Y, and Z is SATANIC, while having -1 mean a driver looks only at location X is OK. Got that? I don't. If you follow the logic that the user won't know where -1 looks for the driver that looks at locations X, Y and Z, he still won't know what location is being accessed if the driver just looks at location X. No difference here. The user will still have to refer to documentation to find out where the driver is looking, but he only looks if it doesn't work! That is the key. If you go along with the user-should-be-fully-informed and must-set-everything-exactly-right way of thinking (I guess this is the same school that took the automatic IRQ mapping out of the ed0 driver sometime back - grrr), then all drivers should list explicit settings in config, and not look anywhere else, nor should they figure out anything for themselves. The Port/IRQ/DMA settings should have no hidden meanings, such as changing a driver from interrupt-driven to polled, etc. The Flags parameter should be used for special stuff that, and if the driver doesn't use a given resource, stick a -1 in that field. End of song. Pretty oracle-ish. This is also backwards from my experience writing drivers for over 130,000 commercial, consumer and military XENIX and UNIX systems over the past eleven years. If your choice is a lot of questions (we counted questions as problems) from customers about the drivers not finding the hardware, or a few questions about conflicts (which were very few compared to other question categories) the choice is obvious. As a computer operating system company, we also found that dealing with questions about conflicts was far easier than questions about the system not finding hardware. We would tell the user to start pulling cards until the conflict went away. Then put back all but the last one and make sure everything worked. Find out what the remaining card used and change that. Now, what do you tell the user to pull or change when you already have a negative response? Remember, that the user probably doesn't know what resources the hardware uses either, so he/she won't be able to tell you. Subsequently, we would check for hardware at every possible location and setting, rather than miss a piece and suffer a support call on that point. And this was in the days when 8-bit cards were King and IRQ and DMA resources were very scarce. That has been my experience, and so it is my opinion. We must not forget the looming issue of Plug and Play devices, where the entire point is for the drivers and initialization code to work out where the hardware is, can and can't go, and to put it wherever the pieces fit best. When that day comes, more and more drivers would be "autoconfiguring", and our current method of reporting locations back to the to-be-probed drivers and such will have to be replaced. That is down the road a bit as the entire ISA probe/attach mechanism will have to be re-written to handle it. This is certainly not a goal for 2.1, and I doubt anyone has thought about it much as an item for 2.2. It will be nasty. ICU, anybody? Perhaps some of the comments I got (above) are looking forward toward that day, but I think the current scheme will be replaced so what we do now matters little with regard to how things look when these PnP devices become heavily supported by FreeBSD. Actions (1) Based on what I hear above, and assuming that Mike can make a miracle and come up with a way to handle negative numbers after all, perhaps he should look into making -2 acceptable for dynamic assignment, and make sure that "config" will actually accept a -2 (or some character, such as '*') to indicate a dynamic field. This should be done for 2.1. Personally, I would change "?" to be the -2 and "x" to mean the resource is not used, ie -1. Comments on better choices? (Yeah, using "x" isn't traditional BSDish. Neither are a lot of other things we have these days.) (2) On the religous front, "I'll do it to my code if you'll do it to your code." :-) Well, I know that won't happen. However I'll bend, and unless I hear a loud outcry, I'll change the config entry for matcd to not search for its hardware BY DEFAULT and I'll pick one address. Based on the fact that there are several "popular" addresses, my chances of picking a common one are low, but at least that will limit the bi-yearly complaints down to just the 'why-matcd-isn't-using-disk-slice' complaint. :-) This is a config file change ONLY and should be done in sync with Mikes change above. (3) If Mike can't come through with a scheme, a Plan B will be needed, such as documenting that you can't change settings for some devices in "visual". Yuck. Ok, if the comment and/or suggestion is technical and not religious, reply now! Frank Durda IV <uhclem@nemesis.lonestar.org>|"Nobody cares how neat your or uhclem%nemesis@fw.ast.com (Fastest Route)| malloc, pager or filesystem ...letni!rwsys!nemesis!uhclem | is. All they really want ...decvax!fw.ast.com!nemesis!uhclem | is a GUI they are 'used' to." Paraphrased RK.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0t3ZiH-000IvuC>