Date: Sun, 2 Apr 2000 11:20:59 -0700 (MST) From: "Chad R. Larson" <chad@DCFinc.com> To: winter@jurai.net (Matthew N. Dodd) Cc: stable@FreeBSD.org Subject: Re: FIXED --> Thanks! Re: ep0 eeprom failed to come ready... Message-ID: <200004021821.LAA02427@freeway.dcfinc.com> In-Reply-To: <Pine.BSF.4.21.0003252309120.50194-100000@sasami.jurai.net> from "Matthew N. Dodd" at "Mar 25, 0 11:29:49 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
As I recall, Matthew N. Dodd wrote: > On Sat, 25 Mar 2000, Chad R. Larson wrote: >> This makes me wary. One of the reasons I like UNIX is the assumption >> implicit in its organization that the users might actually know what >> they're doing. > > This has nothing to do with UNIX. Sorry for the delayed response. My day job got in the way, but now it's the weekend. There are actually two related but separate issues we're discussing. The first is hardware configuration, and how it's accomplished. The second is how should the kernel know where that hardware was configured. And part of what makes them related is my contention that automating either of those hasn't made life better. About the first: > If you want to fiddle around with your hardware and feel 'in control', > feel free to play with old VAXen and QBUS or something. At least, when I was admining VAX 11/780 systems, the I/O boards didn't move around within their address space without me telling them to (which involved a thin-nosed pliers and some jumpers). For that matter, neither did the I/O cards in my S100 buss Altair. Or my PDP-11s. Or...never mind, you get the idea. > If you've got totally broken hardware that doesn't stay where you tell > it then you're pretty much fucked, and hints aren't gonna fix your > problem. But PnP hardware ignorant exists. And no amount of your wishing will make that that go away. Do you think FreeBSD should only work only on the latest box Dell ships? When your PnP BIOS thinks it knows what the hell it is doing, and moves your PnP aware sound card on top of your PnP ignorant Ethernet card, you're screwed. And in your proposed brave new world, the owner of the machine has no way out, as you've eliminated his ability to override what you've decided is best for all of us. Further, the manufacturers of PnP (and before that EISA) cards subscribe to the theory that only Microsoft operating systems exist, and that it is therefore sufficient to provide configuration tools that only run in Microsoft's environment. That provides further annoyances for those of us who prefer not to have anything to do with Microsoft and its world domination plans. And on to the second issue: > This has everything to do with being able to determine card config > without user intervention. If I can give the driver the ability to > detect the board and retreive its config with 100% accuracy then thats > a far better solution than trusting the user to remember the settings > and properly communicate them to the kernel. You =can't= "detect the board and retreive [sic] its config with 100% accuracy", for the reasons I mentioned in my earlier message (insufficient specifications, vendors who mis-interpret or ignore those specifications, etc.). And by removing access to the lower level knobs, you increase the support load because administrators have no work-around for breakage. Making system architecture decisions based on wishful thinking is just plain silly. And "trusting the user" is what this discussion started about. > My goal is to reduce support load by taking advantage of the features > of the hardware that permit the kernel/drivers to 'do the right > thing'. An admirable goal. Just not realistic given the current state of Pee-Cee hardware. It will lie to you. Or be invisible and therefore deceive you. And we've already discussed why that goal will not reduce the support load. I don't mind you taking a "first cut" at a configuration. I object to your stated goal of removing any configuration control from the system administrator. The part where you say the kernel config file doesn't even need an entry for, say, an "ep" driver, and that it will ignore it if it exists. This =is= about control. I want to be able to control where my hardware resides within its address space. On the other hand =you=, in collaboration with the hardware vendors, want to control where my (and everyone else's) hardware resides within its address space. Can you give me a good reason why I should delegate that authority to you? And don't offer: "It makes it easier for newbies." If I bought that, then I should install Windows '98, because it installs on more different hardware than FreeBSD will ever see, without the user having to know anything other than how to work his CD-ROM tray. > If you pull your average 3c509 and drop it in a CURRENT box, the driver > -will- find the current config. Assuming the vendor built his card close enough to what you believe the specifications say. And the EEPROM hasn't faded. And some wild-assed application (running under a Microsoft operating system that doesn't provide isolation between the applications and the hardware) hasn't scrambled its brains. And there isn't an ISA, hardware jumpered board at the same address as was being used in the machine I pulled the 3c509 from. It's good you chose that example. I went through =exactly= that exercise two weeks ago. A 3c509B which wouldn't do squat. Even the 3Com MS-DOS configurator program claimed there were "no Etherlink cards found" until I pulled out the Creative Labs Soundblaster that was in there. > It will even use that config if nothing else is conflicting. The > ability to manually provide 'hints' isn't going to alter the config of > the card. I'm not advocating "hints". I'm saying I should be able to tell the kernel exactly where to look (IRQ, DMA channel, memory window, I/O port) for any particular piece of hardware. And the kernel should not have to go on some spelunking expedition to find it. > If you go slapping new hardware in a box without making sure its set to > non-conflicting resources then you get what you deserve. Hints aren't > gonna fix that problem either. And, "making sure its [sic] set to non-conflicting resources" is the issue at hand. How does one set the resources if you and the board makers insist that it's your province? Ok. So if you are going to invest programming effort, give me a tool that allows me to set any PnP compatible device exactly where I want it to be (without booting MS-DOS). Put a smarter, configurable version of the PnP BIOS functionality into the loader, for example. And then I'll make sure my kernel matches up. Or, if you insist on automation, have the kernel jam any PnP-capable device to wherever the kernel has been configured to expect it, rather than for the kernel to try to guess where the PnP-capable device has been set by some <unknown-uninteresting> utility. -crl -- Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm? chad@dcfinc.com chad@larsons.org larson1@home.net DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004021821.LAA02427>