> > 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.
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!"
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."
I want the user to have control of what's going on at compile time, and
I'd like the ability for the user to be able to re-configure it at
userconfig time as well.
The problem with sysctl is that it's trying to be all things to all men,
and like M$ Registrty, it becomes too complex and unweildy since *all*
configuration is dumped into it's bowels, so keeping the namespace sane
is almost impossible. And, assuming you've done a good job of keeping
the namespace separated out, you have to understand *how* it's separated
in order to use it, which means that your average user won't know which
know to tweak until after he's read the poorly documented 14 page book
that explains each of the sysctl knobs.
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.
Nate
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message