Driving Me Nuts - Device Classes
This function looks almost like the i2c_adapter class registration code, with two exceptions. First, the class_dev.dev field is set to be either the adapter's parent device or the adapter's device. This is done because some i2c adapters do not have a real parent in the global kernel device tree, as they live on a bus that has not been converted to the kernel driver model (like ISA) or they do not really live on a bus at all (like some i2c embedded controllers). When an i2c adapter does not have a place in the kernel device tree, it is assigned to the legacy bus. The legacy bus, located at /sys/devices/legacy, is used for these kinds of devices.
The second thing that is different with this class device is the line:
class_device_create_file (&i2c_dev->class_dev, &class_device_attr_dev);
The class_device_create_file function is used to create a file in the class device's directory. The filename and attributes are defined with the CLASS_DEVICE_ATTR macro as:
static ssize_t
show_dev(struct class_device *class_dev, char *buf)
{
struct i2c_dev *i2c_dev = to_i2c_dev(class_dev);
return sprintf(buf, "%04x\n",
MKDEV(I2C_MAJOR, i2c_dev->minor));
}
static
CLASS_DEVICE_ATTR(dev, S_IRUGO, show_dev, NULL);
The CLASS_DEVICE_ATTR macro is itself defined as:
#define CLASS_DEVICE_ATTR(_name,_mode,_show,_store) \
struct class_device_attribute \
class_device_attr_##_name = { \
.attr = {.name = __stringify(_name), \
.mode = _mode }, \
.show = _show, \
.store = _store, \
};
The arguments within the CLASS_DEVICE_ATTR macro are:
_name: both the name of the file to be created in sysfs and part of the variable name that describes this whole attribute.
_mode: the file access mode with which the file is created. Use the standard access macros to specify the proper value.
_show: points to a function that is called when the file is read from. This function must have the following return value and parameters. This variable does not have to be set if the file is not to be read from.
ssize_t show (struct class_device *class_dev, char *buf);
_store: points to a function that is called when the file is written to. This function must have the following return value and paramaters. This variable does not have to be set if the file is not to be written to.
ssize_t store (struct device *dev, const char *buf, size_t count);
Almost all driver model structures have an ATTR() macro that declares a file within the sysfs tree.
In this example, a file named dev is created when the class_device_create_file function is called. This file is created to be read-only by any user. If the file is read from, the show_dev function is called by the driver core. The show_dev function fills in the buffer passed to it with the information it wants to give the user. In this case, the major and minor number for this specific device are passed to the user. All class devices using a major and minor number should have a dev file within their sysfs class device directory.
The class_device_remove_file function can be used to remove any files created by the class_device_create_file function. But it is not necessary to remove manually any file created if the device is about to be removed. When devices are removed from sysfs, all files created in their directories are removed automatically by the sysfs core. So, when the i2c-dev class device is removed from the system, all that is needed is the following:
static void
i2c_remove_class_device(int minor)
{
struct i2c_dev *i2c_dev = NULL;
struct list_head *tmp;
int found = 0;
spin_lock(&i2c_dev_list_lock);
list_for_each (tmp, &i2c_dev_list) {
i2c_dev = list_entry(tmp, struct i2c_dev,
node);
if (i2c_dev->minor == minor) {
found = 1;
break;
}
}
if (found) {
list_del(&i2c_dev->node);
spin_unlock(&i2c_dev_list_lock);
class_device_unregister(&i2c_dev->class_dev);
kfree(i2c_dev);
} else {
spin_unlock(&i2c_dev_list_lock);
}
}
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- What's the tweeting protocol?
- RSS Feeds
- New Products
- Trying to Tame the Tablet
- Dart: a New Web Programming Experience
- Reply to comment | Linux Journal
14 hours 31 min ago - Reply to comment | Linux Journal
17 hours 3 min ago - Reply to comment | Linux Journal
18 hours 21 min ago - great post
18 hours 56 min ago - Google Docs
19 hours 18 min ago - Reply to comment | Linux Journal
1 day 7 min ago - Reply to comment | Linux Journal
1 day 53 min ago - Web Hosting IQ
1 day 2 hours ago - Thanks for taking the time to
1 day 4 hours ago - Linux is good
1 day 6 hours ago




Comments
Re: Device Classes
Cool description of sysfs, i wonder if it is possible to describe how a user-space app (kde, gnome, etc) could use it to some benefit for it