From owner-freebsd-hackers  Sat Feb 24 06:09:14 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id GAA04536
          for hackers-outgoing; Sat, 24 Feb 1996 06:09:14 -0800 (PST)
Received: from relay.hp.com (relay.hp.com [15.255.152.2])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA04514
          for <freebsd-hackers@freebsd.org>; Sat, 24 Feb 1996 06:09:07 -0800 (PST)
Received: from fakir.india.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA121960935; Sat, 24 Feb 1996 06:09:01 -0800
Received: from localhost by fakir.india.hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.3) id AA023091230; Sat, 24 Feb 1996 19:43:50 +0530
Message-Id: <199602241413.AA023091230@fakir.india.hp.com>
To: Terry Lambert <terry@lambert.org>
Cc: freebsd-hackers@freebsd.org
Subject: Re: ISA device irq/mem auto-configuration 
In-Reply-To: Your message of "Thu, 22 Feb 1996 11:04:00 MST."
             <199602221804.LAA21281@phaeton.artisoft.com> 
Date: Sat, 24 Feb 1996 19:43:49 +0530
From: A JOSEPH KOSHY <koshy@india.hp.com>
Sender: owner-hackers@freebsd.org
Precedence: bulk


>>>>> tl == Terry Lambert said: 

tl> If you could actually tell what it was configured for...
tl> Only "how do you know the board is at IRQ 11 when the probe code
tl> has to assume the interrupt for the probe to work?".  8-).

Not a problem on some boards: you can read h/w configuration registers
to figure out the IRQ that it has been configured to use.  Now, this 
can only be done if one is reasonably confident that the particular kind
of card is actually present so its best done /after/ a non-invasive
probe!

tl> I think this falls into the category of space assignment.  
tl> It's probably not possible to safely relocate the board ...

Well, the question was if it was possible to update the kernel
internal data structures to suit the hardware configuration (not vice-versa).  
The answers I got from the list seemed to indicate that it was ok to do so.  
Following the probe, the kernel apparently does a conflict resolution pass 
after all the drivers have been probed.

So this is what I plan to do:

(a) compile in wild-card defaults for IRQ, Mem address etc 
(b) at probe time if these are wildcarded use the hardware info, else print 
    out an informative message about the mismatch but leave the driver disabled.

    This allows the user to explicitly specify driver settings using boot -c 
    and have the boot process honor them.

Koshy