From owner-freebsd-hackers Wed May 6 20:47:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA28951 for freebsd-hackers-outgoing; Wed, 6 May 1998 20:47:11 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA28913 for ; Wed, 6 May 1998 20:47:04 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id VAA27159; Wed, 6 May 1998 21:46:54 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id VAA07828; Wed, 6 May 1998 21:46:50 -0600 Date: Wed, 6 May 1998 21:46:50 -0600 Message-Id: <199805070346.VAA07828@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mike Smith Cc: Nate Williams , Archie Cobbs , stefan@promo.de (Stefan Bethke), luigi@labinfo.iet.unipi.it, freebsd-hackers@FreeBSD.ORG Subject: Re: ISA-PnP w\o BIOS support? In-Reply-To: <199805070234.TAA00433@antipodes.cdrom.com> References: <199805070039.SAA06961@mt.sri.com> <199805070234.TAA00433@antipodes.cdrom.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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. So, your PnP solution doesn't even begin to solve the problem I'm having. 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. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message