According to Eduardo E. Horvath:
>
>It's a good start, but most of that seems to be generic `how to write
>a driver' stuff that should already be covered in the daemon book.
>

I was actually an attempt to document how to write a pseudo-driver, I
was putting down the information I had to dig out by hard skull work
:-).  I found the daemon book (I have both editions) not much help
with anything more than the generic function entry points and basic
driver structure.  I suppose I should have another look and see if I
can get some info about some of the parameters to the function calls.

>The two things we really need documented are how to use the bus_space*
>and bus_dma* interfaces, and the specific bus-dependent details:
>

Agreed - I do have a copy of a document that was sent to me by someone
else that is the start of a howto on writing a PCI driver.  I will see
if I can get permission to release it from the author.  I was thinking
of merging my document with the PCI one, a lot of the information is
common.  To me, it makes sense to start with a "this is how a
pseudo-driver is written" and then go onto a real device (be it PCI,
SBUS, whatever) driver with a broad brush statement along the lines of
"most of the stuff is the same as a pseudo-driver EXCEPT that you need
to write a probe routine and handle device i/o" and go on to describe
those parts.

>
>That's not to say that the bus_space* stuff is not documented, but a
>tutorial would be nice, and easier to plough through than the current
>manpages.
>

Yes, there seems to be a steep learning curve on writing a driver.
Parts of the process are not terribly well documented and it takes a
bit of "prior art" study to work out what to do.

>
>(I can't help you with PCI since I haven't poked around in the guts
>of the PCI framework enough yet.  Although that may change soon.)
>

Same here.  I _may_ get off my arse and do a PCI driver yet - I have a
couple of voodoo2 cards in my machine that it would be nice to have a
/dev/3dfx device for ;-)

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, BAE SYSTEMS
===============================================================================