From owner-freebsd-hackers Tue Apr 11 10: 4:27 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id E6BCA37BB48; Tue, 11 Apr 2000 10:04:20 -0700 (PDT) (envelope-from dmlb@ragnet.demon.co.uk) Received: from ragnet.demon.co.uk ([158.152.46.40]) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 12f45H-000DZm-0A; Tue, 11 Apr 2000 17:04:15 +0000 Received: from dmlb by ragnet.demon.co.uk with local (Exim 3.03 #1) id 12ev5M-000N6b-00; Tue, 11 Apr 2000 08:27:44 +0100 Content-Length: 3643 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200004110637.XAA00514@mass.cdrom.com> Date: Tue, 11 Apr 2000 08:27:44 +0100 (BST) From: Duncan Barclay To: Mike Smith Subject: Re: Help with network driver development Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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