[Powertop] [RFC 0/9] Use udev for accessing sysfs

[Powertop] [RFC 0/9] Use udev for accessing sysfs

[Nanley Chery]

[-- Attachment #1: Type: text/plain, Size: 2328 bytes --]

From: Nanley Chery <nanley.g.chery(a)intel.com>

This patch series changes PowerTOP's method of accessing sysfs (for 
tunables mainly) from explicitly accessing files to using the standard
udev device management library and API.

The current codebase collects data on devices by probing sysfs files
directly with the usual low-level file handling API. This method is
not recommended by the Linux kernel maintainers because the sysfs
organization is not guaranteed to be stable over time. This can lead
to dependent applications breaking with newer kernel releases. Instead
using an abstraction layer, like udev, is suggested
(see https://www.kernel.org/doc/Documentation/sysfs-rules.txt).

The benefits of switching to udev include:
* The removal of libpci and a reduction in repetitive code.
* Improved readability of the tunable code.
* Faster reading of device state values due to caching provided by udev.

I've tried to make this transition as simple as possible by including
the bare minimum of changes required for this feature. There's at least
one more tunable that can be converted (i2c), but I would like to get
feedback on the current implementation first.

Nanley Chery (9):
  build with udev library
  add udev helper functions
  usb_tunable: use udev
  syfs_tunable: use udev
  runtime_tunable: use udev
  replace pciutils usage with udevhwdb
  runtime_pm: use udev
  remove libpci and most dead code
  calibrate: use udev

 Android.mk                  |   1 -
 README                      |   1 -
 configure.ac                |  20 ++-----
 src/Makefile.am             |   6 +-
 src/calibrate/calibrate.cpp |  44 ++++----------
 src/devices/runtime_pm.cpp  | 105 +++++++++++---------------------
 src/devices/runtime_pm.h    |   1 +
 src/lib.cpp                 | 100 +++++++++++++++++++++----------
 src/lib.h                   |   7 ++-
 src/main.cpp                |   4 +-
 src/tuning/runtime.cpp      | 139 +++++++++++++------------------------------
 src/tuning/runtime.h        |   6 +-
 src/tuning/tuningsysfs.cpp  |  12 +++-
 src/tuning/tuningsysfs.h    |   1 +
 src/tuning/tuningusb.cpp    | 142 ++++++++++++++------------------------------
 src/tuning/tuningusb.h      |   5 +-
 16 files changed, 231 insertions(+), 363 deletions(-)

-- 
2.4.1

Re: [Powertop] [RFC 0/9] Use udev for accessing sysfs

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

On 6/1/2015 9:09 AM, Nanley Chery wrote:
> From: Nanley Chery <nanley.g.chery(a)intel.com>
>
> This patch series changes PowerTOP's method of accessing sysfs (for
> tunables mainly) from explicitly accessing files to using the standard
> udev device management library and API.
>
> The current codebase collects data on devices by probing sysfs files
> directly with the usual low-level file handling API. This method is
> not recommended by the Linux kernel maintainers because the sysfs
> organization is not guaranteed to be stable over time. This can lead
> to dependent applications breaking with newer kernel releases. Instead
> using an abstraction layer, like udev, is suggested
> (see https://www.kernel.org/doc/Documentation/sysfs-rules.txt).

.... how does this work on Android ?

Re: [Powertop] [RFC 0/9] Use udev for accessing sysfs

[Nanley Chery]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

On Mon, Jun 1, 2015 at 9:09 AM, Arjan van de Ven <arjan(a)linux.intel.com> wrote:
> On 6/1/2015 9:09 AM, Nanley Chery wrote:
>>
>> From: Nanley Chery <nanley.g.chery(a)intel.com>
>>
>> This patch series changes PowerTOP's method of accessing sysfs (for
>> tunables mainly) from explicitly accessing files to using the standard
>> udev device management library and API.
>>
>> The current codebase collects data on devices by probing sysfs files
>> directly with the usual low-level file handling API. This method is
>> not recommended by the Linux kernel maintainers because the sysfs
>> organization is not guaranteed to be stable over time. This can lead
>> to dependent applications breaking with newer kernel releases. Instead
>> using an abstraction layer, like udev, is suggested
>> (see https://www.kernel.org/doc/Documentation/sysfs-rules.txt).
>
>
> .... how does this work on Android ?

That's a good question. I actually hadn't considered the affects on
that platform. It seems like there is no udev-like abstraction layer
on Android. It looks like the way forward would be to either keep a
separate folder for android specific code or to create more helper
functions to abstract how we access sysfs. The latter method seems
preferable because it wouldn't increase the complexity of the project
as a whole. Thoughts?

- Nanley

Re: [Powertop] [RFC 0/9] Use udev for accessing sysfs

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

On 6/3/2015 1:23 PM, Nanley Chery wrote:

>>
>> .... how does this work on Android ?
>
> That's a good question. I actually hadn't considered the affects on
> that platform. It seems like there is no udev-like abstraction layer
> on Android. It looks like the way forward would be to either keep a
> separate folder for android specific code or to create more helper
> functions to abstract how we access sysfs. The latter method seems
> preferable because it wouldn't increase the complexity of the project
> as a whole. Thoughts?

but if we keep the code anyway, what's the benefit of going through one
more layer of indirection????
Am I missing something here?

Re: [Powertop] [RFC 0/9] Use udev for accessing sysfs

[Nanley Chery]

[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]

On Wed, Jun 3, 2015 at 1:25 PM, Arjan van de Ven <arjan(a)linux.intel.com> wrote:
> On 6/3/2015 1:23 PM, Nanley Chery wrote:
>
>>>
>>> .... how does this work on Android ?
>>
>>
>> That's a good question. I actually hadn't considered the affects on
>> that platform. It seems like there is no udev-like abstraction layer
>> on Android. It looks like the way forward would be to either keep a
>> separate folder for android specific code or to create more helper
>> functions to abstract how we access sysfs. The latter method seems
>> preferable because it wouldn't increase the complexity of the project
>> as a whole. Thoughts?
>
>
> but if we keep the code anyway, what's the benefit of going through one
> more layer of indirection????
> Am I missing something here?

The main benefit would be increased protection from sysfs
reorganizations with progressive kernel releases. If this is actually
something we should be proactive about, I am not sure.
Udev should provide faster reading of sysfs files due to caching, but
I do not have any hard numbers to back this claim up.
Lastly there are some general wins in the realm of software
readability and maintainability (in my opinion). This should make the
process of adding more features and fixing bugs easier.

- Nanley