Date: Wed, 06 May 1998 20:13:22 -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: <199805070313.UAA00577@antipodes.cdrom.com> In-Reply-To: Your message of "Wed, 06 May 1998 21:46:50 MDT." <199805070346.VAA07828@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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 > the Hitachis. Ok, now we're getting somewhere. Do you actually know that the systems in question don't have PnP BIOS functionality? What tests are you using? Have you tried the ESCD BIOS calls? > So, your PnP solution doesn't even begin to solve the problem I'm > having. Ok. But it solves a lot of other peoples' problems. The fact that it might not be the magic bullet _you're_ after doesn't alter the fact that it's a huge improvement over the current situation. > 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. It's nice to see that a few obscure laptop systems are a "majority" and the relatively larger set of desktop systems are a "minorty". Just as a counterexample, using the PnP BIOS would have illuminated a number of resource problems on Sharp and larger Toshiba laptops. Not to mention the interesting problem where anyone with an onboard LM78 on a new motherboard seems to have an ISA LANCE at 0x280. We can, actually, talk to the PnP BIOS. There are a few technical issues outstanding, and obviously plenty of work to do. I'm not presenting a fait accompli, merely suggesting that these facilities exist for a damnned good reason, and ignoring them is stupid. > > > 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. Er, Nate. I just said "it doesn't matter unless there is resource starvation". Then you said "even if there isn't resource starvation, it matters". Now you say it only matters because there is resource starvation. We both know who argues like this. Please don't make my job harder by obfuscating the issues. Yes, resource starvation is a problem. Yes, we need to be able to do something about it. No, obtaining more accurate resource availbility information from the BIOS is not going to suddenly result in even more resources being stolen away from your rare but no doubt serious problems. The answer lies in providing extra information to the driver(s) in question so that they can take advantage of this information to avoid wasting resources. If this information isn't available from any other source, we have to provide a new source. I have proposed using an already existing and known functional information management infrastructure to provide this extra information. I don't see you even acknowledging this, let alone considering how it might be used to your advantage. > > > 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. Why is a shared interrupt not a "real" interrupt. Any why would you care about "setting" PCI interrupts? You're not _allowed_ to "set" PCI interrupts. This is the job of the BIOS. > > 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...) So statically allocated resources are bad, right? Am I arguing for or against statically allocated resources? > > > 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. I'm not sure what you are calling a "poor solution". A unified parametric namespace is a good idea. The sysctl implementation is flawed and inadequate in many ways. However, it *works*, and for what you are specifically griping about, it's more than adequate. > > 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. Bad sysctl. Bad, bad sysctl. Naughty sysctl. Now tell me how else I can do it. -- \\ 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?199805070313.UAA00577>