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] [thread-next>] [day] [month] [year] [list]

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

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.

Do we send a uevent when driver binds/unbinds from a device? If not I
think we should so that userspace can check for additional attributes,
if any.

Thanks.

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