We have a bunch of reports from people who have a custom kernel and
are confused why udev is not running. Issue a warning on
error. Barring an error in the code, the only error that is possible
is ENOSYS.
https://bugzilla.redhat.com/show_bug.cgi?id=1072966
Cases where name_to_handle_at is used allocated the full struct to be
MAX_HANDLE_SZ, and assigned this size to handle_bytes. This is wrong
since handle_bytes should describe the length of the flexible array
member and not the whole struct.
Define a union type which includes sufficient padding to allow
assignment of MAX_HANDLE_SZ to be correct.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
Under some conditions, in udev_rules_apply_to_event the fact that
result is 1024 bytes, creates problems if the output of the running
command/app is bigger then 1024 bytes.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
The way the kernel namespaces have been implemented breaks assumptions
udev made regarding uevent sequence numbers. Creating devices in a
namespace "steals" uevents and its sequence numbers from the host. It
confuses the "udevadmin settle" logic, which might block until util a
timeout is reached, even when no uevent is pending.
Remove any assumptions about sequence numbers and deprecate libudev's
API exposing these numbers; none of that can reliably be used anymore
when namespaces are involved.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
We switch to defining _GNU_SOURCE as we do for cdrom_id.c
for a more consistant approach to this issue.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
The type definitions usec_t and nsec_t where defined twice: in
path-util.h and util.h.
time-util.h and time-util.c now gather the time-related functions and
definitions (as in upstream systemd).
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
This reverts commit 8741f2defa: 'Add virtio-blk support to path_id' and
commit e3d563346c4237af23335cc6904e0662efdf62ad: 'udev: net_id - handle virtio buses'.
Distros may want to take note of this, as it changes behavior.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
This is upstream commits
f89b42ec0fd51feab5566d6bdbacee101023c037
15f392394e75ffb7f318920008fd1bbe4e82b488
by Marcel Holtmann <marcel@holtmann.org> and Scott Thrasher <scott.thrasher@gmail.com>
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
Dropping <fcntl.h> in favor of <linux/fcntl.h> is incorrect. Yet
uClibc needs O_CLOEXEC from <linux/fcntl.h>. So we re-introduce
<fcntl.h> and include <linux/fcntl.h> only on uClibc systems to
avoid redefinitions.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
modified: src/udev/udev-builtin-kmod.c
Temporary copies of the arguments to the 'execv' call are made so that gcc doesn't give,
possibly confusing warning about 'discarding const' during compilation.
Input devices like rudders or pedals are joystick-like; they don't have
buttons, but axes like RX, THROTTLE, or RUDDER. These don't interfere with
other device types with absolute axes (touch screens, touchpads, and
accelerometers), so it's fairly safe to mark them as ID_INPUT_JOYSTICK and thus
hand out dynamic ACLs to the user.
https://bugs.freedesktop.org/show_bug.cgi?id=70734
GCC optimizes strlen("string constant") to a constant, even with -O0.
Thus, replace patterns like sizeof("string constant")-1 with
strlen("string constant") where possible, for clarity. In particular,
for expressions intended to add up the lengths of components going into
a string, this often makes it clearer that the expression counts the
trailing '\0' exactly once, by putting the +1 for the '\0' at the end of
the expression, rather than hidden in a sizeof in the middle of the
expression.
Commit 80b10107cb added #include <linux/fcntl.h> in
src/accelerometer and friends for builds on uclibc.
This only works with glibc and musl systems with
linux headers 3.9 but fails with linux headers 3.13.
We keep <linux/fcntl.h> but drop <fcntl.h>.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
Keymaps for Samsung 900X3E and 900X3F should be the same as for other
models in the series.
I have also moved the comment for '# Series 9' to the right place
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
