If any devices are marked with 'SYSTEMD_READY=0' then we shouldn't run any
btrfs check on them.
Indeed there's no point in running "btrfs ready" on devices that already have
SYSTEMD_READY=0 set. Most probably such devices are members of a higher layer
aggregate device such as dm-multipath or software RAID. Doing IO on them wastes
time at best, and may cause delays, timeouts, or even hangs at worst (think
active-passive multipath or degraded RAID, for example).
It was initially reported at:
https://bugzilla.opensuse.org/show_bug.cgi?id=872929
On s390x and ppc64, the permissions of the /dev/kvm device are currently
not right as long as the kvm kernel module has not been loaded yet. The
kernel module is using MODULE_ALIAS("devname:kvm") there, so the module
will be loaded on the first access to /dev/kvm. In that case, udev needs
to apply the permission to the static node already (which was created via
devtmpfs), i.e. we have to specify the option "static_node=kvm" in the
udev rule.
Note that on x86, the kvm kernel modules are loaded early instead (via the
MODULE_DEVICE_TABLE(x86cpu, ...) feature checking), so that the right module
is loaded for the Intel or AMD hypervisor extensions right from the start.
Thus the "static_node=kvm" is not required on x86 - but it also should not
hurt here (and using it here even might be more future proof in case the
module loading is also done delayed there one day), so we just add the new
option to the rule here unconditionally.
So far I avoided adding license headers to meson files, but they are pretty
big and important and should carry license headers like everything else.
I added my own copyright, even though other people modified those files too.
But this is mostly symbolic, so I hope that's OK.
Commit 83b48159 set ID_BUS for these subsystems but copied the intent
of commit c49df207 by not creating symlinks for those devices.
Remove the GOTO so that the rest of the rules are still processed and
symlinks are created for rmi and i8042 devices.
- Remove the uaccess tag from /dev/dri/renderD*.
- Change the owning group from video to render.
- Change default mode to 0666.
- Add an option to allow users to set the access mode for these devices at
compile time.
Freescale IMX SoCs serial ports driven by kernel "imx-uart" driver have
names of "ttymxcN", let's add this pattern to an udev rule for serial
ports so they will have proper ownership applied.
The input_id builtin assigns the various ID_INPUT based on the exported evdev
bits. In some cases, the device may not have the properties required to label
a device as one specific type but the physical form factor is clear.
e.g. in the case of #7197 it's a tablet pad that does not have x/y axes which
the kernel exports for pads for historical reasons.
A custom override is needed, best to be solved with a hwdb entry.
Related #7197
To mimic MODEL_ID variable built for ATA and SCSI devices, add rules
to add MODEL_ID variable for NVMe devices.
TEST: Check on a system with NVMe device that MODEL_ID variable is
present:
udevadm info --query=all -n /dev/nvme0n1p1 | grep ID_MODEL
and
udevadm info --query=all -n /dev/nvme0n1p1 | grep ID_MODEL
return:
E: ID_MODEL=SAMSUNG...
Commit 0e8856d2 (assemble multidevice btrfs volumes without external
tools (#6607)) introduced a call to udevadm. That lives in @rootbindir@,
not @rootlibexecdir@. So fix the path.
Previously we were loading kernel modules on all device events save
for "remove". With the introduction of KOBJ_BIND/KOBJ_UNBIND this causes
issues, as driver modules that have devices bound to their drivers get
immediately reloaded, and it appears to the user that module unloading
does not work.
Let's change the rules to only load modules on "add" events instead.
assemble multidevice btrfs volumes without external tools
This self-contained approach introduce very little overhead, unless
someone has a large number of devices composing many btrfs volumes,
in which case btrfs device scan would be faster. Still, having robust
implementation is a nice to have alternative for btrfs-progs.
This places the input_id call after the evdev hwdb calls. With this the
hwdb fixups in evdev can affect the device capabilities assigned in
input_id.
Remove the ID_INPUT_KEY dependency in atkbd rule because it is now not
assigned at this point.
When the joystick is integrated directly into the machine, knowing
that the device is internal allows us to disable attached functionality
when the device is not used or inaccessible.
For example, this allows disabling rumble and accelerometer on
flip-console-like devices like the GPD-XD.
Formatting sd-cards does not trigger "change" uevents. As a result clients
using udev API don't get any updates afterwards and get outdated information
about the device.
Include mmcblk* in a match for watch option assignment.
Many eMMC devices have separate boot partitions that aren't part of the
normal partition table that show up as /dev/mmcblk[0-9]boot[0-9]. These
partitions are generally small (128KB to 16MB) and typically hold a boot
loader, boot loader data or a recovery image. Match these and create
-boot%n by-path symlinks.
Prior to this change by-path symlinks for the main device would be
incorrectly linked to one of the boot partitions.
For instance before:
/dev/disk/by-path/platform-219c000.usdhc linked to /dev/mmcblk1boot1
Now:
/dev/disk/by-path/platform-219c000.usdhc links to /dev/mmcblk1
/dev/disk/by-path/platform-219c000.usdhc-boot0 links to /dev/mmcblk1boot0
/dev/disk/by-path/platform-219c000.usdhc-boot1 links to /dev/mmcblk1boot1
On systems that support multiple SD/MMC devices it can be essential to
have by-path links to these devices since device names vary depending on
which other devices are connected.
