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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
>
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
