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

Powered by Openwall GNU/*/Linux Powered by OpenVZ