Date: Sun, 27 Feb 2000 15:05:37 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> Cc: new-bus@freebsd.org Subject: Re: New version of the newbus draft Message-ID: <Pine.BSF.4.21.0002271505030.8714-100000@salmon.nlsystems.com> In-Reply-To: <Pine.BSF.4.21.0002271411580.8714-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Here is a first draft of a document on the new-bus method system.
The New-bus Object System
========================
The core of the new-bus system is an extensible object-based
programming model. Each device in the system has a table of methods
which it supports. The system and other devices uses those methods to
control the device and request services. The different methods
supported by a device are defined by a number of ``interfaces''. An
``interface'' is simply a group of related methods which can be
implemented by a device.
In the new-bus system, the methods for a device are provided by the
various device drivers in the system. When a device is attached to a
driver during auto-configuration, it uses the method table declared by
the driver. A device can later detach from its driver and re-attach to
a new driver with a new method table. This allows dynamic replacement
of drivers which can be useful for driver development.
The interfaces are described by an interface definition language
similar to the language used to define vnode operations for
file systems. A simple example interface (which would normally be in a
file named foo_if.m) might look like this:
INTERFACE FOO
METHOD int doit {
device_t dev;
};
METHOD int doit_to_child {
device_t dev;
device_t child;
};
When this interface is compiled, it generates a header file
``foo_if.h'' which contains function declarations:
int FOO_DOIT(device_t dev);
int FOO_DOIT_TO_SOMEONE(device_t dev, device_t child);
and also a source file ``foo_if.c'' which contains implementations of
those functions which look up the location of the relevant functions
in the object's method table and call that function.
The system defines two main interfaces. The first fundamental
interface is called ``device'' and includes methods which are relevant
to all devices. Methods in the ``device'' interface include ``probe'',
``attach'' and ``detach'' to control detection of hardware and
``shutdown'', ``suspend'' and ``resume'' for critical even
notification.
The second, more complex interface is ``bus''. This interface contains
methods suitable for devices which have children, including methods to
access bus-specific per-device information (read_ivar and write_ivar),
event notification (child_detached, driver_added) and resource
management (alloc_resource, activate_resource, deactivate_resource,
release_resource).
Many methods in the ``bus'' interface are performing services for some
child of the bus device. These methods would normally use the first
two arguments to specify the bus providing the service and the child
device which is requesting the service. To simplify driver code, many
of these methods have accessor functions which lookup the parent and
call a method on the parent. For instance the method
BUS_TEARDOWN_INTR(device_t dev, device_t child, ...) can be called
using the function bus_teardown_intr(device_t child, ...).
Some types of bus in the system define additional interfaces to
provide access to bus-specific functionality. For instance, the pci
bus driver defines the ``pci'' interface which has two methods
``read_config'' and ``write_config'' for accessing the configuration
registers of a pci device.
--
Doug Rabson Mail: dfr@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-new-bus" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0002271505030.8714-100000>