Date: Tue, 21 Jul 1998 16:17:18 -0700 From: Mike Smith <mike@smith.net.au> To: john@ece.arizona.edu (John Galbraith) Cc: freebsd-hardware@FreeBSD.ORG, randal@comtest.com, dufault@FreeBSD.ORG Subject: Re: new GPIB driver Message-ID: <199807212317.QAA02618@dingo.cdrom.com> In-Reply-To: Your message of "Tue, 21 Jul 1998 15:21:54 PDT." <199807212221.PAA09431@burdell.ece.arizona.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Randal, I think this just might be your lucky day. 8) > I have a new GPIB driver that supports National products AT/GPIB and > GPIB/TNT. I believe it to be significantly better than the one > currently included in FreeBSD-2.2.6 (in /sys/i386/isa/gpib.c). It > should be a whole lot faster by the use of interrupts and different > polling techniques (which is why I started this in the first place). > My driver is a complete rewrite, with some insight gathered from both > the current FreeBSD driver and the Linux driver. The Linux driver was > particularly helpful, because National apparently likes to withhold > certain details about their products... (lame) No kidding. It's not always been that way; their products used to be well-documented and easy to work with. All that remains of the old tradition is price - their stuff is still too expensive. 8( > I would like to contribute my code, but would like some advice on how > to best package it. The best technique is to make sure that you have the following: - The driver source. Every source file should contain your copyright notice. - A manpage describing the driver, which should cover the relevance of the various config options, the programming interface, any diagnostics that the driver may emit and any other useful information. - Testimonials from at least one other independant user that has tested the driver (this is not mandatory, but it is desirable). Then submit a PR (using send-pr) summarising what you've got. Either include the stuff above in the PR (eg. uuencoded), or include a reference to a public FTP or HTTP server that contains the archive. Once you have a PR number, you can post to -hardware and -hackers letting people know about it, and just quote the PR. The PR is important, because it means that we have the submission on file, and the PR database is actively monitored (unlike the mailing list archives, which just slowly turn to compost over time). > It would be nice to have some other folks try it > out first, too. I still have to package it, though. I have been > debugging the driver as an lkm, but most drivers that you aren't > actually working on are easier if you just config them in. It would > seem best to make it work either way. Right on the mark with all of those. > Second, it exists in multiple > source files right now. Is it best to consolodate all the source into > one huge file, or leave it as several? Finally, how would I go about > showing that this code is reliable and is worthy of replacing the > current gpib.c? One single file is a little better from the point of view of ease of working on it, but by no means mandatory. See the 'matcd' driver for an example of a driver that comprises several files. One other advantage of having only a single source file is that you can declare all of your non-public functions static, and thus reduce namespace pollution (which is a real problem). Initially, I would suggest that you pick a new name for your driver, eg. 'nigpib'. I'd also talk to Fred Cawthorne (the author of the current gpib driver) and see whether he thinks the version in the system right now is worth preserving. It may be that his feelings are simply that it should die and yours should replace it, in which case exactly that would happen. > I haven't contributed anything before. It would be useful to me if > somebody more experienced with device drivers than myself would be > willing to look over what I have and make sure that I didn't do > anything particularly stupid. Sure. When you're happy it's working for you and your test candidates, submit the PR and start harrassing us to look at it. Please bear in mind that most of the committers are sufficiently overloaded that they work largely in interrupt mode - if you haven't gotten a result from us a few days after you ask, poke again. 8) > I do not take this list (should I?) so if you could make sure I am > explicitly included in any replies, that would be much appreciated. If you're planning to maintain the driver, it would be a good idea to try to watch the activity on either -current or -hackers, although this can be quite a lot of work. > Thanks! Thanks to you! -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807212317.QAA02618>