> > There's no FUD. You just erased my specific examples.
> I haven't seen a single example situation from you yet where knowing
> what is and isn't actually available/used is a disadvantage over the
> current state of "blessed ignorance".
Huh? You're claiming that PnP is the answer to all my problems, and the
fact of the matter is that none of the hardware that has these problems
have a PnP bios, so it solves nothing.
My 560 doesn't have a PnP BIOS, and neither does Warnar's Libretto, nor
do any of the ThinkPad's that I have access to, nor the NEC's, nor do
So, your PnP solution doesn't even begin to solve the problem I'm
You're spreading misinformation by stating that the PnP BIOS is the
panacea to all of the resource problems, when in fact it only solves a
minority of the problems that people are seeing, and in fact we can't
even talk to the PnP BIOS so it's not even a workable solution yet.
> > No, I'm talking about cases where hardware *can* use IRQ's, but don't
> > need them.
> Unless there is a resource starvation issue, who cares?
Because there *is* resource starvation. There aren't very many free
interrupts on a laptop with built-in sounds, and IR port, plus a couple
of PCMCIA/CardBus adapters.
> > Right not, to get a 'real' interrupt, you must be an ISA device.
> > Otherwise, you've got to hope for the best. This is simply bogus.
> I'm not sure I understand what you're talking about. What are the
> interrupts delivered to PCI devices if not "real" interrupts?
Because they are sharable, and because I don't have any control over
setting them in FreeBSD.
> Are you
> bitching about the current interrupt registration mechanism, or about
> free resource determination?
Both. To allocate resources at compile time, the device must be an ISA
device. (Resources include things like flags, interrupts, etc...)
> > And, sysctl is a *huge* hack that's completely incapable of dealing with
> > it. You can't tell a device to not use an interrupt via a sysctl, since
> > by the time the syctl is active it's much too late.
> sysctl is a poor implementation of a good idea. Despite my good
> intentions and support from a number of sources, a replacement hasn't
> materialised. In the interim, it is more than adequate for the task.
It's a poor solution that should *NOT* be extended.
> And you're thinking *much* too narrowly about when sysctls can be set.
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.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message