Subject: Re: Documentation for autoconf system
To: None <bjh21@netbsd.org>
From: None <jkunz@unixag-kl.fh-kl.de>
List: tech-kern
Date: 04/22/2001 00:54:08
On 21 Apr, Ben Harris wrote:
>>Figuring out is the probem. Every one has to reverse engeneer existing
>>drivers if he wants to know how to write a new one.
> Well, you can always read the code in subr_autoconf.c that runs it all.
This is exactely the answer I wanted to hear. ;-)
"RTFSC" (Read The F*** Source Code) is not an adequate answer to a
newbe, that has no knowledge about the _concept_. There should be some
kind of doc that explains the basic concept (like the man pages in
sction 9). Then, if the concept is known, the source should be studied
to explore the details. Diving into the source without knowing the
concept is a very frustrating task. I went through this while developing
a SSL application using OpenSSL...
Don't get we wrong. I don't want to be unkind to the NetBSD developers,
because I miss some doc. They do great work (See the good news about SMP
on alpha...) and they have my highest respect as they are "gurus".
And of course, I am a software developer too and I know how boring it is
to write docs. ;-)
> No. One's a struct cfattach, the other's a struct cfdata.
Ups, yes. Sorry I am stupid. ;-)
> The struct cfdata is the internal representation of a line of a kernel
> config file (like "foo* at bar? slot ?").
Ahhhmm. And what can I do with this? What is the purpose of passing
this struct to the match routine?
> That's the case for those busses where this is possible (PCI, SCSI,
> podulebus). For busses where the autoconf code (actually, the code in the
> parent driver) can't work out what's there (e.g. ISA) things work a little
> differently, but I'm afraid I don't know quite how.
[inspecting some of the ISA/EISA drivers]
I think that is the reason why some kind of address has to be specified
for devices on those busses. ISA devices usualy have a
foo at isa? port 0x300
or
bar at isa? iomem 0xd8000
or in case of a Unibus/Qbus
ts0 at uba? csr 0172520
line in the kernel config file. So the autoconfig stuff knows the
address on whitch to probe. Now I understand why the device is only
detected if it is at exactely this addess, even if it is present at an
other address, and why it is not possible to specify a wildcard if the
device has no special handling for this. Some drivers, like adv and
ahc, don't get an address. They are probing a set of common addresses
using a for loop to iterate on this set...
Thanks for this comment.
--
tschuess,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz