At 23:28 Uhr 02.10.1996, briggs@puma.macbsd.com wrote:
>> Well, I wish the NetBSD device driver framework was only _half_ as easy
>> to see through as the IWM code.
>
>I know what you mean.
>I'm terribly guilty for not documenting much of anything.

Who am I to object. :)

>Actually, 'aux' on the mac68k platform is a pointer to a
>'struct confargs' (defined in autoconf.h).  This contains two
>elements, 'bustype' and 'slot'.  For obio, the bustype is 0,
>which looks like "" when you treat it like a string.  'slot'
>is ignored for obio.

So there! I had already considered that this is a feature of obio. After
all, the obio concept involves the fact that child devices are available on
a CPU model basis and are not removable like an ethernet card or a scsi
device.

>Basically, autoconf.c:configure() calls config_rootfound().  This goes into
>mainbus.c, which cascades into obio.c and nubus.c, each of which probes
>the "devices" on those "busses."

This is what you get when you try to implement advanced models with a
rather low-level language like C. You end up passing void * pointers and
your interface definitions cease to tell you anything about the data that's
actually passed along. Then you cast the pointers to something that's
defined in one of a dozen include files or even in a file included by
another... It literally takes years to see through all this when you do it
as a spare time task.

>There is a distinct lack of kernel-level
>documentation of any detail.  I think this is a combination of
>several things:
>
>        * It's in constant flux.  Of varying degrees, and some things
>          have not changed in years.

Can you say 'MI bounce buffers'?

>        * There's always something more interesting to work on than
>          documenting what's running.

*BSD has a big disadvantage here since it took over an existing code and
documentation base. The l*nux guys started many things from scratch and
simply _had_ to document things to keep the project running. AFAIK, they
now have a doc group, and then there is the kernel hacker's guide. For all
the stuff that has changed in NetBSD since the merge of 4.4BSD lite, there
is virtually no information on design ideas besides sparse comments in the
sources. Sure, you can always try to spot the author and bug him...

>        * "anyone who needs to know can look at the code to figure it
>          out."

For me, part of 'quality code' has always been sufficient commenting _and_
documenting. But I am under the impression that it is more important that
NetBSD sources be tabbed according to KNF than that they are documented...

>That said, at least a couple of folks on current-users (I think that's
>where they're hanging out) have been working on section 9 (kernel) man
>pages.

I am not sure that the NetBSD autoconfig scheme is something you can make a
man page about. There has to be sort of a stairway from an abstract CS
concept down (up?) to the source code - overviews, tech notes & other forms
of documentation, comments, finally 'speaking' names. The more steps are
left out, the less people will reach the other end. What is sorely missing
here is a paper or even a book on writing NetBSD device drivers. This could
be especially interesting because machine independence is an important
aspect.

>Perhaps you can contribute something there when you get it
>figured out...  ;-)

I shall start with iwm(4) ...
Seriously: We lack knowledge of design and overall concepts here, and of
their relation to the implementation. I did not design all this, and I am
only working my way through it as far as it is necessary to write this
driver - question of economy.
Let those tell the story who did the work...



	hauke

---
"It's never straight up and down"     (DEVO)