Re: [PATCH] RFC: Attributes in /sys/cdev

[viro]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/