Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Jan 2000 13:22:21 -0800
From:      Mike Smith <msmith@freebsd.org>
To:        Warner Losh <imp@village.org>
Cc:        Mike Smith <msmith@FreeBSD.ORG>, Tatsumi Hosokawa <hosokawa@itc.keio.ac.jp>, mobile@FreeBSD.ORG
Subject:   Re: Working pcic polling mode patch (Re: Polling mode of pcic as default?) 
Message-ID:  <200001182122.NAA01429@mass.cdrom.com>
In-Reply-To: Your message of "Mon, 17 Jan 2000 22:42:27 MST." <200001180542.WAA14505@harmony.village.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
> In message <200001170922.BAA02947@mass.cdrom.com> Mike Smith writes:
> : Definitely not.  The IRQ should be determined by examining the machine's 
> : actual resource configuration, with a manual override from the loader.  
> : Of all the possible sources of IRQ configuration information, the kernel 
> : configuration file is the most likely to be wrong.
> 
> Why is pcic different than every other device in the entire system?
> If I want to change the IRQ for a sio line, I do it in userconfig, not
> some whacked out kernel loader env variable.  Why should PCIC be
> different?

Er, because it _is_ different.

With sio devices, you have a set of hardcoded configurations that are 
'typical', and PnP information (which we mishandle in the case when it 
matches the hardcoded expectations).

The pcic is a totally different animal in some respects; in particular, 
its IRQ needs to be selected based on what's actually available in the 
system; something that cannot possibly be determined correctly in a 
pre-built kernel.

Using an environment variable is just a placeholder for userconfig 
becoming a real hint editor; making the pcic IRQ settable inside 
userconfig would require a heap more work than anyone wants to spend.

> Also, this rusian roulette of picking an IRQ is unwise.  It breaks too
> many times.  You must hardwire the IRQ, or use polling.  Examining the
> machine is too unreliable to work.

Er, hardwiring is just persistent state based on examining the machine.  
This is an argument for a polling-only approach.
-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001182122.NAA01429>