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

viro
2003-09-22T21:00:29Z

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).