Date: Wed, 06 May 1998 19:34:41 -0700 From: Mike Smith <mike@smith.net.au> To: Nate Williams <nate@mt.sri.com> Cc: Mike Smith <mike@smith.net.au>, Archie Cobbs <archie@whistle.com>, stefan@promo.de (Stefan Bethke), luigi@labinfo.iet.unipi.it, freebsd-hackers@FreeBSD.ORG Subject: Re: ISA-PnP w\o BIOS support? Message-ID: <199805070234.TAA00433@antipodes.cdrom.com> In-Reply-To: Your message of "Wed, 06 May 1998 18:39:33 MDT." <199805070039.SAA06961@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Things is, this falls really short for non-ISA/non-PnP devices as well. > > > > No, it doesn't. But I may not have answered your specific qualms. > > > > > Think hot-swappable devices, and devices that *really* no one knows > > > about? > > > > Yes, what about them? How about a concrete problem rather than FUD? > > 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". > > > Also, devices that can use IRQ's, but don't necessarily need > > > them. How do you say 'go ahead and use it', vs. 'don't bother'. > > > > Huh? You must specifically be talking about the resource starvation > > case where the "can but don't have to" device comes up before a "must > > have" device and takes the last interrupt. > > 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? If you have a free IRQ that isn't needed, it doesn't matter if it's assigned to a source that never drives it, or whether it remains free. > > Firstly, there aren't too many devices in the "can but don't have to" > > class, so this is a pathalogical example. > > But it's an example of something we need to have now. (Like, if it were > there, I could use it today.) > > 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? Are you bitching about the current interrupt registration mechanism, or about free resource determination? > 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. And you're thinking *much* too narrowly about when sysctls can be set. -- \\ 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?199805070234.TAA00433>