Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

[Dmitry Torokhov]

On Fri, Nov 06, 2015 at 04:24:07PM -0800, Greg Kroah-Hartman wrote:
> On Fri, Oct 30, 2015 at 08:13:11AM -0700, Dmitry Torokhov wrote:
> > On Fri, Oct 30, 2015 at 07:40:37AM -0700, Greg Kroah-Hartman wrote:
> > > On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> > > > Many drivers create additional driver-specific device attributes when
> > > > binding to the device and providing managed version of sysfs_create_group()
> > > > will simplify unbinding and error handling in probe path for such drivers.
> > > 
> > > But they really shouldn't, because if they do this, they have raced
> > > userspace and tools don't know that the files are present.
> > > 
> > > I don't want to encourage drivers to do this at all, so I don't want to
> > > make it easier for them to do things incorrectly.
> > 
> > The solution is not to forbid drivers from establishing attributes but
> > rather notify userspace when device is fully bound to the driver. Then
> > userspace that actually cares about these attributes will listen to
> > proper events.
> > 
> > We can either do KOBJ_BOUND/KOBJ_UNBOUND or reuse
> > KOBJ_ONLINE/KOBJ_OFFLINE. I'd prefer the former (adding new events).
> 
> bound/unbound makes a bit more sense, maybe that would work, haven't
> thought that much about it.  Given that no one in the "real world" seem
> to notice the race condition, that means that people aren't really using
> tools like libudev to read sysfs attributes, so maybe no one even cares
> about the contents of them :)

Could be, or they have workarounds for this scenario.

> 
> > > Yes, I know that input does this for its devices, but I still think it
> > > is wrong and should be changed.  Let's not let this problem spread to
> > > other subsystems please.
> > 
> > Like HID, chargers, hwmon, wireless drivers, leds, backlights, platform
> > drivers and so on? Where are platform devices supposed to create their
> > attributes? There are more than 300 drivers that add new groups and 581
> > instance of device_create_file().
> 
> Platform drivers are the main problem right now, I don't know what to do
> about them.  I hate those things :(
> 
> > Let's be realistic here and see that additional attributes are not going
> > anywhere and adding devm interface just helps getting error handling
> > right.
> 
> But the files are already removed from the system when the device is
> removed,

In this case the device to which we attach attributes is not removed
though, it is still present in the system.

> so with the exception of the odd error path on probe, this
> isn't doing much.  Does it save much code when used?

It basically allows replacing code like:

static void rohm_ts_remove_sysfs_group(void *_dev)
{
	struct device *dev = _dev;

	sysfs_remove_group(&dev->kobj, &rohm_ts_attr_group);
}

static int rohm_bu21023_i2c_probe(struct i2c_client *client, ...)
{
	...

	error = sysfs_create_group(&dev->kobj, &rohm_ts_attr_group);
	if (error) {
		dev_err(dev, "failed to create sysfs group: %d\n", error);
		return error;
	}

	error = devm_add_action(dev, rohm_ts_remove_sysfs_group, dev);
	if (error) {
		rohm_ts_remove_sysfs_group(dev);
		dev_err(&client->dev,
			"Failed to add sysfs cleanup action: %d\n",
			error);
		return error;
	}

	...
}

with:

static int rohm_bu21023_i2c_probe(struct i2c_client *client, ...)
{
	...

	error = devm_sysfs_create_group(dev, rohm_ts_attr_group);
	if (error)
		return error;

	...
}

which is arguable much more compact.

That assuming that the driver is using devm construct. In case driver
used goto error unwinding it really depends at what point the attributes
were created, but I strongly advise against mixing devm and goto
unwinding in one driver as it leads to confusion as to what strategy a
given resource is using, manual or devm?

Thanks.

-- 
Dmitry
--
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/