linux-kernel - Re: driver model, duplicate names question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51E596E7.5040504@linux.intel.com>
Date:	Tue, 16 Jul 2013 11:54:31 -0700
From:	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
To:	Greg KH <gregkh@...uxfoundation.org>
CC:	Linux Kernel <linux-kernel@...r.kernel.org>,
	"Brown, Len" <len.brown@...el.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: driver model, duplicate names question

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