lkml.org 
[lkml]   [2002]   [Dec]   [21]   [last100]   RSS Feed
Views: [more markup]   [less markup]   [headers]   [forward]  
 
Messages in this thread
Patch in this message
/
DateSat, 21 Dec 2002 01:00:45 -0800
From"Adam J. Richter" <>
SubjectRe: RFC: bus_type and device_class merge (or partial merge)
>If you're interested, I've finished a paper for linux.conf.au on the 
>driver model that should describe the various objects and purposes (much 
>better than the Ottawa paper did). You can find it at: 
>
>http://kernel.org/pub/linux/kernel/people/mochel/doc/lca/driver-model-lca2003.tar.gz

	Thanks.  I've read it now.  Here is a proposed patch.  The
only substantive change is a correction to the misunderstanding about
the risk of bus driver modules being unloaded (you might want to
delete the second paragraph that I added).  I've cc'ed linux-kernel
as others might want to comment that proposed change.

	The other changes are just typos and one TeX quirk (apparentlyd
underscores don't have to be escaped in "verbatim" sections).

-- 
Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."diff -u -r driver-model-lca2003/source/buses.tex driver-model-lca2003.modified/source/buses.tex
--- driver-model-lca2003/source/buses.tex	2002-12-18 09:57:33.000000000 -0800
+++ driver-model-lca2003.modified/source/buses.tex	2002-12-21 00:57:20.000000000 -0800
@@ -211,24 +211,28 @@
 \end{table}
 
 
-There are two caveats of using bus drivers as they are currently
-implemented in the driver model . First, the de facto means of
-referencing a bus driver is via a pointer to its struct
-bus\_type. This implies that the bus drivers must not declare the
-object as 'static' and must be explicitly exported for modules to
-use. An alternative is to provide a helper that searches for and
-returns a bus with a specified name. This is a more desirable solution
-from an abstraction perspective, and will likely be added to the
-model.  
-
-Secondly, bus drivers contain no internal means of preventing their
-module to unload while their reference count is positive. This causes
-the referring object to access invalid memory if the module is
-unloaded. The proposed solution is to use a semaphore, like device
-drivers contain, that bus\_unregister() waits on, and is only unlocked
-when the reference count reaches 0. This will be fixed in the near
-future. 
-
+A bus driver is referenced via a pointer to its struct bus\_type. This
+implies that the bus drivers must not declare the object as 'static'
+and that it must be explicitly exported for modules to use. The reference
+to the bus driver's struct bus\_type means that the bus driver module
+will automatically be loaded by modprobe before any users of that
+bus type.  It also means that the dependency code built into the
+kernel module system will prevent a bus driver from being unloaded
+until all device drivers for that bus are unloaded, elmininating the
+need to reference counting or other locking schemes.
+
+An alternative is to provide a helper that searches for and
+returns a bus with a specified name, which might be useful with,
+for example, a module that contained drivers for PCI and
+MicroChannel versions of a device and one wanted to build a kernel
+with support for both drivers built in and then run this driver
+in a situtation where, say, the MicroChannel bus module was not
+available (for example on a customized ram disk).  However, if this
+were really necessary, then splitting such a module into bus specific
+parts and a ``core'' would reduce kernel footprint and probably result
+in less complexity than implementing run-time lookup of bus types,
+and developing a scheme for rebinding such a driver if, for example,
+the microchannel bus driver is loaded later.
 
 \subsection*{Driver Binding}
 
@@ -339,16 +343,16 @@
 \begin{footnotesize}
 \begin{verbatim}
 
-struct callback\_data {
+struct callback_data {
        struct device * dev;
        char * id;
 };
 
 static int callback(struct device * dev, void * data)
 {
-        struct callback\_data * cd = (struct callback\_data *)data;
-        if (!strcmp(dev->bus\_id,cd->id)) {
-                cd->dev = get\_device(dev);
+        struct callback_data * cd = data;
+        if (!strcmp(dev->bus_id,cd->id)) {
+                cd->dev = get_device(dev);
                 return 1;
         }
         return 0;
@@ -356,15 +360,15 @@
 
 static int caller(void)
 {
-        struct callback\_data data = {
+        struct callback_data data = {
                 .id = "00:00.0",
         };
 
         /* find PCI device with ID 00:00.0  */
-        if(bus\_for\_each\_dev(&pci\_bus\_type,&data,callback)) {
+        if(bus_for_each_dev(&pci_bus_type,&data,callback)) {
                 struct device * dev = data.dev;
                 /* fiddle with device */
-                put\_device(dev);
+                put_device(dev);
         }
 }
 
diff -u -r driver-model-lca2003/source/classes.tex driver-model-lca2003.modified/source/classes.tex
--- driver-model-lca2003/source/classes.tex	2002-12-18 11:53:00.000000000 -0800
+++ driver-model-lca2003.modified/source/classes.tex	2002-12-21 00:07:01.000000000 -0800
@@ -122,10 +122,10 @@
 
 
 Struct device\_class most closely resembles struct bus\_type. Indeed,
-many of the fields of struct device\_class server a similar purpose as
+many of the fields of struct device\_class serve a similar purpose as
 those in struct bus\_type. The subordinate subsystem 'devsubsys' and
 the 'devices' list manage the list of devices registered with the
-class. Like with buses, these structures must exist in parallel, since
+class. As with buses, these structures must exist in parallel, since
 a kobject may not belong to more than one subsystem at a time. The
 same is true of the 'drvsubsys' and 'drivers' list with regard to
 drivers registered with the classes.
diff -u -r driver-model-lca2003/source/devices.tex driver-model-lca2003.modified/source/devices.tex
--- driver-model-lca2003/source/devices.tex	2002-12-18 11:35:06.000000000 -0800
+++ driver-model-lca2003.modified/source/devices.tex	2002-12-20 08:35:20.000000000 -0800
@@ -63,7 +63,7 @@
 
 saved\_state	& void *	& Pointer to saved state for device. \\\hline
 
-dma\_mask	& dma\_mask\_t *	& DMA address mask the device
+dma\_mask	& dma\_mask\_t	& DMA address mask the device
 	can support.\\\hline
 
 \end{tabularx} \\
diff -u -r driver-model-lca2003/source/platform.tex driver-model-lca2003.modified/source/platform.tex
--- driver-model-lca2003/source/platform.tex	2002-12-18 10:33:57.000000000 -0800
+++ driver-model-lca2003.modified/source/platform.tex	2002-12-21 00:08:28.000000000 -0800
@@ -216,7 +216,7 @@
 cause problems, though, when a driver is running on a platform where
 the ports to probe for existence are different. It doesn't even have
 to be different architectures, only different revisions of the same
-platform. Probing undefined I/O ports is dangerous and cause very
+platform. Probing undefined I/O ports is dangerous and causes very
 unpredictable behavior. It can also be a very slow process, and
 significantly delay the boot process.
 
diff -u -r driver-model-lca2003/source/sysfs.tex driver-model-lca2003.modified/source/sysfs.tex
--- driver-model-lca2003/source/sysfs.tex	2002-12-18 09:57:33.000000000 -0800
+++ driver-model-lca2003.modified/source/sysfs.tex	2002-12-20 08:34:42.000000000 -0800
@@ -74,7 +74,7 @@
 sysfs has been a standard part of the Linux kernel as of version
 2.5.45. It has existed under a different name (driverfs or ddfs) since
 kernel version 2.5.2. The de-facto standard mount point for sysfs is a
-new directory named '/sys'. It may be mounted from user pace by doing:
+new directory named '/sys'. It may be mounted from user space by doing:
 
 
 \begin{alltt}
\
 
 \ /
  Last update: 2005-03-22 11:31    [W:0.214 / U:0.230 seconds]
©2003-2008 Jasper Spaans