Messages in this thread | | | Date | Wed, 17 Jul 2013 11:09:44 -0700 | From | Srinivas Pandruvada <> | Subject | Re: 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. > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |