Re: driver model, duplicate names question

[Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>]

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