| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Follow-up for e0504dd011189d97a1ea813aabfe1e696742bcf5.
Hopefully, devices in PCI subsystem have some properties, thus have
their udev database file. But, that may not be true. Here, we only read
sysattrs of enumerated devices, hence it is not necessary to check if
the device is initialized or not.
|
|
|
|
|
|
|
| |
That's not gramatically correct.
In backlight, change "assocation" to "deduplication". Without the context,
it's probably not clear at all that we "associate" them to ignore them.
|
|
|
|
| |
Closes #30507.
|
|\
| |
| | |
device-util: introduce device_in_subsystem() and device_is_devtype() helper functions
|
| | |
|
| |
| |
| |
| | |
No functional change, just refactoring.
|
| |
| |
| |
| | |
No functional change, just refactoring.
|
| |
| |
| |
| | |
No functional change, just refactoring.
|
| |
| |
| |
| |
| |
| |
| | |
While at it, this replaces strndupa_safe() with strndup(), as the input
is a user-controlled string.
No functional change, just refactoring.
|
| |
| |
| |
| | |
No functional change, just refactoring.
|
|/
|
|
|
| |
Also rename get_max_brightness() -> read_max_brightness() for
consistency with read_brightness().
|
|
|
|
| |
Closes #29328.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
util.h is now about logarithms only, so we can rename it. Many files included
util.h for no apparent reason… Those includes are dropped.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a system has multiple graphics cards, then we cannot associate
platform backlight devices to backlight devices under PCI bus.
Previously, in such case, vaidate_device() for a raw backlight device
might erroneously detect a platform device and return false. So, users
could not save/load backlight level.
This makes validate_device() give up to associate platform devices on
non-PCI bus with raw backlight devices. That may cause unwanted
backlight level save or restore by systemd-backlight@.service, but users
can workaround that by masking specific instances of the service.
Closes #24223.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #21997.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's define two helpers strdupa_safe() + strndupa_safe() which do the
same as their non-safe counterparts, except that they abort if called
with allocations larger than ALLOCA_MAX.
This should ensure that all our alloca() based allocations are subject
to this limit.
afaics glibc offers three alloca() based APIs: alloca() itself,
strndupa() + strdupa(). With this we have now replacements for all of
them, that take the limit into account.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
|
|
|
|
|
|
|
| |
The old code was just fine, but gcc doesn't understand that max_brightness is
initialized. Let's rework it a bit to move some logic to the main function. Now
get_max_brightness() just retrieves and parses the attribute, and the main
function decides what to do with it.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
It may be useful when debugging daemons.
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think this formatting was originally used because it simplified
adding new options to the help messages. However, these days, most
tools their help message end with "\nSee the %s for details.\n" so
the final line almost never has to be edited which eliminates the
benefit of the custom formatting used for printf() help messages.
Let's make things more consistent and use the same formatting for
printf() help messages that we use everywhere else.
Prompted by https://github.com/systemd/systemd/pull/18355#discussion_r567241580
|
|
|
|
| |
This may help to investigate issues.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If actual_brightness is larger than max_brightness, then fall back to
use brightness attribute.
Also, if the saved value is invalid, then this makes remove the file in
/var/lib/systemd/backlight.
Hopefully fixes #17011.
|
| |
|
| |
|
|
|
|
| |
Closes #16302.
|
| |
|
| |
|
|
|
|
|
| |
It's just a small function, but it is higher-level functionality.
I don't see a good place for it, reboot-util.[ch] seems least bad
|
|
|
|
|
|
| |
Let's be helpful to static analyzers which care about whether we
knowingly ignore return values. We do in these cases, since they are
usually part of error paths.
|
|
|
|
|
| |
This means we need to include many more headers in various files that simply
included util.h before, but it seems cleaner to do it this way.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I had accidentally filled my /var partition. This caused backlight to fail to
start even with disk space, because the brightness files were truncated to zero
size:
systemd-backlight[624]: acpi_video0: Failed to parse brightness "": Invalid argument
systemd-backlight[624]: acpi_video0: Failed to write system 'brightness' attribute: No such device or address
systemd[1]: systemd-backlight@backlight:acpi_video0.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: systemd-backlight@backlight:acpi_video0.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Load/Save Screen Backlight Brightness of backlight:acpi_video0.
Handle a truncated file like non-existent file.
|
| |
|
| |
|
|
|
|
|
| |
Let's reduce the common boilerplate and have a single setup function
used by all service code to setup logging.
|
|
|
|
|
|
|
|
|
|
|
| |
All users of the macro (except for one, in serialize.c), use the macro in
connection with read_line(), so they must include fileio.h. Let's not play
libc games and require multiple header file to be included for the most common
use of a function.
The removal of def.h includes is not exact. I mostly went over the commits that
switch over to use read_line() and add def.h at the same time and reverted the
addition of def.h in those files.
|
| |
|
| |
|