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
>
>
>