| Age | Commit message (Collapse) | Author |
|---|
|
Instead of using multiple recursive Makefile.am files, use a single
Makefile.am that sets and builds all the basic suite of libraries and
binaries for udev. This reduces the number of files in the source tree, and
also reduces drastically the build time when using parallel-make.
With this setup, all the compile steps will be executed in parallel, and
just the linking stage will be (partially) serialised on the libraries
creation.
|
|
See https://launchpad.net/bugs/407940
|
|
If by-path / by-id links don't quite do what you want, this is a nice
clean way to extend the behaviour. Real example:
SYMLINK=="serial/by-id/usb-Novatel_Wireless_Inc*CDMA*-if00-port0", \\
SYMLINK+="cellcard"
Some users ask how to do things like this.
- create an additional link with a shorter name
- create a link which matches more loosely
(omit certain path segments e.g. serial numbers)
- change permissions on certain USB device nodes
Allow them to realize this without reading the friendly *.c files.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
|
|
Dates aren't shown in the manpages. So they are not really useful,
and no-one is going to remember to update them.
"<refmiscinfo class="version"></refmiscinfo>" sounds even less useful.
I leave the unused "title" and "productname" tags. They could
theoretically be useful, and aren't hard to maintain. We just need to
fix the "title" for udevadm.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
|
|
Reported by Dirk Thierbach <dthierbach@gmx.de> on hal ML.
|
|
|
|
|
|
It did not work for the last couple of releases.
If RUN{record_failed}+="..." is given, a non-zero execution will mark
the event as failed. Recorded failed events can be re-triggered with:
udevadm trigger --type=failed
The failed tracking _might_ be useful for things which might not be
ready to be executed at early bootup, but a bit later when the needed
dependencies are available. In many cases though, it indicates that
something is used in a way it should not.
|
|
|
|
|
|
User needs read-write access to joystick devices in order to use force
feedback features.
|
|
Exclude digitizers and similar devices from ID_CLASS joystick by
checking modalias for BTN_DIGI.
This was also done for linux kernel joydev interface in linux commit
d07a9cba6be5c0e947afc1014b5a62182a86f1f1.
|
|
|
|
I have recently been getting the above message on fc11 and
I have traced it down to a bug in util_lookup_group.
As of 145 util_lookup_group reads:
gid_t util_lookup_group(struct udev *udev, const char *group)
{
char *endptr;
int buflen = sysconf(_SC_GETGR_R_SIZE_MAX);
char buf[buflen];
struct group grbuf;
struct group *gr;
gid_t gid = 0;
if (strcmp(group, "root") == 0)
return 0;
gid = strtoul(group, &endptr, 10);
if (endptr[0] == '\0')
return gid;
errno = 0;
getgrnam_r(group, &grbuf, buf, buflen, &gr);
if (gr != NULL)
return gr->gr_gid;
if (errno == 0 || errno == ENOENT || errno == ESRCH)
err(udev, "specified group '%s' unknown\n", group);
else
err(udev, "error resolving group '%s': %m\n", group);
return 0;
}
The errno value from getgrnam_r here is ERANGE which is documented as
"Insufficient buffer space supplied".
When I call get getgrnam_r with a large enough buffer everything
works. Indicating that the problem is that sysconf is returning
a value too small.
A quick google search tells me that sysconf(_S_GETGR_R_SIZE_MAX)
is documented as:
> sysconf(_S_GETGR_R_SIZE_MAX) returns either -1 or a good
> suggested starting value for buflen. It does not return the
> worst case possible for buflen.
In my case I have a group with about 50 users in /etc/group
and that is what triggered the problem in udev and caused
all of the udevs group lookups to fail.
The following patch which dynamically allocates the group member buffer
should fix this problem.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
|
|
of each card
Generally ALSA control devices should be the last ones to be processed
for ACL changes and similar operations because they can then be used as
indicators that ACL management finished for all device nodes of a
specific card.
This patch simple moves each controlC device behind all the pcmC devices
(and similar).
|
|
|
|
We must never access random devices in /dev which do not belong to
the event we are handling. Hard-coding /dev/hidrawX, and looping over all
devices is absolutely not acceptable --> hook into hidraw events.
We can not relay on (rather random) properties merged into the parent
device by earlier rules --> use libudev to find the sibling device
with a matching interface.
Libusb does not fit into udev's use case. We never want want to scan
and open() all usb devices in the system, just to find the device
we are already handling the event for --> put all the stupid scanning
into a single function and prepare for a fixed libusb or drop it later.
|
|
|
|
|
|
|
|
The keymap table has some holes in it, which caused the interactive mode to
crash for unknown keys. In these cases, print the numeric key code instead.
|
|
What's odd is that this is a huawei modem, not an option modem, so one would
expect it to work better with usb_modeswitch and it's -H (huawei) mode - but
that's not the case, I've tested that as well.
https://launchpad.net/bugs/401655
|
|
$ udevadm trigger -n -v --subsystem-match=usb --sysname-match=2-1.1*
/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.1
/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.1/2-1.1.1
/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1:1.0
/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.1/2-1.1.2
/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.1/2-1.1.2/2-1.1.2:1.0
/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.1/2-1.1.2/2-1.1.2:1.1
/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.1/2-1.1:1.0
|
|
|
|
|
|
|
|
|
|
|
|
Reported on hal ML by Sergey Astanin <s.astanin@gmail.com>.
|
|
|
|
https://launchpad.net/bugs/48547
|
|
https://launchpad.net/bugs/35382 shows that may Evo N* models share the same
keymap, so generalize the existing rule.
|
|
https://launchpad.net/bugs/20223
|
|
|
|
Do not complain about missing keymap files when giving scancode/keyname pairs
on the keymap command line in the rules.
|
|
Remove key map files which have only one override. Instead, use keymap tools'
new feature of specifying scancode/keyname pairs directly at the command line.
Also add a comment to 95-keymap.rules about how to specify key mappings in the
rules.
|
|
This avoids having to create and parse an entire keymap file for cases where
just one or two keys have to be remapped.
|
|
Do not duplicate help strings, and add missing calling variant for
interactivity.
|
|
https://launchpad.net/bugs/198530
|
|
Reported in https://launchpad.net/bugs/400921
|
|
|
|
Reported on https://launchpad.net/bugs/400252
|
|
Reported as hal-info patch by Németh Márton <nm127@freemail.hu> on hal ML.
|
|
|
|
|
|
We may need to handle SIGCHLD before the queued worker message. The last
reference, from the SIGCHLD or the worker message will clean up the worker
context. In case we receive an unexpected SIGCHLD with an error, we let
the event fail and clean up the worker context.
|
|
Persistent network rules write out new rules files. When rules change,
we need to kill all workers to update the in-memory copy of the rules.
We need to make sure, that a worker finshes its work for all device
messages it has accepted, before it exits after a SIGTERM from the main
process.
|
|
<zzam> kay: udevadmin info -e prints all lines with a space after the :, but the W: line
<kay> zzam: yeah, seems so, and the R: and the A:
<zzam> yeah
|
|
Jul 8 09:36:41 udevd[663]: worker [5491] did not accept message, kill it
Jul 8 09:36:41 udevd[663]: worker [5491] unexpectedly returned with 0
Jul 8 09:36:41 udevd[663]: worker [5551] unexpectedly returned with 0
Jul 8 09:36:41 kernel: [ 156.832086] <6>udevd[663]: segfault at 4 ip 00959fbc sp bfbe7b78 error 6 in udevd[94f000+1c000]
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/396957
|
|
On machines with many thousands of devices:
$ time find /sys -name uevent | wc -l
74876
real 0m33.171s
user 0m3.329s
sys 0m29.719s
the current udevtrigger spends minutes sorting the device list:
$ time /sbin/udevadm trigger --dry-run
real 4m56.739s
user 4m45.743s
sys 0m7.862s
with qsort() it looks better:
$ time udev/udevadm trigger --dry-run
real 0m6.495s
user 0m0.473s
sys 0m5.923s
|
