Date: Tue, 11 Apr 2000 08:27:44 +0100 (BST) From: Duncan Barclay <dmlb@ragnet.demon.co.uk> To: Mike Smith <msmith@freebsd.org> Cc: hackers@freebsd.org Subject: Re: Help with network driver development Message-ID: <XFMail.000411082744.dmlb@computer.my.domain> In-Reply-To: <200004110637.XAA00514@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mike, On 11-Apr-00 Mike Smith wrote: > > Sorry that this is off-list - I'm blocked by the DUL at the moment, but > please copy your replies there. > >> I've successfully ported the NetBSD if_ray (Webgear PCCard Wireless LAN) >> driver to RELENG_3 but have realised that the driver has a bit of a >> problem and I would like some advice on the best way to fix it. > > Heh. I have a small pile of these cards and I am _itching_ to see the > driver on -current. Consider me at your disposal. 8) Thanks! Where can I go to understand NEWBUS (for later)? I've managed to get 170kB/s ftp to/from Windows and FreeBSD boxes. 170kB/s is a maxed out 2Mb/s IEEE 802.11 link, so I'm reasonably happy. Range isn't bad at about 70m indoors-outdoors and might be a little better if you have the firmware that supports antenna diversity. I might also put in something that turns down the data-rate as the received signal power drops (by slowing the data-rate one increases the signal to noise ratio and range should increase). >> The problem is that the driver returns to userland before the >> command (e.g. update to multicast list via an ioctl) actually >> completes. > > This is actually really easy to handle; you want to use a similar > architecture to a block device. > > Set up a command queue. To submit a command, you do this: [code snipped] Thanks, I was planning on doing something like that but hadn't got it fully worked out. >> My question to all the network driver gods is how best to serialise >> access to the driver to different userland processes? I want to ensure >> that two different processes don't try and access the card >> simultaneously and muck each other up. > > The command queue approach is very simple, easy to debug, and is widely > used in our codebase already. I spend a lot of time looking at other > peoples' drivers (mostly in Linux space) and I've seen a lot of people > trying to solve this problem in a lot of very wrong ways. Save yourself > the trouble. 8) The Linux driver for these cards has calls to a function named spinlock() all over the place - I really hope it doesn't do what's on the box. One of my testers reckons my driver is about twice as fast for random receive/transmit patterns, and I have't implemented chaining tx packets yet because of another race. >> Is something like this sufficient (and right) for ioctl entry? > > It's probably sufficient, but much more complex than necessary. Be very > careful with using PCATCH too - your logic will need to deal with > handling a completed command after the submitter has gone away (the > queued command approach works OK here as long as you remember to dequeue > the command - remember that when tsleep returns you are back at splnet()). I like reusing the queue idea here (with another queue I presume) to serialise t he access. I see what you mean about PCATCH, is it easier to not bother about using it? >> PS. Until pccard in RELENG_4 allows access to both attribute and common >> memory (a bit like if_xe) the driver won't be advanced to > RELENG_3 :-( > > So I understand. Grr. Now that Warner's fried his iOpener, maybe he'll > get back to this. 8) It looks like there is a way to jury rig something for RELENG_4 but by hacking pccard.c to export a few functions. I'll also need to get my head around NEWBUS. Duncan --- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. ________________________________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.000411082744.dmlb>