Quoting Documentation/driver-api/vfio.rst in Linux:
> note that /dev/vfio/vfio provides no capabilities on its own and is therefore
> expected to be set to mode 0666 by the system
The ID_FFADO environment variable comes from external FFADO project.
Now we have comprehensive and self-contained rules instead of it.
Let's remove it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In IEC 61883-1:1998, we can see some values for AV/C device with vendor
unique command set in IEC 61883-1:1998. Current udev rule handles it
for video. However it brings an issue that the functions in AV/C device
are not distinguished just by the content of configuration ROM.
In former commit, hardware database was added to describe function type
of unit in the node, then udev rules are added to utilize the database.
However, we have an request to obsolete existent udev rules by putting
enough entries to the database. It should be done carefully.
This commit adds entry into hardware database just for backward
compatibility. The entry can match to some node and unit unexpectedly.
Therefore this commit modifies existent entries to invalidate the effect
from added entry.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Typical node of AV/C device has standard content of configuration ROM.
This is defined in documentation of 1394 Trading Association.
* Configuration ROM for AV/C Devices 1.0 (Dec. 12, 2000, 1394 Trading
Association, TA Document 1999027)
However, it brings an issue that the functions in AV/C device are not
distinguished just by the content of configuration ROM.
In former commit, hardware database was added to describe function type
of unit in the node, then udev rules are added to utilize the database.
However, we have an request to obsolete existent udev rules by putting
enough entries to the database. It should be done carefully.
This commit adds entry into hardware database just for backward
compatibility. The entry can match to some node and unit unexpectedly.
Therefore this commit modifies existent entries to invalidate the effect
from added entry.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
IIDC specification describes configuration ROM without model field, thus
it's not possible to match any entry with vendor ID and model ID.
Current entry for Cool Stream iSweet can match any node and unit of
IIDC.
This commit removes the entry. I note that this model uses Texus
Instruments MC680-DCC as all-in-one chipset for video function in
IEEE 1394 bus.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Point Grey Research, inc. shipped cameras to support IIDC, however some
of them are necessarily compliant to IIDC specification in terms of the
value of software version field in unit directory of configuration ROM.
This commit adds entries for them.
Reviewed-by: Damien Douxchamps <damien@douxchamps.net>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Instrumentation & Industrial Digital Camera (IIDC) specifications are
defined by 1394 Trading Association for camera device in IEEE 1394 bus.
IIDC2 specifications are defined by joint working group between Japan
Industrial Imaging Association (JIIA) and 1394 Trade Association as
bus-independent specification.
This commit adds entries for the specifications to remove existent udev
rules. Supported specifications are listed below:
* 1394-based Digital Camera Specification Version 1.04 (Aug. 9, 1996,
1394 Trading Association)
* 1394-based Digital Camera Specification Version 1.20 (Jul. 23, 1998,
1394 Trading Association)
* IIDC Digital Camera Control Specification Ver.1.30 (Jul. 25, 2000,
1394 Trading Association)
* IIDC Digital Camera Control Specification Ver.1.31 (Feb. 2, 2004,
1394 Trading Association, TA Document 2003017)
* IIDC Digital Camera Control Specification Ver.1.32 (Jul. 24, 2008,
1394 Trading Association, Document number 2007009)
* IIDC2 Digital Camera Control Specification Ver.1.0.0 (Jan 26th, 2012,
1394 Trading Association, TS2011001)
* IIDC2 Digital Camera Control Specification Ver.1.1.0 (May 19th, 2015,
1394 Trading Association, TS2015001)
Reviewed-by: Damien Douxchamps <damien@douxchamps.net>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Linux kernel has firedtv kernel module as driver for Digital Everywhere
FloppyDTV and FireDTV. Although this driver works without any help of
userspace application, it's better to add entries to hardware database
for developer's convenience.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Zbigniew Jędrzejewski-Szmek points that current entries are against the
convention of indentation. It should be indented by one space instead of
two.
This commit fixes current entries according to it.
Reported-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Fixes: 1b6d9a05b1 ("hwdb: add database entries for models with ASICs in BeBoB solution")
Fixes: 0db0564e95 ("hwdb: add database entries for models with Fireworks board module")
Fixes: 38338b302c ("hwdb: add database entries for models with OXFW970/971 ASICs")
Fixes: c0d8b61f93 ("hwdb: add database entries for models based on DICE ASICs with TCAT specification")
Fixes: a774b5099b ("hwdb: add database entries for models based on DICE ASICs specialized to M-Audio")
Fixes: ff1cb7b939 ("hwdb: add database entries for models based on DICE ASICs specialized to Weiss Engineering")
Fixes: 6f44dddbe2 ("hwdb: add database entries for models based on DICE ASICs specialized by Loud Technologies")
Fixes: 49ed0aad52 ("hwdb: add database entries for models based on DICE ASICs specialized by Harman Music Group")
Fixes: effbb4024b ("hwdb: add database entries for models based on DICE ASICs specialized by Solid State Logic")
Fixes: 4aaa093b5f ("hwdb: add database entries for models of Digidesign Digi 00x family")
Fixes: c489e7f9d3 ("hwdb: add database entries for Tascam FireWire series")
Fixes: 650b8967a5 ("hwdb: add database entries for MOTU FireWire series")
Fixes: 51e9242b9b ("hwdb: add database entries for RME Fireface series")
Fixes: a90a6a9ae9 ("hwdb: add database entries for Yamaha mLAN 2nd generation")
Fixes: 41f2d0d393 ("hwdb: add database entries for Yamaha mLAN 3rd generation")
Fixes: 1d2ee96292 ("hwdb: add database entries for Focusrite Liquid Mix series")
Fixes: 0c20543835 ("hwdb: add database entries for TC Electronic PowerCore FireWire series")
Fixes: 8b4b76dc50 ("hwdb: add database entry for node with single unit with video function")
Fixes: 12dd2404be ("hwdb: add database entries for node with multiple units")
Fixes: dece0357e1 ("hwdb: add database entries for node with single unit for multiple functions")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
When given no arguments, hwdb parser script seeks test target files by
glob pattern. Although I added a new file for IEEE 1394 unit functions,
the file is excluded as test target due to the pattern.
This commit fixes it.
Fixes: 7713f3fc6a ("hwdb: add parser grammar for IEEE 1394 unit function list")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
"systemd-testsuite" gets in the way when grepping for "testsuite-*.sh".
Also, the name doesn't matter for anything, so let's just use something
very short to save space.
Today this is v248 with 938bdfc0fa, which,
if you don't know about the github webflow key fails to configure with
meson.build:724:8: ERROR: String "gpg: Signature made Tue 30 Mar 2021 22:59:02 CEST\ngpg: using RSA key 4AEE18F83AFDEB23\ngpg: Can't check signature: No public key\n1617137942\n" cannot be converted to int
or, if you do, with
meson.build:724:8: ERROR: String 'gpg: Signature made Tue 30 Mar 2021 22:59:02 CEST\ngpg: using RSA key 4AEE18F83AFDEB23\ngpg: Good signature from "GitHub (web-flow commit signing) <noreply@github.com>" [unknown]\ngpg: WARNING: This key is not certified with a trusted signature!\ngpg: There is no indication that the signature belongs to the owner.\nPrimary key fingerprint: 5DE3 E050 9C47 EA3C F04A 42D3 4AEE 18F8 3AFD EB23\n1617137942\n' cannot be converted to int
We had the following scenario:
under /etc/systemd/system/
- foo@.service
- bar@tty12.service → foo@tty12.service
- multi-user.target.wants/foo@tty12.service
Existing code did not "know" that foo@tty12.service has alias bar@tty12.service:
$ systemctl show -P Names foo@tty12.service
foo@tty12.service
Since multi-user.target is always loaded, we would load foo@tty12.service.
When trying to load bar@tty12.service, it would (correctly) detect that
bar@tty12.service is an alias for foo@tty12.service, and try to merge the
bar@tty12.service unit into the foo@tty12.service. This would fail, because
foo@tty12.service was already loaded, and only about-to-be-loaded units can
be merged.
With the patch we consider bar@tty12.service an alias of foo@tty12.service
immediately, so the issue does not occur:
$ systemctl show -P Names foo@tty12.service
foo@tty12.service bar@tty12.service
Fixes#19409.
This turned in a bigger rewrite. The logic add "the main name and all aliases"
was implemented twice, slightly different in both cases. I split that part out
to a new function. The result about the same length, but hopefully a bit easier
to read.
Logging output is also improved a bit. Some left-over debug logs have been
removed or cleaned up.
This is a fairly big change, but (with the addition in the following commit),
we have pretty good coverage of this logic.
New glibc deprecated mallocinfo(), even newer glibc added mallocinfo2()
as replacement. Use it, if it exists.
Follow-up for 4b6f74f5a0 and related
commits.
We would try to return a value that could be nonzero only if the kernel
reported writing more bytes than we gave to it, hopefully a rare occurence.
Instead, assert that this doesn't happen.
Instead, return true if we got to the end of the iovec array. The caller
can use this information to know that the whole iovec array was written.
This allows one loop to be dropped in write_to_syslog().
Also drop _unlikely_: this function is called with very short arrays, and
it *is* likely that we trigger this condition. Let's just let the compiler
generate normal code without giving it a potentially false hint.
$ SYSTEMD_LOG_LEVEL=debug build/systemd --test --user
...
Failed to lookup RuntimeDirectory path: No such device or address <---- this line is new
Failed to allocate manager object: No such device or address
We would fail and only say "Failed to allocate manager object: ENODEV" which is
not entirely self-explanatory. Let's add a better log message.
When editing this function in 7bf20e48bd, I couldn't
decide whether to initialize ret at the top and only reset it on success, or
whether to assign a value in each branch. In the end I did neither ;( So if the
test finished without creating any of the result files, we would echo a
message, but return "success".
But there was bigger confusion with /failed: some tests create it empty, some
don't. I think we may want to do away pre-creation of /failed completely, and
assume the test failed unless /testok is found. But I'm leaving that for later
rework. For now let's just make sure we report return success only if /testok
or /skipped is found.
This commit applies the filtering imposed by LogLevelMax on a unit's
processes to messages logged by PID1 about the unit as well.
The target use case for this feature is a service that runs on a timer
many times an hour, where the system administrator decides that writing
a generic success message to the journal every few minutes or seconds
adds no diagnostic value and isn't worth the clutter or disk I/O.
This reverts commit 7c20dd4b6e.
Debian has now been updated to patch the issue, so SemaphoreCI should
no longer fail. The fix has also been backported to the affected
stable branches.
Yu Watanabe
Frantisek Sumsal
Luca Boccassi
Alyssa Ross
Takashi Sakamoto
наб
Zbigniew Jędrzejewski-Szmek
Hans de Goede
Lennart Poettering
imayoda
Jakub Warczarek
Ryan Hendrickson
Luca Adrian LandLuca Lindhorst
Luca Boccassi