From owner-freebsd-hackers Thu Jan 30 06:17:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA12354 for hackers-outgoing; Thu, 30 Jan 1997 06:17:58 -0800 (PST) Received: from bacall.lodgenet.com (bacall.lodgenet.com [205.138.147.242]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA12349 for ; Thu, 30 Jan 1997 06:17:54 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id IAA21428; Thu, 30 Jan 1997 08:17:02 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma021420; Thu Jan 30 08:16:43 1997 Received: from jake.lodgenet.com (jake.lodgenet.com [10.0.11.30]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id IAA09745; Thu, 30 Jan 1997 08:16:01 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.8.4/8.6.12) with ESMTP id IAA29041; Thu, 30 Jan 1997 08:17:07 -0600 (CST) Message-Id: <199701301417.IAA29041@jake.lodgenet.com> X-Mailer: exmh version 2.0beta 12/23/96 To: "Brian J. McGovern" cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: Cases (was: Constructive Criticism) In-reply-to: Your message of "Wed, 29 Jan 1997 22:01:40 EST." <199701300301.WAA09208@spoon.beta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 08:17:06 -0600 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Brian J. McGovern" writes: >> >>> The second major area of concern in my eyes is device >>> drivers. Someone pointed me to a section of handbook that dealt with >>> doing it (supposedly), but it was terribly out of date. Back to >> >>If you can't work out how device drivers are integrated, I seriously >>doubt that you're up to writing one in the first place. 8( >> > >Ah, again, a circle effect. You'll never get good till you've chewed on a >handful of them. And you'll never start on your first till you think you >can do it. Everyone I've ever talked to about device drivers says something to the effect of "its not rocket science". Its just one of those things that you need to go through a few times. I often look back on drivers I did even two months ago and see lots of things I could do better. The nice thing about drivers is that they're usually small enough that it only takes a week or so to totally rip one apart and start over with the good parts. Of course there's always exceptions, but you shouldn't be starting with that complex a project. > >But, because I don't like arguing for the sake of arguing, here's a plan. >Tomorrow, whilest I'm at work, I will write some code for a pseudo-device >driver I wish to call foo. I will write routines for fooinit, fooread, >and foowrite. Just from this sentence, its obvious that you haven't read even sparse documentation that your picking at ;-) *BSD doesn't have a fooinit, SysV does. BSD uses fooprobe() and fooattach(). If your device is connected to a bus of any kind (or wants to pretend it is) you have a probe() to do a quick presence test. If the probe returns anything other than zero, your attach routine will be called to do further config. If you have a true pseudo-device (like if_tun, vnode, etc) you'll have just an attach(). > According to the documentation I've read, I should be able to >leave the open and close routines set to (I guess NULL ?) nothing. Just to understand where you're coming from, what documentation is this? > fooinit >will also exist, but will just contain a printf to announce the presence of >the pseudo-driver. The driver will be a character driver, with major number >of 20. Minor number will represent buffer numbers, each buffer will be 1K >in length. Writes to a buffer will set the string. Reads will return it (if >the full length is specified). Optionally, I'll use the offset attributes >to allow multiple reads and writes. Lastly, all of these routines will >be in a file called foodev.c. > That all looks OK. >Now, based on my reading, and what I've seen in some of the drivers >I _have_ looked at, I believe that I'll have to set a cdevsw structure up, Yes, in 2.2 and later, the driver is responsible for it's own [cb]devsw structure. >and it looks like a struct isa_driver. only if your device wants to pretend its an isa device. It could also want to be a pc-card, scsi, pci, eisa, or real pseudo device. All of these busses are slightly different. > I also see probe() and attach() >routines that I have not seen documentation on before in the books I have >read. The 4.4 Daemon book mentions them. I think the 4.3 and possibly Vahalia do too. Check out as many of these as you can get your hands on: Writing Device Drivers: Tutorial and Reference; Tim Burke, Mark A. Parenti, Al, Wojtas; Digital Press, ISBN 1-55558-141-2. Pretty good all around device driver book, geared toward Digital Unix, but it's probably closer to *BSD than any other book I've seen. Writing A Unix Device Driver; Janet I. Egan, Thomas J. Teixeira; John Wiley & Sons, ISBN 0-471-62859-X. System V oriented. The best section is the appendix that explains differences between BSD and SysV Writing Device Drivers for SCO Unix; Peter Kettle, Steve Statler; Addison-Wesley, ISBN 0-201-54425-3 A good introduction to device drivers, SCO oriented (obviously). But covers a lot of the basics of unix drivers. These are more on the kernel in general, but theres lots of good stuff here: The Design and Implementation of the 4.3BSD Unix Operating System; Leffler, McKusick, Karels, and Quarterman; Addison-Wesley, ISBN 0-201-06196-1 The Design and Implementation of the 4.4BSD Unix Operating System; McKusick, Bostic, Karels, and Quarterman; Addison-Wesley, ISBN 0-201-54979-4 Unix Internals the New Frontiers; Uresh Vahalia; Prentice Hall, ISBN 0-13-101908-2 anyone more? > > -Brian > eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com