Re: driver model, duplicate names question

From: Srinivas Pandruvada
Date: Tue Jul 16 2013 - 14:48:13 EST


Hi,

I am assigned to do add a powercap class. There are several technologies, which will allow to
add a power budget to an individual device. For example, you can set a power budget to
a individual physical cpu package, each core and uncore devices, GPUs, DRAM etc.

+The Power Capping framework organizes power capping devices under a tree structure.
+At the root level, each device is under some "controller", which is the enabler
+of technology. For example this can be "RAPL".
+Under each controllers, there are multiple power zones, which can be independently
+monitored and controlled.
+Each power zone can be organized as a tree with parent, children and siblings.
+Each power zone defines attributes to enable power monitoring and constraints.
+
+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
+
+For example, above powercap sys-fs tree represents RAPL(Running Average Power Limit)
+type controls available in the Intel 64 and IA-32 Processor Architectures. Here
+under controller "intel-rapl" there are two CPU packages (package-0/1), which can
+provide power monitoring and controls. A RAPL controller provides control for each
+CPU package, so it can have one node for each package. In addition to providing
+monitoring and control at package level, each package is further divided into
+power zones (called domains in the RAPL specifications). Here zones represent controls
+for core and dram parts. These zones can be represented as children of package.
+Under RAPL framework there are two constraints, one for short term and one for long term,
+with two different time windows. These can be represented as two constraints, with
+different time windows, power limits and names.


Thanks,
Srinivas




On 07/16/2013 11:31 AM, Greg KH wrote:
On Tue, Jul 16, 2013 at 11:29:42AM -0700, Srinivas Pandruvada wrote:
Thanks for the quick response. Here I am creating virtual devices using
device_register.
I have attached a simple test program, which will give error.

This is my intention:

$> cd /sys/class/test_class
$> ls
power_zone_cpu_package_0
power_zone_cpu_package_1
Wait, you are mixing a class and a "real" bus up. This will fail as
your devices all end up on the virtual "bus" with the same name, in the
same location on the bus (look in /sys/devices/virtual/ for where they
will end up at.

That will fail, and rightly so.

Try using this with the proper 'struct bus_type' and let me know if
creating a device there with the same name will also fail.

Oh crud, it will, because we can't create symlinks with the same bus
type in the /sys/bus/BUSTYPE/devices/ directory.

So, don't use the same name for a device on the same bus, that way
causes confusion :)

Let's get back to your original "problem", what again are you trying to
solve? There should be a way to resolve this without having to deal
with duplicate names, perhaps you just want an attribute group with a
common name?

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/