Date: Sat, 25 Mar 2000 23:29:49 -0500 (EST) 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.0003252309120.50194-100000@sasami.jurai.net> In-Reply-To: <200003260406.VAA04621@freeway.dcfinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 25 Mar 2000, Chad R. Larson wrote: > This makes me wary. One of the reasons I like UNIX is the assumptions > implicit in its organization that the users might actually know what > they're doing. This has nothing to do with UNIX. 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. > Every time Microsoft and the PC industry have tried to remove the > responsibility and control from the users (EISA--no jumpers, > Plug-n-Pray--no config program), they've generally made things worse. PnP works fine for me. EISA works fine for me. The PeeCee industry didn't do such a bad job on PCI, which not surprisingly, works fine for me. If you want to fiddle around with your hardware and feel 'in control', feel free to play with old VAXen and QBUS or something. 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'. > C'mon. How many of you have had a sound card magically decide to move > back to its old home, right on top of your new Ethernet NIC? Raise > your hands. And how long did it take for you to figure it out? How > many boards did you pull, and then re-insert (rebooting each time) to > see what makes the NIC run again? How many of you have purchased a > shiny new NIC, and then had to go find a DOS machine you could open up > so you could find out how the card was configured? I'm not advocating that drivers 'guess' what config the card has. If you pull your average 3c509 and drop it in a CURRENT box, the driver -will- find the current config. 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. 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. 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. > I mean, if all that stuff would work as intended, it would be a free > ride. But in the real world, it doesn't. The specifications are > poorly published, not definitive, and sometimes partially ignored by > the manufacturers. And you're left with no way to determine what went > wrong, or to fix it if you do figure it out. Again, I'm not coding the drivers to guess wildly. I'm modifying only the drivers for the hardware which I'm able to perform accurate enumeration and resource identification on. > I liked it best when the boards had jumpers and wouldn't move around > in the I/O space unless I told them to. And I didn't have to keep a > bootable DOS around somewhere just so I could "configure" the boards. > And some stray, random panic or mis-behaved program couldn't scramble > your machine's organization. So how exactly does the ability to provide manual 'hints' to the driver help you? Just because you tell the kernel 'hey, I think that there should be a 3c509 at port 0x300, irq 5.' doesn't mean that the driver is gonna magically reconfigure the board for you. (though I suspect I could make it do that, but still.) If you're gonna use non PnP hardware, or hardware which requires software setup then you're gonna have to contend with booting DOS to configure that hardware. I reccomend putting a 10-15 meg partition on all systems anyway. If you don't like this idea, then replace all your ISA hardware with PCI. The PeeCee is tied to DOS even though thats fairly distasteful to use Unix people. Feel free to write a unix based config util for the 3c509 or other boards which you use that require software setup. Until then, you're stuck with DOS. (And at least you're not trying to use ISA boards with an Alpha) > Bah! This, to me, isn't progress. Sure it is. You're just venting about it and don't really have a clear idea what you object to. :) And if you think EISA got your goat you should try MCA (which thankfully doesn't suffer from having ISA slots to contend with.) -- | 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.0003252309120.50194-100000>