Device Classes

[Matthew Dillon]

:Hello, friends.
:
: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
:Email: wgrim at xxxxxxxx

    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
    src/sys/dev/netif/em/if_em.c.   

    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.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>