Date: Wed, 6 May 1998 21:40:06 -0600 From: Nate Williams <nate@mt.sri.com> To: Mike Smith <mike@smith.net.au> Cc: Nate Williams <nate@mt.sri.com>, Amancio Hasty <hasty@rah.star-gate.com>, 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: <199805070340.VAA07786@mt.sri.com> In-Reply-To: <199805070230.TAA00410@antipodes.cdrom.com> References: <199805070040.SAA06968@mt.sri.com> <199805070230.TAA00410@antipodes.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Sure. Stick a sysctl variable in there. > > > > Too late. The hardware is already probed. > > You're not paying attention. You will be able to set sysctl variables > earlier than the hardware probes. Sysctl variables can't be set by the user. > > > The principal issue with using the PnP BIOS > > > > .... Forget about PnP BIOS. We need a solution that is *NOT* specific to > > PnP. The solution proposed is way too specific to PnP cards, and we > > need a solution that is slightly bigger than them. > > The solution is to obtain authoratative resource availibility > information. On the ISA platform this can come from PnP, or you can > try to pretend that you know it in advance (use a configuration file). No it can't, since many of these boxes are not PnP boxes. > I'm sorry if you're not aware that the PnP BIOS is the only > authoratative source of resource availibility information. The PnP BIOS is *NOT* authoratative since it doesn't exist on all the hardware the functionality is needed. > If you can demonstrate that there is a fundamental flaw in the proposed > techniques, I'm sure we'd be happy to address the situation. So far > all you've offered is unsupported FUD, which isn't helping the > situation at all. 8( Now you're being silly. I've explained twice now cases where the current proposal is inadequate, and you've called it FUD. You're choosing to ignore what I have to say and then calling it FUD just because it doesn't work with your proposal, and that stinks. Nate 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?199805070340.VAA07786>