Date: Fri, 08 May 1998 23:44:07 -0700 From: Mike Smith <mike@smith.net.au> To: Nate Williams <nate@mt.sri.com> Cc: Mike Smith <mike@smith.net.au>, "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: <199805090644.XAA00836@antipodes.cdrom.com> In-Reply-To: Your message of "Thu, 07 May 1998 21:15:40 MDT." <199805080315.VAA12411@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
(Sorry, I took a day to do some more interesting things.) > > > 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. Duh. Like I don't know this? But you contradicted yourself when you said "I want to be able to say ... irq ?" where this is supposed to assign a given IRQ to the device. > > > 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. You have got to be kidding. Compile-time constants are not "dynamic" in any sense of the word. I'm not opposing you, on the contrary it's you opposing my suggestions. This whole discussion started when I suggested that it would be sensible to make use of the available resource-related information in order to require less static configuration information in the majority case. > > > 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 Ah, so "easier" means "easier for me". I think you'll find that most people consider an interactive configuration process a lot "easier" than having to install and build the kernel sources. If you're really concerned about this issue, there are better directions you could be channeling your effort in. > > 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. My point exactly. Sysctl exists. It works. Don't duplicate something it does perfectly well because you don't like it. Again; sysctl is an access method, not a user interface. If you don't like the user interface, try griping about that instead. > 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. Decaf, Nate. Decaf. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199805090644.XAA00836>