http://lwn.net/Articles/31220/ This is a special feed containing comments posted to the individual LWN article titled "Driver porting: Devices and attributes". hourly 2 http://lwn.net/Articles/208250/rss 2006-11-08T08:23:42+00:00 stanleychen_augmentum You mentioned that System bus devices are represented by struct sys_device. Does System bus here mean platform bus which is virtual ? <br> http://lwn.net/Articles/184467/rss 2006-05-19T21:17:19+00:00 flatfive What are the merits of supporting drivers written in C++?<br> <p> <p> http://lwn.net/Articles/37996/rss 2003-06-26T15:14:42+00:00 Alan.Stern This otherwise helpful article contains a mistake that has been made by several developers. Device drivers do not own the device structures they register; these are owned by the bus driver. The most important consequence of this is that the device driver cannot know when all references to its device structure have gone away. References to a device attribute file may persist indefinitely, for as long as a user process has the attribute file open.<p>This means that even after a driver has de-registered its device and has been rmmod'ed and unloaded from memory, the attribute's show() or store() methods might be called. Of course this would be a disaster, since the code for that method would no longer exist.<p>People now recognize that drivers should only create attributes for device structures that they own. The proper way to create a device-specific attribute is to attach the attribute to a class_device, because the driver is able to create and own its class_devices. A driver should never attach an attribute to the device structure it is bound to.<br> http://lwn.net/Articles/32380/rss 2003-05-15T17:14:02+00:00 ncm This is a clever and sneaky way to ensure that no drivers written in C++ can be added on, or even ported from 2.4. It was possible, before. <p> Shame on somebody.