Date: Thu, 7 May 1998 21:15:40 -0600 From: Nate Williams <nate@mt.sri.com> To: Mike Smith <mike@smith.net.au> Cc: Nate Williams <nate@mt.sri.com>, "Jordan K. Hubbard" <jkh@time.cdrom.com>, Archie Cobbs <archie@whistle.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: ISA-PnP w\o BIOS support? Message-ID: <199805080315.VAA12411@mt.sri.com> In-Reply-To: <199805080158.SAA00834@antipodes.cdrom.com> References: <199805071455.IAA09315@mt.sri.com> <199805080158.SAA00834@antipodes.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Something that is not PnP specific, but allows a person to allocate > > resources to non-ISA devices. > > This has absolutely nothing whatsoever to do with the original sysctl > reference (passing out-of-band behavioural configuration information to > an arbitrary driver). > > > Current situation: > > controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr > > > > What I'd like to be able to do: > > controller card0 at generic flags 0x1 irq ? > > > > The 'at generic' stuff is open to discussion, but I need a way of saying > > 'I *WANT* that IRQ, and you can't have it!" > > What you've just said is "I want to tell the driver to find its own > IRQ". I don't think this is what you meant. No, what I said is what I want. IF you have a non-ISA device, you can't tell FreeBSD that it has this IRQ. > I actually believe that the above syntax is wrong. I would be *more* > inclined to try: > > controller card > options "CARD_IRQ=10,11" > Options that control a particular device are *stupid*, and have been removed for th emost part. (I've even been one of the instigators of them, and they should be taken out an shot, but because of the above limitations there were not other alternatives.) > > Also, I'd like to see: > > controller irqsink0 at generic irq 11 > > controller irqsink1 at generic irq 13 > > > > For hardware that doesn't have any driver in FreeBSD so I can say > > "*DON'T* use this IRQ, it's in use." > > Why create a (totally bogus) driver? Because FreeBSD doesn't (and won't) support all of the available hardware. I'm trying to moving FreeBSD towards a more 'dynamic' system, and I'm being fought the entire way. > > Excpecting the users to know/understand each and every tweakable know is > > ludicrous. By making the knob/hooks settable in the config file > > (something they already know how to deal with, or will know how to deal > > with) means it's *really* obvious which device they are messing with, so > > the learning curve is much less. > > This is (IMO) bogus. Stuff set in the kernel configuration file is no > easier to manipulate than sysctl variables. Sure it is. I know how things are setup in the kernel config files. I can tell how to do things by doing a man 'foo', and it'll return me all the things that affect the foo driver, just like I've come accustomed to. (And this knowledge is in *ONE* place, not scatterred all over the system.) > On the other hand, if > stuff is compiled into the kernel, you're screwed if you want to tune > it at startup. You're not 'tuning' anything. You can modify it like we do everything else in userconfig, which is the 'standard' model we now use. > You're more than welcome to veneer over the fact that the startup > tunables are sysctl variables; sysctl is a parameter access method, not > a user interface as you appear to have mistaken it for. Doing something different just because you think it's a good ida doesn't make it a good idea. Duplicating functionality that already exists is adding 'Yet Another Thing to learn', when it's booth un-necessary and provices no additional functionality. Unix is already hard to learn, we're adding yet more crap for people to figure out. Instead of makign it easier, we're adding even more 'esoteric' configuration for them to understand. At least with things like M$ registery settings, the average user is never subjected to messing with it, but in our sysystem we invent new ways to confuse the user and require him to have an even steeper learning curve, because everyday we come up with something 'new' and better than what we did, which is neither new nor better, just different. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805080315.VAA12411>