Re: driver model, duplicate names question

[Srinivas Pandruvada]

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

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