DragonFly kernel List (threaded) for 2006-03
Re: Device Classes
:For my user-space device driver thesis, I've been trying to figure out
:how DFly assigns device classes since I'm curious if I need a separate
:way to handle this (meaning I can't reuse any code found in the kernel).
:I have only glanced at sys/dev/agp/agp.c so far, but it seems that bus
:drivers define themselves to whatever they want. I assume this true for
:other bus drivers?
:Also, does each device driver indicate to the kernel if it's a block or
:character device (including IDE devices that I assume are all block
:devices)? Finally, where is the code that the kernel uses to
:keep track of the devices in the system and to which bus they're registered?
:Thanks in advance. This will provide a lot of insight I can use in
:preparing to propose to do the user-space device driver framework as a
:thesis to do on DFly.
:William Michael Grim
:Master's Student, Southern Illinois University at Edwardsville
:Unix Network Administrator, SIUE, Computer Science dept.
:Phone: (217) 341-6552
This is a fairly complex issue. There are two primary interfaces you
have to look at.
A device registers itself as a MAJOR number using the 'cdevsw'
structure. An example of this would be src/sys/dev/serial/si/si.c.
It declares this structure and calls cdevsw_add() to register the
major number space and a minor number mask, then it registers
subspaces in the minor number space using make_dev(). That attaches
a device to the filesystem block/character device space.
A device is typically associated with the machine BUS/DEVICE structure
through the NEWBUS device method calls. Probably the cleanest example
of this would be the EM GigE network driver in
The device registers the NEWBUS methods typically using a SYSINIT
(part of the automatic system initialization structure that gets executed
at boot time). The primary connection is via the PROBE function,
for example em_probe(). If the device driver recognizes the device
being probed it sets into a motion a whole chain of events which
ultimately causes its ATTACH function (e.g. em_attach()) to be called.
For the purposes of userspace device drivers I would *NOT* recommend
that you try to move any devices which talk to actual hardware into
userspace. Instead I would recommend sticking to just the VFS/filesystem
infrastructure since that infrastructure does not have to talk to any
devices and since filesystem drivers are the most likely sort of driver
you would want to run in userland.