Message-ID: <20130710223438.GA22519@roeck-us.net>
Date:	Wed, 10 Jul 2013 15:34:38 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org, oliver+list@...inagl.nl,
	khali@...ux-fr.org
Subject: Re: Driver core and sysfs changes for attribute groups

On Wed, Jul 10, 2013 at 03:23:37PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Jul 10, 2013 at 03:04:41PM -0700, Guenter Roeck wrote:
> > On Wed, Jul 10, 2013 at 01:05:08PM -0700, Greg Kroah-Hartman wrote:
> > > Hi all,
> > > 
> > > Guenter and Oliver have been pointing out a few limitations of the
> > > driver core's ability to create files properly (i.e. in a way that
> > > doesn't race with userspace.)  The driver core allows this, but it
> > > doesn't export that ability to drivers very easily, and for binary
> > > files, not at all.
> > > 
> > > So here's a set of 6 patches that I'll be queueing up to go to Linus in
> > > time for 3.11 so that people can start using them in their driver
> > > subsystems.  It adds some new macros to make using attributes and
> > > attribute groups easier, adds binary file capabilities to attribute
> > > groups, and finally, lets subsystems (like platform drivers) set a
> > > attribute group for when their device is created.
> > > 
> > > If anyone has any problems with these patches, please let me know.
> > > 
> > > Guenter, I've tweaked your original patch a bit, changing the name of
> > > the function and putting the kernel doc comments in the correct place so
> > > the build doesn't complain about it.
> > > 
> > I like it - thanks a lot for picking that up. I think there are several
> > drivers who could and should use the new API call (gpio, infiniband/umad,
> > c2port, ptp, scsi/osst, android/timed_output, asus_oled are some examples).
> 
> Yes, I'll be sweeping the tree for the next few released doing all of
> this.  The amount of sysfs "cruft" that has accumulated in the past few
> years since I last looked is crazy...
> 
> > For hwmon, I ended up having to handle device creation internally after all.
> > Reason is that I also had to set device->type to a new hwmon device type.
> > That in turn was necessary to be able to support the hwmon 'name' attribute
> > properly (it has to be optional, meaning I could not use class->dev_attrs but
> > had to use device_type->groups instead). I hope I can send out a revised
> > series of patches soon .. only I'll leave for pto next week and I am bugged
> > down with other work right now, so it may have to wait until after I return.
> > 
> > Wonder if it would make sense to support a core driver API call for that
> > purpose as well - ie one that not only has the additional groups argument,
> > but one that (also ?) accepts a pointer to the the device type. I didn't spend
> > any time tracking down potential users, though, so I may be off track here.
> 
> I don't understand the problem, for USB we have different "types" of
> devices on the bus just fine.  Or are you saying that the function you
> created isn't going to be used in the hwmon core in the end?
> 
> I doubt device_create() really needs to worry about different types, but
> I could be wrong :)
> 
All I needed was the dev_groups field you just added to the class structure.
I am currently merging your patches into my code, so you'll get some free test
coverage ...

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists