Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!crcnis1.unl.edu!wupost!howland.reston.ans.net!gatech!destroyer!cs.ubc.ca!alberta!kakwa.ucs.ualberta.ca!acs.ucalgary.ca!cpsc.ucalgary.ca!xenlink!fsa.ca!deraadt
From: deraadt@fsa.ca (Theo de Raadt)
Subject: Re: my bug list
In-Reply-To: bad@flatlin.ka.sub.org's message of Tue, 16 Mar 1993 15: 34:23 GMT
Message-ID: <DERAADT.93Mar26160807@newt.fsa.ca>
Sender: news@fsa.ca
Nntp-Posting-Host: newt.fsa.ca
Organization: little lizard city
References: <1993Feb27.235240.7476@coe.montana.edu> <1mpdb0INNo8a@ftp.UU.NET>
<DERAADT.93Mar11154207@newt.fsa.ca>
<1993Mar15.223046.10278@fcom.cc.utah.edu> <C3yxMK.2Lt@agora.rain.com>
<C3zn9C.GDx@flatlin.ka.sub.org>
Date: Fri, 26 Mar 1993 23:08:07 GMT
Lines: 97
In article <C3zn9C.GDx@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes:
> In <C3yxMK.2Lt@agora.rain.com> rgrimes@agora.rain.com (Rodney Grimes) writes:
> >but I stand behind Terry on this one, it is next
> >to IMPOSIBLE to id all the boards on a ISA bus....
> But that's a completely different problem than what a driver's probe
> routine has to solve. A driver probe routine has to determine if
> there is hardware behind some addresses that works in a way typical
> for the device it's testing for and if that device is properly
> configured. That's a whole lot easier.
I concur. The probe routine is passed (at least) the following specification:
device type (ie, for device type XX, we call XXprobe())
address
irq (or -1 if unknown)
XXprobe() does this: it looks at that address, and checks whether
there really is an XX at that address. It should check if the irq is
correct (or intuit what the irq really is). It should ensure that
whatever it finds there really is an XX.
The config file specifies the possible locations where a device can be
found. I'll give an example from a Sun3 config file:
#
# Support for monochrome frame buffers on various machine types.
#
device bwtwo0 at obmem 1 csr 0xff000000 priority 4 # 3/160
device bwtwo0 at obmem 2 csr 0x100000 priority 4 # 3/50
device bwtwo0 at obmem 3 csr 0xff000000 priority 4 # 3/260
# 3/110 on-board frame buffer overlay plane
device bwtwo0 at obmem 4 csr 0xff000000 # 3/110
device bwtwo0 at obmem 7 csr 0xff000000 priority 4 # 3/60
device bwtwo0 at obmem 8 csr 0x1000000 # 3/E
It's all the same device. There can only be one "bwtwo0", but there
are 6 possible places where it might be found in a sun3-type machine.
The bus config code will call bwtwoprobe() up to 6 times. Each time,
that routine will test the supplied address/irq level to see if the
device is there. If the device does not exist there, it tries the next
one. If it finds the device, it will call bwtwoinit(), and skip all
the other possible addresses.
The config file does more than specify what hardware is in a machine,
rather, it lists all the places where these devices might be found.
As the bus config code proceeds to call the entire list of XXprobe()
routines, it should arbitrate addresses and irq's to ensure that
nothing really funky happens. For instance, if two config file lines
specify the same irq, the second config should never be passwd to
a probe routine.
(Some may say, that for extra points, we should allow devices to share
irq's. Some code would call each of the XXintr() routines in sequence.
If an XXintr() routine thought the irq was not for it, it would return
-1. Unfortunately, the ISA bus uses edge triggered interrupts. If two
cards use the same interrupt, you can lose interrupts.)
This should be perfectly legal in a config file (though it's quite
contrived..)
device com0 at isa? port "IO_COM1" tty irq 1 vector comintr
device com0 at isa? port "IO_COM1" tty irq 2 vector comintr
device com0 at isa? port "IO_COM1" tty irq 3 vector comintr
device com0 at isa? port "IO_COM1" tty irq 4 vector comintr
device com0 at isa? port "IO_COM1" tty irq 5 vector comintr
device com0 at isa? port "IO_COM1" tty irq 6 vector comintr
device com0 at isa? port "IO_COM1" tty irq 7 vector comintr
device com0 at isa? port "IO_COM1" tty irq 8 vector comintr
device com0 at isa? port "IO_COM1" tty irq 9 vector comintr
device com0 at isa? port "IO_COM1" tty irq 10 vector comintr
device com0 at isa? port "IO_COM1" tty irq 11 vector comintr
Of course, I'd rather use this...
device com0 at isa? port "IO_COM1" tty irq ? vector comintr
But then the probe() routine has to be smart enough to figure out what
the irq is. This is somewhat hardware dependent, a few very rare
devices are too dumb to do this, but it's not nearly as much of a
problem as Terry claims it to be. A serial chip can tell you what it's
IRQ is -- it's trivial to generate an IRQ from it. I've seen parallel
hardware that is too dumb (you can generate an interrupt, but do you
really want to send a character to the printer?)
I should be able to swap the base addresses of all the cards in my
system, and the kernel upon boot should find NO devices. Currently, it
will get fooled in some cases. That's simply due to carelessly written
code.
Anyone who wants to look at some good examples is free to take a look
at the probe routines in the vax directory of NET2.
<tdr.
--
This space not left unintentionally unblank. deraadt@fsa.ca