Re: driver model, duplicate names question

[Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>]

On 07/17/2013 11:31 AM, Greg KH wrote:
> On Wed, Jul 17, 2013 at 11:09:44AM -0700, Srinivas Pandruvada wrote:
>>> 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.
> Where are you going to create a symlink from?  That doesn't make sense,
> just use a class if you want a link.
Sorry, my reply may not be clear here. I am not creating any symlinks.
device_register will create a symlink. For example, if I create a bus 
named "test",
with two parents and one child each:
ls -l /sys/bus/test/devices
lrwxrwxrwx 1 root root 0 Jul 17 09:05 child_0 -> 
../../../devices/parent_0/child_0
lrwxrwxrwx 1 root root 0 Jul 17 09:05 child_1 -> 
../../../devices/parent_1/child_1
lrwxrwxrwx 1 root root 0 Jul 17 09:05 parent_0 -> ../../../devices/parent_0
lrwxrwxrwx 1 root root 0 Jul 17 09:05 parent_1 -> ../../../devices/parent_1

>> 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 a separate filesystem alltogether?  That would work, but you then
> loose any benifit that the driver core and sysfs provides you, for no
> benifit other than looking at a pretty tree in a filesystem.  I don't
> see the real need for that at all.
>
>> 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.
> That's what other busses have used for this very reason :)
>
> Also look at the "type" of device you are creating for your bus, that
> will help you differentiate them from each other instead of having to
> rely on the names of them to determine what is going on within the
> kernel.
<Thanks for your time and help.>
> good luck,
>
> greg k-h
>