Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 06 May 1998 19:51:03 -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:  <199805070251.TAA00511@antipodes.cdrom.com>
In-Reply-To: Your message of "Wed, 06 May 1998 21:40:06 MDT." <199805070340.VAA07786@mt.sri.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.

Sorry?  How are they set, then?

> > > > 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, I have just said "the information can either come from PnP 
or a configuration file".  How does the system being non-PnP prevent me 
from using information from a configuration file?

> > 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.

I'm sorry, but on a system where a PnP BIOS exists, it is authoratative
(or broken, or misconfigured).

It is most needed in systems which contain embedded peripherals;
motherboards with onboard I/O and laptops.  The vast majority of these
systems do support PnP.  Of those that don't, the vast majority again
contain a relatively limited subset of onboard peripherals that can be
successfully managed using a configuration file.

Where the PnP BIOS is able to supply resource information, it should be 
used.  I can't understand why you wouldn't want to do this.

> > 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.

Not at all.  You haven't at any point done anything other than say
"there are systems without PnP BIOS support".  Right now, the way we
handle things we pretend that *no* systems have PnP BIOS support. That
sucks.  We can improve the current situation by taking advantage of the
fact that most systems *do* have PnP BIOS support.  If you can
demonstrate that this act will make the situation *worse*, I'm all ears.

-- 
\\  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?199805070251.TAA00511>