linux-kernel - Re: [RFC PATCH 0/2] fs: sysfs: Add devres support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 22 Nov 2013 14:53:30 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Guenter Roeck <linux@...ck-us.net>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] fs: sysfs: Add devres support

On Fri, Nov 22, 2013 at 02:47:38PM -0800, Dmitry Torokhov wrote:
> On Sat, Mar 16, 2013 at 09:21:40AM -0700, Greg Kroah-Hartman wrote:
> > On Thu, Mar 14, 2013 at 08:24:45PM -0700, Guenter Roeck wrote:
> > > Provide devres functions for device_create_file, sysfs_create_file,
> > > and sysfs_create_group plus the respective remove functions.
> > > 
> > > Idea is to be able to drop calls to the remove functions from the various
> > > drivers using those calls.
> > 
> > Hm, despite the fact that almost every driver that makes these calls is
> > broken?  :)
> > 
> > > Potential savings are substantial. There are more than 700 calls to
> > > device_remove_file in the kernel, more than 500 calls to sysfs_remove_group,
> > > and some 50 calls to sysfs_remove_file (though not all of those use dev->kobj
> > > as parameter). Expanding the API to sysfs_create_bin_file would add another 80+
> > > opportunities, and adding sysfs_create_link would create another 100 or so.
> > 
> > The idea is nice, but why are these drivers adding sysfs files on their
> > own?  Are they doing this in a way that is race-free with userspace
> > (i.e. creating them before userspace is told about the device), or are
> > they broken and need to have these calls added to the "default
> > device/driver/bus" attribute list for them instead?
> 
> Just stumbled upon this thread...
> 
> There is a need for drivers to add driver-specific attributes to a
> device. Since they are driver specific they can not go into bus or class
> or whatever default attributes that are created when device is
> instantiated, but rather attached to the device when a driver binds to
> them. An example would be a PS/2 mouse driver allowing user to control
> report rate and resolution of the device. Since it only applicable to
> PS/2 mice the knob does not belong to the generic serio layer/bus nor
> should it go into input layer as it is again PS/2 specific. So psmouse
> creates it while binding to a serio port.

Yeah, platform drivers also "need" this type of thing as well, so you
are right, I can't forbit it for everyone.

> Do we send a uevent when driver binds/unbinds from a device?

No, we don't, see kobject_actions[] for what we implement.

> If not I think we should so that userspace can check for additional
> attributes, if any.

We might be able to do a "change" event for the device itself after it
has been bound / unbound, but I don't know what userspace will do with
that information at this point in time (i.e. 10+ years without that
information...)

thanks,

greg k-h
--
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/