Date: Thu, 07 May 1998 18:58:58 -0700 From: Mike Smith <mike@smith.net.au> To: Nate Williams <nate@mt.sri.com> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, Mike Smith <mike@smith.net.au>, Archie Cobbs <archie@whistle.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: ISA-PnP w\o BIOS support? Message-ID: <199805080158.SAA00834@antipodes.cdrom.com> In-Reply-To: Your message of "Thu, 07 May 1998 08:55:45 MDT." <199805071455.IAA09315@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > No, it's a poor solution, and should NOT be used anymore than it already > > > is. It's worse than IOCTL's, and it's becoming the garbage dump for > > > everything that we don't have easy solutions for, thus making the system > > > that much harder to understand and configure. > > > > Hmmmm. Rather than tell us about what's wrong with sysctl, such > > criticism being hardly new or even particularly valuable, why not tell > > us what you'd rather see implemented and how you might, given the > > time, go about doing it? > > 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. Specifying a fixed IRQ is only suitable for hardware with a programmable IRQ in a system where resource availibility cannot be determined. I actually believe that the above syntax is wrong. I would be *more* inclined to try: controller card options "CARD_IRQ=10,11" Which allows for multiple PCIC instances and gives a list of IRQs to use. Alternatively, and something that I implemented a while back: controller card options "RESERVED_IRQS=((1<<10)|(1<<11))" where the latter specifies a list of IRQs that are not available for general use. You could reverse the sense of this and define a pool of system resources in EISA format which could be used as a substitute for the information that would normally be obtained from the BIOS. In the absence of this, you would just fall back to the current situation. > 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? > 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. On the other hand, if stuff is compiled into the kernel, you're screwed if you want to tune it at startup. 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. Duplicating namespaces for the sake of it is a poor idea. Suggesting that multiple access methods is "better" than a single access method and a wider namespace is just silly. -- \\ 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?199805080158.SAA00834>