summaryrefslogtreecommitdiff
path: root/src/oom/oomctl.c
Commit message (Collapse)AuthorAgeFilesLines
* tree-wide: use -EBADF for fd initializationZbigniew Jędrzejewski-Szmek2022-12-191-1/+1
| | | | | | | | | | | | | | | | -1 was used everywhere, but -EBADF or -EBADFD started being used in various places. Let's make things consistent in the new style. Note that there are two candidates: EBADF 9 Bad file descriptor EBADFD 77 File descriptor in bad state Since we're initializating the fd, we're just assigning a value that means "no fd yet", so it's just a bad file descriptor, and the first errno fits better. If instead we had a valid file descriptor that became invalid because of some operation or state change, the other errno would fit better. In some places, initialization is dropped if unnecessary.
* basic: move version() to build.h+cZbigniew Jędrzejewski-Szmek2022-11-081-0/+1
|
* Make pager_open() return voidZbigniew Jędrzejewski-Szmek2021-11-031-2/+2
|
* Drop the text argument from assert_not_reached()Zbigniew Jędrzejewski-Szmek2021-08-031-1/+1
| | | | | | | | | | | | | | | | | 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.
* tree-wide: use UINT64_MAX or friendsYu Watanabe2021-03-051-1/+1
|
* tree-wide: Drop custom formatting for print() help messagesDaan De Meyer2021-01-311-6/+7
| | | | | | | | | | | | 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
* license: LGPL-2.1+ -> LGPL-2.1-or-laterYu Watanabe2020-11-091-1/+1
|
* systemd-oomd: dbus hook ups and oomctl CLIAnita Zhang2020-10-071-0/+138