Re: [9fans] Writing device drivers

Re: [9fans] Writing device drivers

[Eric Smith]

[-- Attachment #1.1: Type: text/plain, Size: 4772 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 5682 bytes --]

[-- Attachment #2: acq.c --]
[-- Type: text/x-csrc, Size: 10800 bytes --]

/* vim: set sw=8 ts=8 si :
* Author                : Eric Smith
* Date                  : July 2005
* Chip type             : ATMEGA8
* Clock frequency       : 400 kHz (external ceramic resonator)
* Program		: acq.c
* Number		: 0x0A
* Data Format Version	: 0x1A
*
* This program acquires data from three sensors and stores in EEPROM.
* Data from one of the three sensors (jumper selectable) is displayed on
* PORTD's 8 LED display.  EEPROM writes occur once per write interval
* which can be once per second, minute, five minutes, or hour.  After EEPROM
* is full, or SS_WRITE_ENABLE jumper is unset, writes will cease, however,
* the display will continue to update constantly.
*
* Data Format (ver 0x1A):
*				EEPROM @ 0x000 = Program Number
*				EEPROM @ 0x001 = Data Format Version Number
*				EEPROM @ 0x002 - 0x1FF = 170 3-byte records
*				Record Format (3 bytes):
*						Byte 0 = thermistor
*						Byte 1 = photocell
*						Byte 2 = magnetic
******************************************************************************/
#include <avr/io.h>
#include <inttypes.h>

/* GLOBALS */

// JIFFIES_CONSTANT should be set to the number of times the program
// can pass through the main loop in one second.  This will be the basis for
// setting the write interval (1 per sec, 1 per min, 1 per 5mins, or 1 per hour)
// While this processor is capable of running on a 16 MHz clock we are loping
// along at 400 kHz to save power ... which is ok: there's no rush.
const unsigned long int JIFFIES_CONSTANT = 850;

const unsigned long int led_lit_limit = 85;  // should be JIFFIES_CONSTANT/10

char flags = 0;  // clear all flags

// sense switch: 1=flash PC5 LED on writes, 0=quiet
const int SS_LED_ENABLE =	(1<<0);

// sense switch: 1=allow display on PORTD, 0=quiet
const int SS_DISPLAY_ENABLE =	(1<<1);

// sense switch: 1=write enabled, 0=write disabled
const int SS_WRITE_ENABLE =	(1<<2);

unsigned long int loop_counter;

uint8_t record_number;

unsigned short int PC = 0x000;	// this is the EEPROM address pointer

uint8_t SAMPLE_INTERVAL; /* How often to record data:
				0 = 1 per second
				1 = 1 per minute
				2 = 1 every 5 minutes
				3 = 1 per hour		*/

uint8_t DISPLAY_SELECTION; /* What to display on PORTD LEDs:
				0 = record number
				1 = thermistor
				2 = photocell
				3 = magnetic		*/

struct {
	uint8_t thermistor;
	uint8_t photocell;
	uint8_t magnetic;
} sensor;

/* FUNCTION PROTOTYPES */
void delay_ms(unsigned short);
void eeprom_write_byte(unsigned char, unsigned int);
void init(void);
void read_sense_switches(void);
void acquire_data(void);
void display_data(uint8_t);
void write_data(void);

/* FUNCTIONS */
void delay_ms(unsigned short ms)
// delay for a minimum of <ms>
// with a 1Mhz clock, the resolution is 1 ms
{
        uint8_t i,j;
        while (ms) {
                i = 40;  // 40 for 400 kHz clock, 100 for 1 MHz, etc
                while (i) {
                        i--;
                        j = 70;
                        while (j) {
                                j--;
                        }
                }
                ms--;
        }
}

void eeprom_write_byte(unsigned char data_byte, unsigned int eepromAddr)
// Write a byte of data to eeprom at eepromAddr
{
        while (EECR & (1<<EEWE))  // wait for completion of last write
                ;
        EEAR = eepromAddr;      // Setup address
        EEDR = data_byte;       // and data registers
        EECR |= (1<<EEMWE);     // Write logical 1 to master write enable
        EECR |= (1<<EEWE);      // start EEPROM write
}

void init()  // init routine run once only at start of main()
{
	delay_ms(500);	// let's just wait half a sec to make sure we are ON

	PORTB = (1<<PB2) | (1<<PB1) | (1<<PB0);  // enable PB0..2 as inputs
	DDRB = 0x00;
	PORTC = (1<<PC4) | (1<<PC3);  // enable PC3..4 as inputs
	DDRC = 0x00;
	DDRC |= _BV(PC5);	// enable PC5 as output
	PORTC |= _BV(PC5);	// Set PC5 output to 5V, LED off (active low)
	DDRD = 0xFF;	// enable port D
	PORTD = 0xFF;	// set all bits to one = all LEDs off (active low)
	ADCSR = 0xC2;   /* 11000010, left to right: ADC Enable,
                           Start Conversion, Single Conversion Mode,
                           write zero to ADC Int Flag, disable int,
                           prescaler: 010 for XTAL/4            */
	ADMUX = (1<<REFS0) | (1<<ADLAR); // ADLAR = JUSTIFY
	ADMUX &= ~_BV(MUX3);	// This bit always zero; see acquire_data
/*  ZERO of record_number below is candidate for removal.
	record_number = 0;	// zero record number
*/
	eeprom_write_byte(0x0a, PC++);	// 0A = program identifier
	eeprom_write_byte(0x1a, PC++);	// 1A = data format identifier
}  // PC = 0x002 on exit

void read_sense_switches()
// read jumper settings and store in flags structure
{
	flags |= SS_LED_ENABLE;		// LED flash always enabled for now
	flags |= SS_DISPLAY_ENABLE;	// Display always enabled for now

// DISPLAY_SELECTION:
//	0x00 = display record_number
//	0x01 = display thermistor data
//	0x02 = display photocell data
//	0x03 = display magnetic data
//
//	PINB0 = LSB
//	PINB1 = MSB

	if ((PINB & _BV(PINB1)) == 0)  // if this pin is LO then jumper IS set
		DISPLAY_SELECTION = 2;
	else
		DISPLAY_SELECTION = 0;
	if ((PINB & _BV(PINB0)) == 0)  // if this pin is LO then jumper IS set
		DISPLAY_SELECTION++;

// SAMPLE_INTERVAL:
//	0x00 = write EEPROM once per second
//	0x01 = write EEPROM once per minute
//	0x02 = write EEPROM once every five minutes
//	0x03 = write EEPROM once per hour
//
//	PINB2 = LSB
//	PINC3 = MSB

	if ((PINC & _BV(PINC3)) == 0)  // if this pin is LO then jumper IS set
		SAMPLE_INTERVAL = 2;
	else
		SAMPLE_INTERVAL = 0;
	if ((PINB & _BV(PINB2)) == 0)
		SAMPLE_INTERVAL++;

// SS_WRITE_ENABLE:
//	0x00 = write disabled
//	0x01 = write enabled
//
//	PINC4 = this bit ... AND, as with all, JUMPER IN takes pin LOW

	if ((PINC & _BV(PINC4)) == 0)	// pin LOW means JUMPER is IN, so:
		flags |= SS_WRITE_ENABLE;  // set SS_WRITE_ENABLE bit
	else
		flags &= ~SS_WRITE_ENABLE; // JUMPER OUT, clear SS_WRITE_ENABLE
}

void acquire_data()
// digitize sensor data and store in sensor structure
//	ADC0 = magnetic (Hall effect device, expected ouput 0.5-4.5V, AREF = Vcc
//	ADC1 = thermistor, expected output 0-2.5V, AREF = 2.56V
//	ADC2 = photocell, expected output 0-2.5V, AREF = 2.56V
{
	// Let's do ADC0 (magnetic sensor) first:
	ADMUX &= ~_BV(MUX0);// Next three lines sets MUX to ADC0.  Already set
	ADMUX &= ~_BV(MUX1);	// in init() are LEFT JUSTIFY, VREF=Vcc & REFS0
	ADMUX &= ~_BV(MUX2);

	while (ADCSR & (1<<ADSC))	// wait for last conversion to complete
		;

	ADCSR |= (1<<ADSC);	// start conversion (throw last one away)
	while (ADCSR & (1<<ADSC))	// wait for it to finish
		;
	sensor.magnetic = ADCH;  // get high 8 bits of magnetic data

	// Now let's do ADC2 (photocell):
	ADMUX |= _BV(MUX1);	// MUX bits now 0010 = ADC2
	ADCSR |= (1<<ADSC);	// start conversion, another keeper
	while (ADCSR & (1<<ADSC))	//wait for it to finish
		;
	sensor.photocell = ADCH;  // get high 8 bits of photocell data

	// Now let's do ADC1 (thermistor):
	ADMUX |= _BV(REFS1);	// set 2.56V AREF, REFS0 already set in init()
	ADMUX &= ~_BV(MUX1);
	ADMUX |= _BV(MUX0);	// MUX bits now 001 = ADC1

	ADCSR |= (1<<ADSC);	// start conversion (will throw this one away)
	while (ADCSR & (1<<ADSC))	// wait for it to finish
		;

	ADCSR |= (1<<ADSC);	// start a new conversion (this one's a keeper)
	while (ADCSR & (1<<ADSC))	//wait for it to finish
		;
	sensor.thermistor = ADCH;  // get high 8 bits of thermistor data

	// Now let's set up Vcc AREF and start a conversion to throw away on
	// next time through here
	ADMUX &= ~_BV(REFS1);	// clear REFS1, REFS0 still set, so AREF = Vcc
	ADCSR |= (1<<ADSC);	// start a conversion to throw away on re-entry
}

void display_data(uint8_t selection)
// Display data selected by sense switches if display is enabled and
// turn off PC5 LED if LED lit time is expired -- intent is to turn on
// the LED at write, then off after about 1/10 second or so while
// PORTD LED updates continue to occur even during the 1/10 second
{
	if ((flags & SS_LED_ENABLE) != 0) {		// if LED is enabled and
		if (loop_counter > led_lit_limit)	// lit limit exceeded
			PORTC |= _BV(PC5);		// then turn LED off
	}
	if ((flags & SS_DISPLAY_ENABLE) !=0) {	// if DISPLAY is enabled
		// invert bits and display data on Port D LEDs
		// (must be inverted 'cause LEDs are active low)
		switch (selection) {
			case 0:
				PORTD = ~record_number;
				break;
			case 1:
				PORTD = ~sensor.thermistor;
				break;
			case 2:
				PORTD = ~sensor.photocell;
				break;
			case 3:
				PORTD = ~sensor.magnetic;
				break;
		}
	}
}

void write_data()
// Write data in sensor structure to EEPROM at eepromAddr
// Light PC5 LED if enabled through sense switches (SS_LED_ENABLE)
{
	if ((flags & SS_LED_ENABLE) != 0)	// if LED is enabled
		PORTC &= ~_BV(PC5);		// then turn it ON! (active low)
	eeprom_write_byte(sensor.thermistor, PC++);
	eeprom_write_byte(sensor.photocell, PC++);
	eeprom_write_byte(sensor.magnetic, PC++);
}

int main(void)
{
	init(); // initialization routine to be run once only
	unsigned long int loop_limit = JIFFIES_CONSTANT; // for starters
	uint8_t record_limit = 170;  // 170 records = 2 bytes + (170 *3)
					// first byte is program number
					// second byte is record type
					// record type describes data structure
					// of 170 records of 3 bytes each

	while (1) {  // THIS IS THE MAIN LOOP
		loop_counter = 0;
		while (loop_counter < loop_limit) {
			read_sense_switches();
			switch (SAMPLE_INTERVAL) {
				case 0:		// write ONCE PER SECOND
					loop_limit = JIFFIES_CONSTANT;
					break;
				case 1:		// write ONCE PER MINUTE
					loop_limit = JIFFIES_CONSTANT * 60;
					break;
				case 2:		// write ONCE PER FIVE MINUTES
					loop_limit = JIFFIES_CONSTANT * 300;
					break;
				case 3:		// write ONCE PER HOUR
					loop_limit = JIFFIES_CONSTANT * 3600;
					break;
			}
			acquire_data();
			display_data(DISPLAY_SELECTION);
			loop_counter++;
		}

		// loop_counter has exceeded loop_limit, time to write data
		// BUT, write EEPROM only if record limit not exceeded.
		// (will continue to loop and display even if EEPROM is full)

		if (record_number < record_limit) {
			if ((flags & SS_WRITE_ENABLE) !=0) {
				write_data();
				record_number++;
			}
		}
	}  // close of main loop -- will loop here forever, always displaying
	   // data, and writing to EEPROM only if WRITE_ENABLE is set and
	   // record_limit is not exceeded
}

Re: [9fans] Writing device drivers

[David Leimbach]

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

Re: [9fans] Writing device drivers

[jmk]

Brantley's comments are pretty much on the mark.
However, I'd try something simpler than the WPN311
to start with. I think it uses the Atheros 5212
chip and I looked at writing a driver for that a
few weeks ago and decided it was probably more man
years than I had available. On the other hand, we
need to be able to use some newer wireless hardware
than the old Wavelan 802.11b chips. If you have
access to a system with an Intel Centrino wireless
chip there is a partial driver available which
needs someone to finish and debug. That's if you
are set on doing wireless; otherwise there are
many simpler projects you could usefully do and
I'm sure the list could suggest some if you were
interested in alternatives. In any case, be assured
we welcome your enthusiasm and are happy to help
with any questions you may have.

--jim

Re: [9fans] Writing device drivers

[Eric Smith]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

Hi,

On 4/14/06, jmk@plan9.bell-labs.com <jmk@plan9.bell-labs.com> wrote:
>
> ... otherwise there are
> many simpler projects you could usefully do and
> I'm sure the list could suggest some if you were
> interested in alternatives.


This is a real good idea.  Thank you to everyone for all the good advice and
info both on and off the list, but the more I look at it the more I realize
I'm over my head with that.

But I would very much like to contribute, anything.  Yes, if someone on the
list would please make a suggestion I'd like to get started.  Perhaps I
should start with something almost trivial (if you have anything like that
available to do), and go from there.

Thank you very much,
Eric

[-- Attachment #2: Type: text/html, Size: 1085 bytes --]

Re: [9fans] Writing device drivers

[Anthony Sorace]

the wiki has a todo page
(http://cm.bell-labs.com/wiki/plan9/TODO/index.html) with some
proposed and ongoing projects. it's regularly out-of-date.

personally, i'd love firewire/ieee1394 support, although that's mostly
because i've got a small stack of such disks available to me, mostly
sitting idle. i believe someone (peter bosch?) was working on this a
few years ago.

for getting familiar with the plan 9 interfaces and such, you can get
started by just writing a driver that does something simple,
software-only. i found that quite educational getting started. go
write /dev/rot13 or something. for something trivial with real
hardware... has anyone ever bothered to write a driver for the PC
speaker? that should be fairly easy (but then, it is a PC, so i
wouldn't be shocked if not).

Re: [9fans] Writing device drivers

[Paweł Lasek]

On 4/15/06, Anthony Sorace <anothy@gmail.com> wrote:

> personally, i'd love firewire/ieee1394 support, although that's mostly
> because i've got a small stack of such disks available to me, mostly
> sitting idle. i believe someone (peter bosch?) was working on this a
> few years ago.

I agree - firewire bus/device class drivers + at least ohci1394 would
be a great thing...

> for getting familiar with the plan 9 interfaces and such, you can get
> started by just writing a driver that does something simple,
> software-only. i found that quite educational getting started. go
> write /dev/rot13 or something. for something trivial with real
> hardware... has anyone ever bothered to write a driver for the PC
> speaker? that should be fairly easy (but then, it is a PC, so i
> wouldn't be shocked if not).
>

For a little project - why not create kernel mode port of linux coffee
machine driver? (somewhere in the HOWTOs :D)


Not so long ago I tried to plunge through SCSI code to make Plan9 work
on my machine without Xen&co, but I decided to withdraw when I found
I'd have to write a compiler for firmware (and possibly rewrite
BSD/Linux firmware) in addition to driver itself... (Adaptec AIC-7892
- UltraWide2...)
--
Paul Lasek

Re: [9fans] Writing device drivers

[erik quanstrom]

am i missing something?  is this a poor piece of hardware?

- erik

On Tue Apr 18 10:43:14 CDT 2006, jmk@plan9.bell-labs.com wrote:
> 	>What is a dac960?
>
> it's a raid controller formerly made by mylex and now made by lsilogic.
> it might even originally be made by american megatrends, i'm not sure.
> i found one recently and threw it in the pile of cards i'll never have
> a driver for (nor see the need to ever write a driver for).

Re: [9fans] Writing device drivers

[jmk]

i have no idea if it's a poor piece of hardware or not, i just
can't see me ever wanting to use one.

On Tue Apr 18 23:12:50 EDT 2006, quanstro@quanstro.net wrote:
> am i missing something?  is this a poor piece of hardware?
>
> - erik
>
> On Tue Apr 18 10:43:14 CDT 2006, jmk@plan9.bell-labs.com wrote:
> > 	>What is a dac960?
> >
> > it's a raid controller formerly made by mylex and now made by lsilogic.
> > it might even originally be made by american megatrends, i'm not sure.
> > i found one recently and threw it in the pile of cards i'll never have
> > a driver for (nor see the need to ever write a driver for).

Re: [9fans] Writing device drivers

[lucio]

> i have no idea if it's a poor piece of hardware or not, i just
> can't see me ever wanting to use one.

I think I have a largely unused, but supported one in a NetBSD 2.1 box
(with a single drive, it's all I could spare).  It's not impressive
and a trifle erratic, but then that may be the mother board, I get odd
effects from the MegaTrends as well as from the Adaptec in it.

++L

Re: [9fans] Writing device drivers

[Nigel Roles]

jmk@plan9.bell-labs.com wrote:

>i have no idea if it's a poor piece of hardware or not, i just
>can't see me ever wanting to use one.
>
>On Tue Apr 18 23:12:50 EDT 2006, quanstro@quanstro.net wrote:
>
>
>>am i missing something?  is this a poor piece of hardware?
>>
>>
>>
RAID controllers (especially real ones which handle RAID 5 entirely
onboard) tend to end up in a different bracket to host adaptors. Because
they need to convert a single operation into a sequence of reads and
writes to maintain the array, there is a need for substantially more
computing power on board, and people will pay for this. As a result,
they tend to look like the Adaptec card did in the early days with a
fixed mailbox SCB API, but with a fast CPU (I960s are very popular)
running a lot of firmware. The BIOS is used to configure groups of
physical drives into logical drives, and the firmware presents those
logical drives to the OS driver.

Thus there is only one interface to write a driver to, you dont have to
choose the firmware/driver split yourself, the firmware takes care of
the scsi bus so you only need to understand SCSI protocol and not the
physical layer as well, and the programming interface is often quite
straightforward.

In short, assuming you have some documentation (or if really desperate a
Linux driver to look at), then writing a driver for a RAID controller
could well be a lot easier. The trickiest part is often that the BIOS is
not 'fully featured' as regards volume managment (or the machine is
remote and so the console is inaccessible), and you really need to use a
managment API from the host OS to do array management. This API is
rarely documented in detail; instead in the Lunix world thet have in
some cases resorted to finding ways to run the manufacturers DOS binary.

Nigel

Re: [9fans] Writing device drivers

[quanstro]

i didn't know if there was something i didn't know.

about five years ago i built a pretty large (for the day) oracle database (2TB) with a quad
processor va linux box (running linux, oddly enough) and three three-channel
dac960 raid cards.  each channel was connected to a simple raid cabnet with 8 36G
drives in a raid-5 setup.  the whole thing at the time was about $125k and it ran
circles around the ibm big iron it replaced.  we had no problem keeping the load above
0.5per processor and the disk io limited by pci bandwidth.

the only problem we had was when the development server took several power cycles
and a nearby lightning strike.  although the system was on a ups, i had to manually
remind each card about it's attached arrays.  but we didn't loose a byte.

today, i think one could get a lot more bang/buck with (s)ata drives and lvm2 striping/raid 5.
then again, much of the data was documents stored by md5 score.  it would have been great
to have fossil back then.

- erik

On Tue Apr 18 23:03:07 CDT 2006, jmk@plan9.bell-labs.com wrote:
> i have no idea if it's a poor piece of hardware or not, i just
> can't see me ever wanting to use one.
>
> On Tue Apr 18 23:12:50 EDT 2006, quanstro@quanstro.net wrote:
> > am i missing something?  is this a poor piece of hardware?
> >
> > - erik
> >
> > On Tue Apr 18 10:43:14 CDT 2006, jmk@plan9.bell-labs.com wrote:
> > > 	>What is a dac960?
> > >
> > > it's a raid controller formerly made by mylex and now made by lsilogic.
> > > it might even originally be made by american megatrends, i'm not sure.
> > > i found one recently and threw it in the pile of cards i'll never have
> > > a driver for (nor see the need to ever write a driver for).

Re: [9fans] Writing device drivers

[erik quanstrom]

it looks like all the code for aic-7xxx is in the linux kernel tree,
including an assembler.

does anybody know what processor it uses?

- erik

On Sun Apr 16 19:24:05 CDT 2006, rsc@swtch.com wrote:
> > why can't the firmware be compiled on linux or
> > windows or something and treated as binary goo?
>
> depends on how much it interacts with the driver.
> the wireless ones come with a giant mess of goop
> that you're not allowed to touch or even know what
> it means.  but then the ncr scsi drivers have a nice
> simple microcode that is tightly integrated with the
> actual driver.  see the plan 9 and linux drivers, for example.
> nigel wrote an assembler for it and it's *far* better
> than the hand-assembly that the linux driver writers
> resorted to.
>
> russ
>

Re: [9fans] Writing device drivers

[Russ Cox]

> it looks like all the code for aic-7xxx is in the linux kernel tree,
> including an assembler.
>
> does anybody know what processor it uses?

it probably doesn't matter.  it's unlikely that the
microcode is written in a real processor's assembly
language.  usually it is a virtual processor defined
by the card.

RE: [9fans] Writing device drivers

[Nigel Roles]

9fans-bounces+ngr=9fs.org@cse.psu.edu wrote:
>> it looks like all the code for aic-7xxx is in the linux kernel tree,
>> including an assembler.
>>
>> does anybody know what processor it uses?
>
> it probably doesn't matter.  it's unlikely that the
> microcode is written in a real processor's assembly
> language.  usually it is a virtual processor defined
> by the card.

Originally Adaptec has an on-board 8035 which presented a mailbox (aka scb
(aka Scsi Command Block)) interface to the host. You load up the command
block, enable it, and wait for an interrupt. The firmware was fixed in an
EPROM next door. This conforms to Russ'es idea that it is a virtual
processor.

Later, the firmware became downloadable to local ram in a cpu which
implemented the scbs directly, plus enough flow control to allow the
controller to manage many concurrent transfers without host intervention.
So, the aic-7xxx series are real processors (at least a real as they ever
get given that Intel processors still have microcode engines are therefore
in some senses virtual).

The story for the NCR/Symbios/LSI Logic controllers is similar; at first
they were hard-wired and the CPU did all the sequencing, then a SCSI
specific CPU was added (silicon designers would call it a programmable
sequencer) which read its instructions over the bus and gave it more offload
capability. Finally, the firmware got stored in local RAM because it ran too
slowly when competeing with the data transfers over the same bus.

SCSI processors are highly specialised, being excellent at DMA and able to
guarantee the tight bus timings, but struggling to add two numbers together.
They are a nightmare to debug because debugging usually results in the SCSI
bus timing being violated and the targets take their bats home. None of the
current cards will use general purpose processors.

It may well be practical to borrow the Linux aic firmware, but the result
will be ugly as the match between a Linux scsi driver and a Plan 9 scsi
driver is not strong. It's the usual argument I see around here; compare the
Symbios driver in Linux with that in Plan 9. If you want 90% of the
functionality for 10% of the code, learn the firmware assembler and do
something that fits the scale of Plan 9. If you just want a aic driver in
the shortest possible time, then using known good firmware will no doubt
help.

I did make a start on an aic driver with the intention of doing Plan 9
specific firmware. I ported the Linux assembler but the effort is lost in
the mists of time. It turned out that after doing the Symbios driver, I
really couldn't be arsed to fight a firmware processor again. You really
have to understand SCSI at the bus level, and to be honest having a bus
analyser to hand would be a good idea.

RE: [9fans] Writing device drivers

[erik quanstrom]

thanks for the excellent information.  i have the fortune of having a
dac960 controller and an adaptec 7898n in the same machine.  lucky me.

a quick look at the dac960 driver for linux doesn't immediately reveal
any firmware.  do you think that would be an easier driver to build than
the adaptec?

i don't know a think about scsi bus protocol and i don't have a bus analyzer.
is such a beast affordable?  (i am running old va linux boxen after all.)

- erik

"Nigel Roles" <nigel@9fs.org> writes

|
| 9fans-bounces+ngr=9fs.org@cse.psu.edu wrote:
| >> it looks like all the code for aic-7xxx is in the linux kernel tree,
| >> including an assembler.
| >>
| >> does anybody know what processor it uses?
| >
| > it probably doesn't matter.  it's unlikely that the
| > microcode is written in a real processor's assembly
| > language.  usually it is a virtual processor defined
| > by the card.
|
| Originally Adaptec has an on-board 8035 which presented a mailbox (aka scb
| (aka Scsi Command Block)) interface to the host. You load up the command
| block, enable it, and wait for an interrupt. The firmware was fixed in an
| EPROM next door. This conforms to Russ'es idea that it is a virtual
| processor.
[etc]

Re: [9fans] Writing device drivers

[Nigel Roles]

erik quanstrom wrote:

>thanks for the excellent information.  i have the fortune of having a
>dac960 controller and an adaptec 7898n in the same machine.  lucky me.
>
>a quick look at the dac960 driver for linux doesn't immediately reveal
>any firmware.  do you think that would be an easier driver to build than
>the adaptec?
>
>
>
Could be. What is a dac960? If you did an Adaptec aic driver you'd be
much more popular, but there are so many variants you might regret it!

>i don't know a think about scsi bus protocol and i don't have a bus analyzer.
>is such a beast affordable?  (i am running old va linux boxen after all.)
>
>
>
I very much doubt it it would be affordable. Think several 1000 $.

Re: [9fans] Writing device drivers

[jmk]

	>What is a dac960?

it's a raid controller formerly made by mylex and now made by lsilogic.
it might even originally be made by american megatrends, i'm not sure.
i found one recently and threw it in the pile of cards i'll never have
a driver for (nor see the need to ever write a driver for).

Re: [9fans] Writing device drivers

[Moritz Kiese]

On Tue, 18 Apr 2006, Nigel Roles wrote:

> erik quanstrom wrote:

[snip]

>> i don't know a think about scsi bus protocol and i don't have a bus
>> analyzer.
>> is such a beast affordable?  (i am running old va linux boxen after all.)
>>
>>
> I very much doubt it it would be affordable. Think several 1000 $.

Nah. Ebay spills them out once in a while, e.g.
 	http://cgi.ebay.com/Verisys-SV8160-SCSI-Bus-Analyzer_W0QQitemZ7609713441QQcategoryZ97186QQssPageNameZWDVWQQrdZ1QQcmdZViewItem

But then I have never used this particular beast so I can't comment on
usefulness /quality of the related analyser SW...

++mbk

Re: [9fans] Writing device drivers

[Nigel Roles]

> Nah. Ebay spills them out once in a while, e.g.
>     http://cgi.ebay.com/Verisys-SV8160-SCSI-Bus-Analyzer_W0QQitemZ7609713441QQcategoryZ97186QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
>
>
> But then I have never used this particular beast so I can't comment on
> usefulness /quality of the related analyser SW...
>
> ++mbk
>
Not bad.

eBay didn't really exist when I wrote the Symbios driver.

Nigel

Re: [9fans] Writing device drivers

[Paweł Lasek]

On 4/18/06, erik quanstrom <quanstro@quanstro.net> wrote:
> thanks for the excellent information.  i have the fortune of having a
> dac960 controller and an adaptec 7898n in the same machine.  lucky me.

> a quick look at the dac960 driver for linux doesn't immediately reveal
> any firmware.  do you think that would be an easier driver to build than
> the adaptec?

IIRC dac960 has completely OS-independent firmware and communicates
using some kind of protocol? with host os - it is only a storage
controller with SCSI pass-thru for SCSI Tape. It's not what you'd call
a SCSI HBA :)

I wouldn't be surprised if dac960 isn't somehow similar to DPT EATA
standard, where you didn't give a damn about integrated firmware (DPT
Smart* IV controllers used m68k cpu's connected with specialised SCSI
co-processor and PCI bus adapter - It's firmware was completely
independent (most powerful models had complete 68060 :D)

> i don't know a think about scsi bus protocol and i don't have a bus analyzer.
> is such a beast affordable?  (i am running old va linux boxen after all.)

I don't think it's necessary to have a bus analyzer.... just read SCSI
documentation and available source code from *BSD and Linux...

> - erik


--
Paul Lasek

Re: [9fans] Writing device drivers

[erik quanstrom]

i'm missing part of this.

why can't the firmware be compiled on linux or
windows or something and treated as binary goo?

- erik

On Sun Apr 16 18:01:22 CDT 2006, pawel.lasek@gmail.com wrote:
>
> Not so long ago I tried to plunge through SCSI code to make Plan9 work
> on my machine without Xen&co, but I decided to withdraw when I found
> I'd have to write a compiler for firmware (and possibly rewrite
> BSD/Linux firmware) in addition to driver itself... (Adaptec AIC-7892
> - UltraWide2...)
> --
> Paul Lasek

Re: [9fans] Writing device drivers

[Russ Cox]

> why can't the firmware be compiled on linux or
> windows or something and treated as binary goo?

depends on how much it interacts with the driver.
the wireless ones come with a giant mess of goop
that you're not allowed to touch or even know what
it means.  but then the ncr scsi drivers have a nice
simple microcode that is tightly integrated with the
actual driver.  see the plan 9 and linux drivers, for example.
nigel wrote an assembler for it and it's *far* better
than the hand-assembly that the linux driver writers
resorted to.

russ

Re: [9fans] Writing device drivers

[erik quanstrom]

eh?  how would that be like emacs?  apl, fortran, pl/1,
ada, pascal and .el files can all be compiled.  that doesn't make
ada and fortran that similar.

for that matter, rc compiles stuff then executes it.  it
just doesn't ever output it's bytecode.

also, pretty much every concept in computer science can
be found in emacs.  just not brevity.

- erik

On Sat Apr 15 18:56:13 CDT 2006, 9nut@9netics.com wrote:
> > think rc split into a compiler and an execution unit.
>
> like emacs.
>
> ;)
>

Re: [9fans] Writing device drivers

[Anthony Sorace]

or elegance, or taste, or... the list goes on.

i think they're planned for a future release.

Re: [9fans] Writing device drivers

[Bruce Ellis]

I'd rather the opinion of someone who can install a SCSI
drive on a SUN in under four months.  i gave up and went
up stairs.  i could have done it before lunch.  but that
wasn't my job.

brucee

On 4/16/06, Anthony Sorace <anothy@gmail.com> wrote:
> or elegance, or taste, or... the list goes on.
>
> i think they're planned for a future release.

Re: [9fans] Writing device drivers

[erik quanstrom]

i didn't see it at all.
and haven't looked at fgb's port of mozilla's js yet.

what i was thinking of is probablly a little different.
i was thinking of writing a javascript to bytecode compiler --
think rc split into a compiler and an execution unit.
most likely it was just another in a long list of hairbrained ideas.

- erik

On Sat Apr 15 18:19:22 CDT 2006, 9nut@9netics.com wrote:
> i was going to suggest it and was looking for
> what i thought i saw.  after a couple of searches
> i figured i must have imagined it.
>
[etc]
> > I don't know if this is what you're talking about, but
> > you might take a look at /n/sources/contrib/fgb/js.tgz
> > is a native (not ape) port of mozilla's js engine:
> > http://www.mozilla.org/js/spidermonkey/
> >
> >

Re: [9fans] Writing device drivers

[Skip Tavakkolian]

> think rc split into a compiler and an execution unit.

like emacs.

;)

Re: [9fans] Writing device drivers

[erik quanstrom]

this isn't a list of neat little projects.
most of these are very time consuming and/or difficult.
(allowing win to set the scratch flag notwithstanding.)

one project not on the list i've been talking a look at is
javascript.  but holy phd-dissertations, batman.  implementing
js looks to be about as much code as cc+libc.  it's astonishing
that it was implemented to be simple and easy for non-professionals.

then there's the fact that the language is as goofy as it gets.
here's an example from the ecma-262 documentation, page 87:

	[these] produce the same result:

		new Function("a", "b", "c", "return a+b+c")
		new Function("a, b, c", "return a+b+c")
		new Function("a, b", "c", "return a+b+c")

they also go on for a page and a half on the special rules
for free ';'s.

- erik

On Sat Apr 15 09:17:19DT 2006, anothy@gmail.com wrote:
> the wiki has a todo page
> (http://cm.bell-labs.com/wiki/plan9/TODO/index.html) with some
> proposed and ongoing projects. it's regularly out-of-date.

Re: [9fans] Writing device drivers

[Federico Benavento]

I don't know if this is what you're talking about, but
you might take a look at /n/sources/contrib/fgb/js.tgz
is a native (not ape) port of mozilla's js engine:
http://www.mozilla.org/js/spidermonkey/


On 4/15/06, erik quanstrom <quanstro@quanstro.net> wrote:
> this isn't a list of neat little projects.
> most of these are very time consuming and/or difficult.
> (allowing win to set the scratch flag notwithstanding.)
>
> one project not on the list i've been talking a look at is
> javascript.  but holy phd-dissertations, batman.  implementing
> js looks to be about as much code as cc+libc.  it's astonishing
> that it was implemented to be simple and easy for non-professionals.
>
> then there's the fact that the language is as goofy as it gets.
> here's an example from the ecma-262 documentation, page 87:
>
>         [these] produce the same result:
>
>                 new Function("a", "b", "c", "return a+b+c")
>                 new Function("a, b, c", "return a+b+c")
>                 new Function("a, b", "c", "return a+b+c")
>
> they also go on for a page and a half on the special rules
> for free ';'s.
>
> - erik
>
> On Sat Apr 15 09:17:19DT 2006, anothy@gmail.com wrote:
> > the wiki has a todo page
> > (http://cm.bell-labs.com/wiki/plan9/TODO/index.html) with some
> > proposed and ongoing projects. it's regularly out-of-date.
>


--
Federico G. Benavento

Re: [9fans] Writing device drivers

[Skip Tavakkolian]

i was going to suggest it and was looking for
what i thought i saw.  after a couple of searches
i figured i must have imagined it.

cpu% grep -i javascript /n/sources/contrib/*/INDEX
cpu% grep -i ecmascript /n/sources/contrib/*/INDEX
cpu% grep -i script /n/sources/contrib/*/INDEX
/n/sources/contrib/fst/INDEX:piggy.rc: A script for generating html picture galleries.
/n/sources/contrib/geoff/INDEX:ifup: script for configuring additional network interfaces.
/n/sources/contrib/mjl/INDEX:readme: details such as usage of the scripts
/n/sources/contrib/rsc/INDEX:rlogin: rlogin in shell script
/n/sources/contrib/rsc/INDEX:scripts: various scripts for /usr/$you/bin/rc
/n/sources/contrib/rsc/INDEX:talk: scripts to generate talk slides
/n/sources/contrib/steve/INDEX:rc: various rc(1) scripts, some less useful that others, see rc/Index for details

all due to a missing 't' in the description.  there's also
inferno/charon's ecmascript.

> I don't know if this is what you're talking about, but
> you might take a look at /n/sources/contrib/fgb/js.tgz
> is a native (not ape) port of mozilla's js engine:
> http://www.mozilla.org/js/spidermonkey/
>
>
> On 4/15/06, erik quanstrom <quanstro@quanstro.net> wrote:
>> this isn't a list of neat little projects.
>> most of these are very time consuming and/or difficult.
>> (allowing win to set the scratch flag notwithstanding.)
>>
>> one project not on the list i've been talking a look at is
>> javascript.  but holy phd-dissertations, batman.  implementing
>> js looks to be about as much code as cc+libc.  it's astonishing
>> that it was implemented to be simple and easy for non-professionals.
>>
>> then there's the fact that the language is as goofy as it gets.
>> here's an example from the ecma-262 documentation, page 87:
>>
>>         [these] produce the same result:
>>
>>                 new Function("a", "b", "c", "return a+b+c")
>>                 new Function("a, b, c", "return a+b+c")
>>                 new Function("a, b", "c", "return a+b+c")
>>
>> they also go on for a page and a half on the special rules
>> for free ';'s.
>>
>> - erik
>>
>> On Sat Apr 15 09:17:19DT 2006, anothy@gmail.com wrote:
>> > the wiki has a todo page
>> > (http://cm.bell-labs.com/wiki/plan9/TODO/index.html) with some
>> > proposed and ongoing projects. it's regularly out-of-date.
>>
>
>
> --
> Federico G. Benavento

Re: [9fans] Writing device drivers

[Federico G. Benavento]

> all due to a missing 't' in the description.

fixed, thanks

Re: [9fans] Writing device drivers

[Charles Forsyth]

>i was thinking of writing a javascript to bytecode compiler --
>think rc split into a compiler and an execution unit.

that's what charon's does, and surely the others don't do otherwise?
but that emphasises the real problem: ecmascript+java/jscript extensions is the tiniest part
of the least of your worries when implementing `javascript'.
it's similar to compiling C to Dis: in many ways that's not too hard
but it's what people expect that will then do that creates the consternation.

Re: [9fans] Writing device drivers

[Bruce Ellis]

indeed - translating clean C to dis is not hard - i had a discussion
with dennis about this many years ago.  but, as i think charles was
implying, you would get the "why doesn't X11 compile" etc.
because they are full of egregious hacks and non portable code
clouded in ifdefs.

brucee

On 4/17/06, Charles Forsyth <forsyth@terzarima.net> wrote:
> >i was thinking of writing a javascript to bytecode compiler --
> >think rc split into a compiler and an execution unit.
>
> that's what charon's does, and surely the others don't do otherwise?
> but that emphasises the real problem: ecmascript+java/jscript extensions is the tiniest part
> of the least of your worries when implementing `javascript'.
> it's similar to compiling C to Dis: in many ways that's not too hard
> but it's what people expect that will then do that creates the consternation.
>

Re: [9fans] Writing device drivers

[Charles Forsyth]

>but, as i think charles was implying [about compiling c to
>dis], you would get the "why doesn't X11 compile" etc.

yes, and that even having got that to compile, there is now
(even compared to 1996) a much bigger set of software that
is expected to work.

the relevance to `javascript' is that what the applications now
require is a rather big set of software that is expected to work

[9fans] Writing device drivers

[Eric Smith]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

Wanting to see a Netgear WPN311 (wireless PCI adapter) device driver I'm
considering writing one.  This may be the first and last you hear of this
effort - the last device driver I wrote was in 1979, and I used assembly for
that.  So you other WPN311 users out there -- don't hold your breath unless
you look good in blue.  My C skills are about a 3 on a 1-10 scale.

Tonight I'm looking at plan 9 sources of similar drivers to see how it's
done.  I'll probably be borrowing heavily from someone else's prior work.

Beyond this do you have any suggestions of good reading for an aspiring plan
9 device driver programmer?

Anything will help.

Thanks,
Eric

ps -- this plan 9 is good stuff, guys.  Good work.

[-- Attachment #2: Type: text/html, Size: 775 bytes --]