Date: Thu, 24 May 2001 10:47:13 -0700 From: Peter Wemm <peter@wemm.org> To: SJ <sandejain@rocketmail.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Device driver questions Message-ID: <20010524174713.A9C03380C@overcee.netplex.com.au> In-Reply-To: <20010523003414.51600.qmail@web13405.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
SJ wrote: > Hi all, > I am new to writing device drivers...so please excuse > my ignorance. > > I have a couple of questions regarding that: > > 1. "ioconf.c" contains struct config_resource and > config_device definitions for declarations in > "config" file. But I noticed that for some devices > e.g. device atadisk > device atapicd > ... > the corresponding lines in ioconf.c are missing?? Ignore ioconf.c. It is the old way of providing static driver info for things like the isa bus.. eg: what IO port to look for a device on. New isa drivers have all this pre-processed for them. There are only some special cases (eg: fd) that still use the resource_*() functions directly. > 2. Whats the use of device_ops structure and what does > "ops" stand for? Operations.. It is a list of functions or implementation methods that a device supports. > 3. File naming question: > whats the reasoning behind having "bus.h" and > "bus_private.h"....whats the significance of > "private" here. bus_private.h means you should ignore it. It exists only so that several different kernel files can share private information. Everything in there is 100% subject to change without notice. > 4. concept behind having devclasses...I know that > devclasses for a particular bus holds devices and > device drivers for that bus. But then whats the > need for defining a devclass for each driver we > write ? Devclasses keep track of unit numbers for drivers. It also allows you to get hold of another driver's device units by using it as a handle for devclass_get_device(). > 5. Any poniters to literature which explains the > design philosophy and code specific help for device > drivers in freebsd - I am referring to files > kern/subr_bus.c, bus.h, bus_private.h, isa/* etc. Paul Richards did an excellent primer on this stuff at BSDCon 2000. I wonder if the slides are around anywhere? Other than that, look at some drivers. Most of the drivers in sys/dev/* and sys/isa/* are newbus aware. Some are better examples than others though :-/. In a nutshell though, the new bus implementation is a dynamic, stackable, pseudo OO-like driver/bus framework. It is designed with the assumption that most present and future busses will be self identifying (eg: have device id's for devices). id's are discovered and offered to drivers in an auction-like fashion. Each node on the device/bus/whatever tree implements a set of methods (device_ops) that are expected by its parent and/or children. This means that a bus node expects its potential child drivers to implement the required set of device (probe/attach/etc) methods. The child drivers expect their parent to implement the expected set of methods to support that kind of driver (eg: bus_alloc_resource etc) This means that a given bus/driver pair are completely oblivious to how it is attached to the rest of the system.. eg: an isa bus can be on a pci->isa bridge or an old-style ISA-only system where the isa bus is at the root of the tree. The isa devices dont know (or care) that they may be sitting behind a PCI device on an Alpha that has a MMU-like device (scatter-gather map) that enables ISA devices there to access all 64bits of address space, not just the usual 24 bits of space. > thanks for your help, > SJ > > __________________________________________________ > Do You Yahoo!? > Yahoo! Auctions - buy the things you want at great prices > http://auctions.yahoo.com/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 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?20010524174713.A9C03380C>