Messages in this thread | | | Date | Mon, 22 Sep 2003 22:00:21 +0100 | From | viro@parcelfa ... | Subject | Re: [PATCH] RFC: Attributes in /sys/cdev |
| |
On Mon, Sep 22, 2003 at 10:46:09AM -0600, Jonathan Corbet wrote: > > > I have no idea whether this follows the original plan for /sys/cdev. > > > > They are more of a side effect. > > So...to be sure I have things straight.../sys/cdev isn't really meant to be > there, and char devices wanting to do things in sysfs should be working > under /sys/devices or /sys/class or /sys/somethingelse?
<nod>
For block devices we really have non-trivial properties associated with them - struct gendisk and request queue, for one thing. And these are uniform across the entire set.
Character devices per se have *no* meaningful properties common to the entire class. To put it another way, while block devices do form a natural class, character ones do not.
> > * driver has embedded struct cdev in its data structures > > > * ->open() can use ->i_cdev to get whatever data structure driver > > had intended and avoid any lookups of its own > > I noticed there's no "private" member in the cdev structure. So drivers > should embed the structure and use container_of to get their real structure > of interest?
Yes, if they bother with cdev of their own in the first place.
> [Forgive my ignorance here...] If I embed a struct cdev within my own > device structure, how do I know when I can safely free said device > structure? Will there be a release method that gets exposed at the driver > level, or am I missing something obvious again?
Umm... Any kobject has ->release() method, obviously. NOTE: as always, embedding kobject into one of your objects requires serious thinking about lifetime rules for your objects. Until they are cleaned up you'd better *not* mess with that. OTOH, in a lot of cases cleanup is needed anyway - e.g. if you declare per-object sysctls/procfs entries/whatnot, you have the same sort of problems already (plus you need to deal with the same sort of races in your code that finds object by major:minor; many drivers are FUBAR in that area). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |