* Re: [9fans] Writing device drivers
@ 2006-04-15 15:26 erik quanstrom
2006-04-15 23:04 ` Federico Benavento
0 siblings, 1 reply; 35+ messages in thread
From: erik quanstrom @ 2006-04-15 15:26 UTC (permalink / raw)
To: 9fans
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-15 15:26 [9fans] Writing device drivers erik quanstrom @ 2006-04-15 23:04 ` Federico Benavento 2006-04-15 23:18 ` Skip Tavakkolian 0 siblings, 1 reply; 35+ messages in thread From: Federico Benavento @ 2006-04-15 23:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-15 23:04 ` Federico Benavento @ 2006-04-15 23:18 ` Skip Tavakkolian 2006-04-16 0:43 ` Federico G. Benavento 2006-04-16 18:03 ` Charles Forsyth 0 siblings, 2 replies; 35+ messages in thread From: Skip Tavakkolian @ 2006-04-15 23:18 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-15 23:18 ` Skip Tavakkolian @ 2006-04-16 0:43 ` Federico G. Benavento 2006-04-16 18:03 ` Charles Forsyth 1 sibling, 0 replies; 35+ messages in thread From: Federico G. Benavento @ 2006-04-16 0:43 UTC (permalink / raw) To: 9fans > all due to a missing 't' in the description. fixed, thanks ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-15 23:18 ` Skip Tavakkolian 2006-04-16 0:43 ` Federico G. Benavento @ 2006-04-16 18:03 ` Charles Forsyth 2006-04-16 18:14 ` Bruce Ellis 1 sibling, 1 reply; 35+ messages in thread From: Charles Forsyth @ 2006-04-16 18:03 UTC (permalink / raw) To: 9fans >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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-16 18:03 ` Charles Forsyth @ 2006-04-16 18:14 ` Bruce Ellis 2006-04-16 21:31 ` Charles Forsyth 0 siblings, 1 reply; 35+ messages in thread From: Bruce Ellis @ 2006-04-16 18:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-16 18:14 ` Bruce Ellis @ 2006-04-16 21:31 ` Charles Forsyth 0 siblings, 0 replies; 35+ messages in thread From: Charles Forsyth @ 2006-04-16 21:31 UTC (permalink / raw) To: 9fans >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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers
@ 2006-04-19 3:10 erik quanstrom
2006-04-19 4:02 ` jmk
0 siblings, 1 reply; 35+ messages in thread
From: erik quanstrom @ 2006-04-19 3:10 UTC (permalink / raw)
To: 9fans
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).
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-19 3:10 erik quanstrom @ 2006-04-19 4:02 ` jmk 2006-04-19 4:57 ` lucio ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: jmk @ 2006-04-19 4:02 UTC (permalink / raw) To: 9fans 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). ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-19 4:02 ` jmk @ 2006-04-19 4:57 ` lucio 2006-04-19 6:59 ` Nigel Roles 2006-04-19 21:12 ` quanstro 2 siblings, 0 replies; 35+ messages in thread From: lucio @ 2006-04-19 4:57 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-19 4:02 ` jmk 2006-04-19 4:57 ` lucio @ 2006-04-19 6:59 ` Nigel Roles 2006-04-19 21:12 ` quanstro 2 siblings, 0 replies; 35+ messages in thread From: Nigel Roles @ 2006-04-19 6:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-19 4:02 ` jmk 2006-04-19 4:57 ` lucio 2006-04-19 6:59 ` Nigel Roles @ 2006-04-19 21:12 ` quanstro 2 siblings, 0 replies; 35+ messages in thread From: quanstro @ 2006-04-19 21:12 UTC (permalink / raw) To: 9fans 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). ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers
@ 2006-04-17 0:31 erik quanstrom
2006-04-17 1:44 ` Russ Cox
0 siblings, 1 reply; 35+ messages in thread
From: erik quanstrom @ 2006-04-17 0:31 UTC (permalink / raw)
To: 9fans
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
>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-17 0:31 erik quanstrom @ 2006-04-17 1:44 ` Russ Cox 2006-04-17 10:01 ` Nigel Roles 0 siblings, 1 reply; 35+ messages in thread From: Russ Cox @ 2006-04-17 1:44 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: [9fans] Writing device drivers 2006-04-17 1:44 ` Russ Cox @ 2006-04-17 10:01 ` Nigel Roles 2006-04-18 1:34 ` erik quanstrom 0 siblings, 1 reply; 35+ messages in thread From: Nigel Roles @ 2006-04-17 10:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: [9fans] Writing device drivers 2006-04-17 10:01 ` Nigel Roles @ 2006-04-18 1:34 ` erik quanstrom 2006-04-18 14:49 ` Nigel Roles 2006-04-18 19:15 ` Paweł Lasek 0 siblings, 2 replies; 35+ messages in thread From: erik quanstrom @ 2006-04-18 1:34 UTC (permalink / raw) To: 9fans, Nigel Roles 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] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-18 1:34 ` erik quanstrom @ 2006-04-18 14:49 ` Nigel Roles 2006-04-18 15:42 ` jmk 2006-04-18 15:59 ` Moritz Kiese 2006-04-18 19:15 ` Paweł Lasek 1 sibling, 2 replies; 35+ messages in thread From: Nigel Roles @ 2006-04-18 14:49 UTC (permalink / raw) To: erik quanstrom; +Cc: 9fans 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 $. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-18 14:49 ` Nigel Roles @ 2006-04-18 15:42 ` jmk 2006-04-18 15:59 ` Moritz Kiese 1 sibling, 0 replies; 35+ messages in thread From: jmk @ 2006-04-18 15:42 UTC (permalink / raw) To: 9fans >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). ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-18 14:49 ` Nigel Roles 2006-04-18 15:42 ` jmk @ 2006-04-18 15:59 ` Moritz Kiese 2006-04-18 16:03 ` Nigel Roles 1 sibling, 1 reply; 35+ messages in thread From: Moritz Kiese @ 2006-04-18 15:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-18 15:59 ` Moritz Kiese @ 2006-04-18 16:03 ` Nigel Roles 0 siblings, 0 replies; 35+ messages in thread From: Nigel Roles @ 2006-04-18 16:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-18 1:34 ` erik quanstrom 2006-04-18 14:49 ` Nigel Roles @ 2006-04-18 19:15 ` Paweł Lasek 1 sibling, 0 replies; 35+ messages in thread From: Paweł Lasek @ 2006-04-18 19:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers
@ 2006-04-17 0:11 erik quanstrom
2006-04-17 1:24 ` Russ Cox
0 siblings, 1 reply; 35+ messages in thread
From: erik quanstrom @ 2006-04-17 0:11 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-17 0:11 erik quanstrom @ 2006-04-17 1:24 ` Russ Cox 0 siblings, 0 replies; 35+ messages in thread From: Russ Cox @ 2006-04-17 1:24 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers
@ 2006-04-16 1:02 erik quanstrom
2006-04-16 2:36 ` Anthony Sorace
0 siblings, 1 reply; 35+ messages in thread
From: erik quanstrom @ 2006-04-16 1:02 UTC (permalink / raw)
To: 9fans
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.
>
> ;)
>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-16 1:02 erik quanstrom @ 2006-04-16 2:36 ` Anthony Sorace 2006-04-16 8:06 ` Bruce Ellis 0 siblings, 1 reply; 35+ messages in thread From: Anthony Sorace @ 2006-04-16 2:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs or elegance, or taste, or... the list goes on. i think they're planned for a future release. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-16 2:36 ` Anthony Sorace @ 2006-04-16 8:06 ` Bruce Ellis 0 siblings, 0 replies; 35+ messages in thread From: Bruce Ellis @ 2006-04-16 8:06 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers @ 2006-04-15 23:34 erik quanstrom 2006-04-15 23:55 ` Skip Tavakkolian 0 siblings, 1 reply; 35+ messages in thread From: erik quanstrom @ 2006-04-15 23:34 UTC (permalink / raw) To: 9fans 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/ > > > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-15 23:34 erik quanstrom @ 2006-04-15 23:55 ` Skip Tavakkolian 0 siblings, 0 replies; 35+ messages in thread From: Skip Tavakkolian @ 2006-04-15 23:55 UTC (permalink / raw) To: 9fans > think rc split into a compiler and an execution unit. like emacs. ;) ^ permalink raw reply [flat|nested] 35+ messages in thread
[parent not found: <8a5bd8ccbc2e53557663e2a9020fb26c@coraid.com>]
[parent not found: <820bc1260604140834v2a773ev90ff46b4e6b2427f@mail.gmail.com>]
* Re: [9fans] Writing device drivers [not found] ` <820bc1260604140834v2a773ev90ff46b4e6b2427f@mail.gmail.com> @ 2006-04-14 15:36 ` Eric Smith 2006-04-14 19:33 ` David Leimbach 2006-04-15 4:58 ` jmk 0 siblings, 2 replies; 35+ messages in thread From: Eric Smith @ 2006-04-14 15:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 } ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-14 15:36 ` Eric Smith @ 2006-04-14 19:33 ` David Leimbach 2006-04-15 4:58 ` jmk 1 sibling, 0 replies; 35+ messages in thread From: David Leimbach @ 2006-04-14 19:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 > > > > > > > > > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-14 15:36 ` Eric Smith 2006-04-14 19:33 ` David Leimbach @ 2006-04-15 4:58 ` jmk 2006-04-15 13:24 ` Eric Smith 1 sibling, 1 reply; 35+ messages in thread From: jmk @ 2006-04-15 4:58 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-15 4:58 ` jmk @ 2006-04-15 13:24 ` Eric Smith 2006-04-15 14:16 ` Anthony Sorace 0 siblings, 1 reply; 35+ messages in thread From: Eric Smith @ 2006-04-15 13:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-15 13:24 ` Eric Smith @ 2006-04-15 14:16 ` Anthony Sorace 2006-04-16 23:00 ` Paweł Lasek 0 siblings, 1 reply; 35+ messages in thread From: Anthony Sorace @ 2006-04-15 14:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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). ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9fans] Writing device drivers 2006-04-15 14:16 ` Anthony Sorace @ 2006-04-16 23:00 ` Paweł Lasek 0 siblings, 0 replies; 35+ messages in thread From: Paweł Lasek @ 2006-04-16 23:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* [9fans] Writing device drivers @ 2006-04-14 3:20 Eric Smith 0 siblings, 0 replies; 35+ messages in thread From: Eric Smith @ 2006-04-14 3:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2006-04-19 21:12 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-04-15 15:26 [9fans] Writing device drivers erik quanstrom 2006-04-15 23:04 ` Federico Benavento 2006-04-15 23:18 ` Skip Tavakkolian 2006-04-16 0:43 ` Federico G. Benavento 2006-04-16 18:03 ` Charles Forsyth 2006-04-16 18:14 ` Bruce Ellis 2006-04-16 21:31 ` Charles Forsyth -- strict thread matches above, loose matches on Subject: below -- 2006-04-19 3:10 erik quanstrom 2006-04-19 4:02 ` jmk 2006-04-19 4:57 ` lucio 2006-04-19 6:59 ` Nigel Roles 2006-04-19 21:12 ` quanstro 2006-04-17 0:31 erik quanstrom 2006-04-17 1:44 ` Russ Cox 2006-04-17 10:01 ` Nigel Roles 2006-04-18 1:34 ` erik quanstrom 2006-04-18 14:49 ` Nigel Roles 2006-04-18 15:42 ` jmk 2006-04-18 15:59 ` Moritz Kiese 2006-04-18 16:03 ` Nigel Roles 2006-04-18 19:15 ` Paweł Lasek 2006-04-17 0:11 erik quanstrom 2006-04-17 1:24 ` Russ Cox 2006-04-16 1:02 erik quanstrom 2006-04-16 2:36 ` Anthony Sorace 2006-04-16 8:06 ` Bruce Ellis 2006-04-15 23:34 erik quanstrom 2006-04-15 23:55 ` Skip Tavakkolian [not found] <8a5bd8ccbc2e53557663e2a9020fb26c@coraid.com> [not found] ` <820bc1260604140834v2a773ev90ff46b4e6b2427f@mail.gmail.com> 2006-04-14 15:36 ` Eric Smith 2006-04-14 19:33 ` David Leimbach 2006-04-15 4:58 ` jmk 2006-04-15 13:24 ` Eric Smith 2006-04-15 14:16 ` Anthony Sorace 2006-04-16 23:00 ` Paweł Lasek 2006-04-14 3:20 Eric Smith
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).