[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130717183105.GA14988@kroah.com>
Date: Wed, 17 Jul 2013 11:31:05 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
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
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.
> 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.
good luck,
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/
Powered by blists - more mailing lists