Date: Sun, 2 Apr 2000 19:17:38 -0400 (EDT) From: "Matthew N. Dodd" <winter@jurai.net> To: "Chad R. Larson" <chad@DCFinc.com> Cc: stable@FreeBSD.org Subject: Re: FIXED --> Thanks! Re: ep0 eeprom failed to come ready... Message-ID: <Pine.BSF.4.21.0004021906590.50194-100000@sasami.jurai.net> In-Reply-To: <200004021821.LAA02427@freeway.dcfinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm not going to bother tearing apart your reply. You obviously have -no- idea what the current state of the PnP system in FreeBSD is. If the FreeBSD kernel -knows- about non-PnP resources then it will not 'remap' PnP hardware to conflict. My discussion of making various ISA device drivers more intelligent in no way alters the behavior of the driver, other than removing the requirement that the user supply the resource information to kernel. This is not about making FreeBSD run only on the latest greatest box; if it were we'd be ripping out ISA support instead of spending time fixing the existing drivers. I'm the -first- person in line in defense of older hardware; I maintain the EISA and MCA support and am working on support for FDDI and Token Ring devices, all of which are for 'dead end' technologies. I don't expect that I'll be behind any move that will result in ISA systems being crippled. :) On Sun, 2 Apr 2000, Chad R. Larson wrote: > 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 > -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | 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?Pine.BSF.4.21.0004021906590.50194-100000>