Linux can be run on a device meant to act as a USB peripheral. In order
for a machine to act as such a USB device it has to be equipped with
a UDC - USB Device Controller.
This patch adds a target reached when UDC becomes available. It can be used
for activating e.g. a service unit which composes a USB gadget with
configfs and activates it.
LUKS2 header supports to device label and blkid since 2.32 version
already supports this option.
Persistent udev storage rules should create symlink for this label.
For older devices this value is not set so changed rule should be compatible.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
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.
Tape and tape changer devices from Amazon Webservice Storage Gateway VTLs
and maybe other iSCSI VTLs all have the same ENV{ID_SERIAL}.
The results is, that only the last device is available in
/dev/tape/by-id/, as the former devices have been overwritten.
However, the devices can be distinguished by ENV{ID_SCSI_SERIAL}.
ENV{ID_SCSI_SERIAL} is not set on directly connected SCSI devices.
This rule additional creates links based on the ENV{ID_SCSI_SERIAL}, if
it is set.
In my case, it creates (ID_SCSI_SERIAL)
/dev/tape/by-id/scsi-AMZN_SGW-6BF81D02_MC_00001
/dev/tape/by-id/scsi-AMZN_SGW-6BF81D02_TD_00001
/dev/tape/by-id/scsi-AMZN_SGW-6BF81D02_TD_00002
...
instead of only (ID_SERIAL)
scsi-2414d5a4e5f5347572d364246
It is important to be able to access tape changer ("Medium Changers") by
persistant name.
While tape devices can be accessed via /dev/tape/by-id/ and
/dev/tape/by-path/, tape-changers could only be accessed by
/dev/tape/by-id/.
However, in some cases, especially when accessing Amazon Webservice
Storage Gateway VTLs (or accessing iSCSI VTLs in general?) this does not
work, as all tape devices and the tape changer have the same ENV{ID_SERIAL}.
The results is, that only the last device is available in
/dev/tape/by-id/, as the former devices have been overwritten.
As this behavior is hard to change without breaking consistentcy,
this additional device in /dev/tape/by-path/ can be used to access the medium changes.
The tape devices can also be accessed by this path.
The content of the directory will now look like:
# SCSI tape device, rewind (unchanged)
/dev/tape/by-path/$env{ID_PATH} -> ../../st*
# SCSI tape device, no-rewind (unchanged)
/dev/tape/by-path/$env{ID_PATH}-nst -> ../../nst*
# SCSI tape changer device (newly added)
/dev/tape/by-path/$env{ID_PATH}-changer -> ../../sg*
Tape devices and tape changer have different ID_PATHs.
SCSI tape changer get the suffix "-changer"
to make them better distinguishable from tape devices.
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...
