lkml.org 
[lkml]   [2013]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: driver model, duplicate names question
On 07/16/2013 12:32 PM, Greg KH wrote:
> On Tue, Jul 16, 2013 at 12:33:03PM -0700, Srinivas Pandruvada wrote:
>>>> +Example Sys-FS Interface
>>>> +
>>>> +/sys/class/power_cap/intel-rapl
>>>> +├── package-0
>>>> +│ ├── constraint-0
>>>> +│ │ ├── name
>>>> +│ │ ├── power_limit_uw
>>>> +│ │ └── time_window_us
>>>> +│ ├── constraint-1
>>>> +│ │ ├── name
>>>> +│ │ ├── power_limit_uw
>>>> +│ │ └── time_window_us
>>>> +│ ├── core
>>>> +│ │ ├── constraint-0
>>>> +│ │ │ ├── name
>>>> +│ │ │ ├── power_limit_uw
>>>> +│ │ │ └── time_window_us
>>>> +│ │ ├── energy_uj
>>>> +│ │ └── max_energy_range_uj
>>>> +│ ├── dram
>>>> +│ │ ├── constraint-0
>>>> +│ │ │ ├── name
>>>> +│ │ │ ├── power_limit_uw
>>>> +│ │ │ └── time_window_us
>>>> +│ │ ├── energy_uj
>>>> +│ │ └── max_energy_range_uj
>>>> +│ ├── energy_uj
>>>> +│ ├── max_energy_range_uj
>>>> +│ └── max_power_range_uw
>>>> +├── package-1
>>>> +│ ├── constraint-0
>>>> +│ │ ├── name
>>>> +│ │ ├── power_limit_uw
>>>> +│ │ └── time_window_us
>>>> +│ ├── constraint-1
>>>> +│ │ ├── name
>>>> +│ │ ├── power_limit_uw
>>>> +│ │ └── time_window_us
>>>> +│ ├── core
>>>> +│ │ ├── constraint-0
>>>> +│ │ │ ├── name
>>>> +│ │ │ ├── power_limit_uw
>>>> +│ │ │ └── time_window_us
>>>> +│ │ ├── energy_uj
>>>> +│ │ └── max_energy_range_uj
>>>> +│ ├── dram
>>>> +│ │ ├── constraint-0
>>>> +│ │ │ ├── name
>>>> +│ │ │ ├── power_limit_uw
>>>> +│ │ │ └── time_window_us
>>>> +│ │ ├── energy_uj
>>>> +│ │ └── max_energy_range_uj
>>>> +│ ├── energy_uj
>>>> +│ ├── max_energy_range_uj
>>>> +│ └── max_power_range_uw
>>>> +├── power
>>>> +│ ├── async
>>>> +│ ├── autosuspend_delay_ms
>>>> +│ ├── control
>>>> +│ ├── runtime_active_kids
>>>> +│ ├── runtime_active_time
>>>> +│ ├── runtime_enabled
>>>> +│ ├── runtime_status
>>>> +│ ├── runtime_suspended_time
>>>> +│ └── runtime_usage
>>>> +├── subsystem -> ../../../../class/power_cap
>>>> +└── uevent
>>> Ick. Rewrite this to use a bus and you should be fine, right? Don't
>>> use a class, a class is only to be used if you have a device that is a
>>> specific "type of thing". Like a tty device, it is a class, as lots of
>>> different "real" devices can have tty ports on them (usb, pci, pcmcia,
>>> platform, etc.)
>>>
>>> Rethink this using a bus and see if that solves your issues. You get a
>>> hierarchy with that. And you can have different "types" of devices on
>>> your bus, making it easy to tell the difference between a "package" and
>>> a "constraint".
>>>
>>> Does that help?
>> I will experiment your suggestion. I see this class analogous to
>> "/sys/class/thermal",
>> , where the thermal class provides a set of consistent interface for all
>> thermal devices.
> But thermal devices are not "real" at all. There are just a number of
> "cooling devices" on a virtual bus and not attached to any type of a
> real device at all.
Similar to cooling drivers, the power cap client drivers don't have to
be real.
For example intel rapl just uses x86 MSRs. But some other drivers can be
using
PCIe and use this framework to export control to users.
> There's also no hierarchy that I can see with the thermal class, but you
> want to have this, so you will have to do something different because
> classes do not have hierarchies.
The reason, we tried not have hierarchy for ease of management from
a user space. If I use this flat model, then showing relationships need
to use
some sort of linking like regulator class. Do you have preference for
such model?
> So try using a device and a bus and see if that helps out. If not,
> please let me know.
Looking at this possibility.
> thanks,
>
> greg k-h
>
Thanks,
Srinivas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2013-07-16 22:41    [W:0.535 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site