From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3e1162e60604141233y56c46ab2ra055829e28029fa5@mail.gmail.com> Date: Fri, 14 Apr 2006 12:33:33 -0700 From: "David Leimbach" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Writing device drivers In-Reply-To: <820bc1260604140836p4ba0baby9b9ef3d081d2fb51@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8a5bd8ccbc2e53557663e2a9020fb26c@coraid.com> <820bc1260604140834v2a773ev90ff46b4e6b2427f@mail.gmail.com> <820bc1260604140836p4ba0baby9b9ef3d081d2fb51@mail.gmail.com> Topicbox-Message-UUID: 36a18b54-ead1-11e9-9d60-3106f5b1d025 > 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 elude= d > 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 proje= ct. > 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 re= ad > 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 overboa= rd > 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 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 > > > > > > > > > >