Date: Wed, 06 May 1998 19:30:16 -0700 From: Mike Smith <mike@smith.net.au> To: Nate Williams <nate@mt.sri.com> Cc: Mike Smith <mike@smith.net.au>, 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: <199805070230.TAA00410@antipodes.cdrom.com> In-Reply-To: Your message of "Wed, 06 May 1998 18:40:52 MDT." <199805070040.SAA06968@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > The device driver can tell the upper layer which resources it wants or > > > > does not need. > > > > > > The device driver needs a hint from the user to know whether or not it > > > wants a resource or not. > > > > 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. > > 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). I'm sorry if you're not aware that the PnP BIOS is the only authoratative source of resource availibility information. If you care to either read what I've been posting or the standards themselves you would have some understanding of the relationship between the manual BIOS configuration of PnP hardware, non-ISA-PnP configuation in the BIOS domain, and the determination of available assignable resources by an operating system. If you believe that you have a pathological case where this combination is inadequate, please feel free to publish it. I'll compare it with my list, and see if the proposed new techniques make the situation any worse than it currently is. 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( -- \\ 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?199805070230.TAA00410>