Re: [9fans] Writing device drivers

["David Leimbach" <leimy2k@gmail.com>]

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

Ever written a jump table in assembly?  A table of pointers to
functions works similarly.

Pointers themselves are just a chunk of memory to store the address to
something else in.  Dereferencing a pointer with the * operator is
similar to telling the assembler to retrieve memory stored at the
address in a register.



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

As for your code, I've seen much worse :).

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