Thank you SO much -- this was just the sort of thing I needed.  Pointing out the ethernet interface, /sys/src/9/pc/devether.c, and small, easily understood, sample drivers like etherec2t.c and ether2000.c is just what I needed.

And you guessed it -- I have spent zero time in kernel mode.  But I'm anxious to try :)

Use of pointers in C has always been a sticky point for me although it shouldn't be.  Because I have a background with low-level languages like assembly I thoroughly understand doing things in memory, registers, etc, but for some reason, understanding the _why_ of using pointers in C has eluded me -- like what is to be gained by accessing functions via a table of pointers.  But that is just what I hope to learn by working on this project.

Truly, though, my C sucks.  I do hope to improve it through this ... I do hope to succeed.

But to give you an idea of how horrible my C is I've attached a piece of code I wrote for a (hobby) microcontroller project.  This is for an 8-bit Atmel RISC.  I know this bears little relation to a device driver living in kernel space -- and no one would write non-blocking code like this as a device driver.  But it's probably the best example I have (attached).

Please pardon the heavy comments -- that is the one thing I have learned about C:  I can go back and look at old, say, Pascal code of mine, and read it.  But 6 months after writing a little piece of C it's tough for me to read it and figure out what in the world I was thinking.  So I go overboard with the comments.

I realize I'm submitting my sorry C code to a group of really strong C programmers -- if nothing else it should provde some amusement :)

Thank you for your help!!!!

Regards,
Eric


On 4/14/06, Brantley Coile <brantley@coraid.com> wrote:

Interesting question.  I just spend a few moments looking around and
thinking about suggestions for helping you up the learning curve.  The
more I thought about it, the more I wondered where you were already on
that curve.  Recommendations depend on that sort of thing.

Suggestions break into three parts: C skills, general device driver
skills, and Plan 9 specific knowledge.  The C skills fall into three
categories: the syntax and semantics of the language, common
techniques and paradigm, and skill in software design, constructing
solution from small functions and that sort of thing.  The syntax and
semantics problem can most easily be fixed by a quick re-read of Brian
and Dennis' book, the famaous K&R.  Most likely you've read that
before, but I re-read it every few years or so.  Amazing that a
language so small can take a life time to fully learn.  (And I'm not
talking about C99.)

Common techniques and paradigms, since you want to write a Plan 9
device driver, is best learned by reading Plan 9 code.  Lots of nice
small things in /sys/src/cmd are great for this.  As with natural
languages, the best way to learn to write is to read.  I owe
everything to this principle.

The skills in design are much harder to obtain.  You may already be
strong in this department since it's not unique to C. The two
attributes of cohesion and coupling are the key ideas here.  Good code
in Oberon, Java, C, PL/I or COBOL are all the same.

Brian and Rob's book, `The Practice of Programming' is the best
I know of for this kind of stuff.

I assume from your comment that you time spend writing stuff in kernel
mode is limited.  Sorry if this isn't the case.  Things you should
learn include, the restricted context of kernel mode, the issues
regarding locking in the multiprocessor Plan 9 kernel, how interrupt
handlers get registered and called, limitations on what you can do in
the interrupt handler, how processes sleep and wakeup, and more.
Interfacing to the under part of Plan 9 is easy.  It's just a 9P
server with function calls instead of messages.  Simple device drivers
in like /sys/src/9/pc/devrtc.c show how the device driver interfaces
with the system.

But you want to write a driver for the WPN311, so you'll need to study
the ethernet interface in /sys/src/9/pc/devether.c, and look at an
ethernet sample driver like etherec2t.c and ether2000.c .  These are
pretty small and show how to glue into the devether.c code.
Devether.c factors out all the common work of ethernet drivers and
uses a table of pointers to functions to get the specific work done by
a given driver.

Hope that helps some.  I've never written a wireless driver so I don't
know about any specific gotchas with that.  Good luck on it.  It's a
great feeling to get a driver working.

Brantley