On recent systems, extra configuration files can live in
/etc/ld.so.conf.d, so check this directory too, before warning.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6045 7894878c-1315-0410-8ee3-d5d059ff63e0
attributes. These are defined in the standard sysfs interface for quite
some time, and at least three drivers (max6650, lm63 and applesmc)
implement them so we should support them.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6029 7894878c-1315-0410-8ee3-d5d059ff63e0
now, but this make it possible to add more feature types without
increasing the code complexity beyond reason. Define constants and use
them to make the code even easier to understand.
If anyone is really worried about the relatively large memory
allocation, one way to improve the situation would be a two-pass
approach. But remember the memory is only needed for a short time...
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@5874 7894878c-1315-0410-8ee3-d5d059ff63e0
George Spelvin).
The lifetimes of the path and label name buffers are
disjoint, so a single buffer can be used for both purposes.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@5748 7894878c-1315-0410-8ee3-d5d059ff63e0
There were multiple in-line calls that then fell through to
a common exit. Instead, set up a pointer to the original
strings, and have a single strdup in the common code.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@5747 7894878c-1315-0410-8ee3-d5d059ff63e0
representation of chip names.
sensord, sensors: Fix a memory leak when one or more chip names are
provided on the command line.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@5740 7894878c-1315-0410-8ee3-d5d059ff63e0
Most filesystems (in particular - reiserfs, jfs, xfs, nfs); maybe,
some legacy installation of ext2/3 too) always return dirent->dt_type =
DT_UNKNOWN, so libsensors fails to parse /etc/sensors.d.
Also, symlink (DT_LNK) can point to directory, or FIFO/socket/device
(very bad!) - current check insufficient anyways.
Fixed by always using stat() to check what each entry is, rather than
relying on dirent->dt_type.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@5730 7894878c-1315-0410-8ee3-d5d059ff63e0
From: Didier Roche <didrocks@ubuntu.com>
Hi lm-sensors developer,
It would be great if lm-sensors can take into account distribution
LDFLAGS so that exported variables change linker behavior.
For instance, ubuntu uses -Wl,-Bsymbolic-functions. Taking this patch
will enable us to just sync from debian on this package.
In Ubuntu, we've applied the attached patch to achieve the following:
* handle default ubuntu LDFLAGS for linking option (LP: #321632)
- Remove the old hack directly pushed in lib/Module.mk (now
lib/Module.mk if from pristine source)
- add debian/patches/07-use-LDFLAGS.patch to take LDFLAGS into account
Debian and Ubuntu thought you might be interested to handle this
directly upstream.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@5713 7894878c-1315-0410-8ee3-d5d059ff63e0
chip entries. This is a prerequisite to add support for multiple
configuration files. Each configuration file can come with its own bus
statements and the bus number substitution should only affect chip
entries from the same configuration file.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@5646 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare