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.
>
> 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.
>
> So try using a device and a bus and see if that helps out.  If not,
> please let me know.
Experimented by using a device and a bus. As your initial mail pointed 
out, it still fails.
It will try to create symlink to /sys/bus/BUSTYPE/devices/, which will 
prevent duplicate names.
Someone suggested to do like usb by creating file system entries, which 
will require me to
wear a body armour to post upstream for review.

So I think the solution is to use prevent duplicate names. So in the 
above example of sys-fs:

"package-0" may be called power_zone#, with attribute "name" = 
"package_0". Its children can
be called power_zone#:#. I will still use parent child relationships 
during device_register.
For constraints, I will be using attributes like constraint_0_name, 
constraint_0_power_limit etc. under each power_zone.
Hope this is an acceptable solution.
> thanks,
>
> greg k-h

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