Re: driver model, duplicate names question

[Srinivas Pandruvada]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/