Browse files

Staging: Merge 2.6.37-rc5 into staging-next

This was done to handle a number of conflicts in the batman-adv
and winbond drivers properly.  It also now allows us to fix up the sysfs
attributes properly that were not in the .37 release due to them being
only in this tree at the time.

Signed-off-by: Greg Kroah-Hartman <>
  • Loading branch information...
gregkh committed Dec 7, 2010
2 parents 03fa6fc + cf7d7e5 commit ea3398a1ae54cd3403f3cc0f6aa498c7452c681a
Showing 991 changed files with 16,878 additions and 8,098 deletions.
@@ -0,0 +1,83 @@
+What: /sys/bus/rbd/
+Date: November 2010
+Contact: Yehuda Sadeh <>,
+ Sage Weil <>
+Being used for adding and removing rbd block devices.
+Usage: <mon ip addr> <options> <pool name> <rbd image name> [snap name]
+ $ echo " name=admin rbd foo" > /sys/bus/rbd/add
+The snapshot name can be "-" or omitted to map the image read/write. A <dev-id>
+will be assigned for any registered block device. If snapshot is used, it will
+be mapped read-only.
+Removal of a device:
+ $ echo <dev-id> > /sys/bus/rbd/remove
+Entries under /sys/bus/rbd/devices/<dev-id>/
+ The ceph unique client id that was assigned for this specific session.
+ The block device major number.
+ The name of the rbd image.
+ The pool where this rbd image resides. The pool-name pair is unique
+ per rados system.
+ The size (in bytes) of the mapped block device.
+ Writing to this file will reread the image header data and set
+ all relevant datastructures accordingly.
+ The current snapshot for which the device is mapped.
+ Create a snapshot:
+ $ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_create
+ Rolls back data to the specified snapshot. This goes over the entire
+ list of rados blocks and sends a rollback command to each.
+ $ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_rollback
+ A directory per each snapshot
+Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
+ The rados internal snapshot id assigned for this snapshot
+ The size of the image when this snapshot was taken.
@@ -79,10 +79,6 @@
- <chapter id="clk">
- <title>Clock Framework Extensions</title>
- </chapter>
<chapter id="mach">
<title>Machine Specific Interfaces</title>
<sect1 id="dreamcast">
@@ -16,7 +16,7 @@
- <email></email>
+ <email></email>
@@ -114,7 +114,7 @@ GPL version 2.
<para>If you know of any translations for this document, or you are
interested in translating it, please email me
@@ -171,7 +171,7 @@ interested in translating it, please email me
<para>Find something wrong with this document? (Or perhaps something
right?) I would love to hear from you. Please email me at
- <email></email>.</para>
+ <email></email>.</para>
@@ -154,7 +154,7 @@ The stages that a patch goes through are, generally:
inclusion, it should be accepted by a relevant subsystem maintainer -
though this acceptance is not a guarantee that the patch will make it
all the way to the mainline. The patch will show up in the maintainer's
- subsystem tree and into the staging trees (described below). When the
+ subsystem tree and into the -next trees (described below). When the
process works, this step leads to more extensive review of the patch and
the discovery of any problems resulting from the integration of this
patch with work being done by others.
@@ -236,7 +236,7 @@ finding the right maintainer. Sending patches directly to Linus is not
normally the right way to go.
The chain of subsystem trees guides the flow of patches into the kernel,
but it also raises an interesting question: what if somebody wants to look
@@ -250,7 +250,7 @@ changes land in the mainline kernel. One could pull changes from all of
the interesting subsystem trees, but that would be a big and error-prone
-The answer comes in the form of staging trees, where subsystem trees are
+The answer comes in the form of -next trees, where subsystem trees are
collected for testing and review. The older of these trees, maintained by
Andrew Morton, is called "-mm" (for memory management, which is how it got
started). The -mm tree integrates patches from a long list of subsystem
@@ -275,7 +275,7 @@ directory at:
Use of the MMOTM tree is likely to be a frustrating experience, though;
there is a definite chance that it will not even compile.
-The other staging tree, started more recently, is linux-next, maintained by
+The other -next tree, started more recently, is linux-next, maintained by
Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
the mainline is expected to look like after the next merge window closes.
Linux-next trees are announced on the linux-kernel and linux-next mailing
@@ -303,12 +303,25 @@ volatility of linux-next tends to make it a difficult development target.
See for more information on this topic, and
stay tuned; much is still in flux where linux-next is involved.
-Besides the mmotm and linux-next trees, the kernel source tree now contains
-the drivers/staging/ directory and many sub-directories for drivers or
-filesystems that are on their way to being added to the kernel tree
-proper, but they remain in drivers/staging/ while they still need more
+The kernel source tree now contains the drivers/staging/ directory, where
+many sub-directories for drivers or filesystems that are on their way to
+being added to the kernel tree live. They remain in drivers/staging while
+they still need more work; once complete, they can be moved into the
+kernel proper. This is a way to keep track of drivers that aren't
+up to Linux kernel coding or quality standards, but people may want to use
+them and track development.
+Greg Kroah-Hartman currently (as of 2.6.36) maintains the staging tree.
+Drivers that still need work are sent to him, with each driver having
+its own subdirectory in drivers/staging/. Along with the driver source
+files, a TODO file should be present in the directory as well. The TODO
+file lists the pending work that the driver needs for acceptance into
+the kernel proper, as well as a list of people that should be Cc'd for any
+patches to the driver. Staging drivers that don't currently build should
+have their config entries depend upon CONFIG_BROKEN. Once they can
+be successfully built without outside patches, CONFIG_BROKEN can be removed.
2.5: TOOLS
@@ -1,129 +0,0 @@
-Device Interfaces
-Device interfaces are the logical interfaces of device classes that correlate
-directly to userspace interfaces, like device nodes.
-Each device class may have multiple interfaces through which you can
-access the same device. An input device may support the mouse interface,
-the 'evdev' interface, and the touchscreen interface. A SCSI disk would
-support the disk interface, the SCSI generic interface, and possibly a raw
-device interface.
-Device interfaces are registered with the class they belong to. As devices
-are added to the class, they are added to each interface registered with
-the class. The interface is responsible for determining whether the device
-supports the interface or not.
-Programming Interface
-struct device_interface {
- char * name;
- rwlock_t lock;
- u32 devnum;
- struct device_class * devclass;
- struct list_head node;
- struct driver_dir_entry dir;
- int (*add_device)(struct device *);
- int (*add_device)(struct intf_data *);
-int interface_register(struct device_interface *);
-void interface_unregister(struct device_interface *);
-An interface must specify the device class it belongs to. It is added
-to that class's list of interfaces on registration.
-Interfaces can be added to a device class at any time. Whenever it is
-added, each device in the class is passed to the interface's
-add_device callback. When an interface is removed, each device is
-removed from the interface.
-Once a device is added to a device class, it is added to each
-interface that is registered with the device class. The class
-is expected to place a class-specific data structure in
-struct device::class_data. The interface can use that (along with
-other fields of struct device) to determine whether or not the driver
-and/or device support that particular interface.
-struct intf_data {
- struct list_head node;
- struct device_interface * intf;
- struct device * dev;
- u32 intf_num;
-int interface_add_data(struct interface_data *);
-The interface is responsible for allocating and initializing a struct
-intf_data and calling interface_add_data() to add it to the device's list
-of interfaces it belongs to. This list will be iterated over when the device
-is removed from the class (instead of all possible interfaces for a class).
-This structure should probably be embedded in whatever per-device data
-structure the interface is allocating anyway.
-Devices are enumerated within the interface. This happens in interface_add_data()
-and the enumerated value is stored in the struct intf_data for that device.
-Each interface is given a directory in the directory of the device
-class it belongs to:
-Interfaces get a directory in the class's directory as well:
- class/
- `-- input
- |-- devices
- |-- drivers
- |-- mouse
- `-- evdev
-When a device is added to the interface, a symlink is created that points
-to the device's directory in the physical hierarchy:
- class/
- `-- input
- |-- devices
- | `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
- |-- drivers
- | `-- usb:usb_mouse -> ../../../bus/drivers/usb_mouse/
- |-- mouse
- | `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
- `-- evdev
- `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
-Future Plans
-A device interface is correlated directly with a userspace interface
-for a device, specifically a device node. For instance, a SCSI disk
-exposes at least two interfaces to userspace: the standard SCSI disk
-interface and the SCSI generic interface. It might also export a raw
-device interface.
-Many interfaces have a major number associated with them and each
-device gets a minor number. Or, multiple interfaces might share one
-major number, and each will receive a range of minor numbers (like in
-the case of input devices).
-These major and minor numbers could be stored in the interface
-structure. Major and minor allocations could happen when the interface
-is registered with the class, or via a helper function.
@@ -196,7 +196,7 @@ csrow3.
The representation of the above is reflected in the directory tree
in EDAC's sysfs interface. Starting in directory
/sys/devices/system/edac/mc each memory controller will be represented
-by its own 'mcX' directory, where 'X" is the index of the MC.
+by its own 'mcX' directory, where 'X' is the index of the MC.
@@ -207,7 +207,7 @@ by its own 'mcX' directory, where 'X" is the index of the MC.
Under each 'mcX' directory each 'csrowX' is again represented by a
-'csrowX', where 'X" is the csrow index:
+'csrowX', where 'X' is the csrow index:
@@ -232,7 +232,7 @@ EDAC control and attribute files.
In 'mcX' directories are EDAC control and attribute files for
-this 'X" instance of the memory controllers:
+this 'X' instance of the memory controllers:
Counter reset control file:
@@ -343,7 +343,7 @@ Sdram memory scrubbing rate:
In the 'csrowX' directories are EDAC control and attribute files for
-this 'X" instance of csrow:
+this 'X' instance of csrow:
Total Uncorrectable Errors count attribute file:
Oops, something went wrong.

0 comments on commit ea3398a

Please sign in to comment.