When resolving /dev/console one would often get "tty0" meaning the active VT.
Resolving to the actual tty (e.g. "tty1") will notably help on boot when
determining whether or not PID1 can output to the console.
Instead of individually checking for containers in each user do this
once in a new call proc_cmdline() that read the file only if we are not
in a container.
This introduces a new key NamePolicy, which takes an ordered list of naming
policies. The first successful one is applide. If all fail the value of Name
(if any) is used.
The possible policies are 'onboard', 'slot', 'path' and 'mac'.
This patch introduces a default link file, which replaces the equivalent udev
rule.
When set to 0 this will stop tools like the backlight and rfkill tools to
restore state from previous boot. This is useful in case the stored state
is bogus to the extent that it is preventing you from resetting it (e.g.,
the backlight settings cause the screen to be off on boot on a system where
the backlight can not be adjusted directly from the keyboard).
glob_extend() would completely fail to work, or return incorrect
data if it wasn't being passed the current getopt "optarg" variable
as it used the global variable, instead of the passed parameters.
rename old versions to ascii_*
Do not take into account zerowidth characters, but do consider double-wide characters.
Import needed utf8 helper code from glib.
v3: rebase ontop of utf8 restructuring work
[zj: tweak the algorithm a bit, move new code to separate file]
We were already creating the file if it was missing, and this way
containers can reconfigure the file without running into problems.
This also makes resolv.conf handling more alike to handling of
/etc/localtime, which is also not a bind mount.
In the process, rename udev_encode_string which is poorly named for what
it does. It deals specifically with encoding names that udev creates and
has its own rules: utf8 is valid but some ascii is not (e.g. path
separators), and everything else is simply escaped. Rename it to
encode_devnode_name.
Condition that is checked is taken from upower:
active(anon) < free swap * 0.98
This is really stupid, because the kernel knows the situation better,
e.g. there could be two swap files, and then hibernation would be
impossible despite passing this check, or the kernel could start
supporting compressed swap and/or compressed hibernation images, and
then this this check would be too stringent. Nevertheless, until
we have something better, this should at least return a true negative
if there's no swap.
Logging of capabilities in the journal is changed to not strip leading
zeros. I consider this more readable anyway.
http://cgit.freedesktop.org/upower/tree/src/up-daemon.c#n613https://bugzilla.redhat.com/show_bug.cgi?id=1007059
So far, we would show up to 128 bytes from a message, simply
cutting of the rest. With multiline messages, it is quite common
for a message to be longer than that, and this model doesn't really
work anymore.
A new limit is added: up to 3 lines will be shown, unless --full is
used (c.f. first line below). The limit for bytes is extended to 300
bytes. An ellipsis will always be used, if some form of truncation
occurs. If the tail of the message is cut off, either because of
length or line limit, dots will be shown at the end of the last
line. If this last line is short, the dots will be simply appended. If
the last line is too long for that, it will be ellipsized with dots at
the very end.
Note that the limits are in bytes, not characters, and we suck at
outputting unicode strings (c.f. last three lines below).
Aug 11 10:46:21 fedora python[67]: test message
line
line...
Aug 11 10:50:47 fedora python[76]: test message word word word word word word word word word word word wor...
Aug 11 10:55:11 fedora python[83]: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
Aug 11 11:03:21 fedora python[90]: ąąąąąąąąąąąąąąąąąąąąąąąąąąąąąą...
Aug 11 11:03:53 fedora python[97]: aąąąąąąąąąąąąąąąąąąąąąąąąąąąąąą...
Aug 11 11:25:45 fedora python[121]: aąąąąąąąąąąąąąąąąąąąąąąąąąąąąąąąąąą�...
If you have a ASCII only terminal, there is no way to set the charmap to
ANSI_X3.4-1968, other than using LC_CTYPE=C.
We don't want to assume a UTF-8 capable terminal in this case and only
do so, if LANG, LC_ALL and LC_CTYPE are unset.
The kernel adds those when the file is deleted,
but we don't really care if the file is still there
or not. The downside is that if the filename ends
in ' (deleted)', this part of the filename will be
removed. Too bad.
A new config file /etc/systemd/sleep.conf is added.
It is parsed by systemd-sleep and logind. The strings written
to /sys/power/disk and /sys/power/state can be configured.
This allows people to use different modes of suspend on
systems with broken or special hardware.
Configuration is shared between systemd-sleep and logind
to enable logind to answer the question "can the system be
put to sleep" as correctly as possible without actually
invoking the action. If the user configured systemd-sleep
to only use 'freeze', but current kernel does not support it,
logind will properly report that the system cannot be put
to sleep.
https://bugs.freedesktop.org/show_bug.cgi?id=57793https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=7e73c5ae6e7991a6c01f6d096ff8afaef4458c36http://lists.freedesktop.org/archives/systemd-devel/2013-February/009238.html
SYSTEM_CONFIG_FILE and USER_CONFIG_FILE defines were removed
since they were used in only a few places and with the
addition of /etc/systemd/sleep.conf it becomes easier to just
append the name of each file to the dir name.
I'm assuming that it's fine if a _const_ or _pure_ function
calls assert. It is assumed that the assert won't trigger,
and even if it does, it can only trigger on the first call
with a given set of parameters, and we don't care if the
compiler moves the order of calls.
This reverts commit 4826f0b7b5.
Because statfs.t_type can be int on some architecures, we have to cast
the const magic to the type, otherwise the compiler warns about
signed/unsigned comparison, because the magic can be 32 bit unsigned.
statfs(2) man page is also wrong on some systems, because
f_type is not __SWORD_TYPE on some architecures.
The following program:
int main(int argc, char**argv)
{
struct statfs s;
statfs(argv[1], &s);
printf("sizeof(f_type) = %d\n", sizeof(s.f_type));
printf("sizeof(__SWORD_TYPE) = %d\n", sizeof(__SWORD_TYPE));
printf("sizeof(long) = %d\n", sizeof(long));
printf("sizeof(int) = %d\n", sizeof(int));
if (sizeof(s.f_type) == sizeof(int)) {
printf("f_type = 0x%x\n", s.f_type);
} else {
printf("f_type = 0x%lx\n", s.f_type);
}
return 0;
}
executed on s390x gives for a btrfs:
sizeof(f_type) = 4
sizeof(__SWORD_TYPE) = 8
sizeof(long) = 8
sizeof(int) = 4
f_type = 0x9123683e
This reverts commit a858b64ddd.
This reverts commit aea275c431.
This reverts commit fc6e6d245e.
This reverts commit c4073a27c5.
This reverts commit cddf148028.
This reverts commit 8c68a70170.
The constants are now casted to __SWORD_TYPE, which should resolve the
compiler warnings about signed vs unsigned.
After talking to Kay, we concluded:
This should be fixed in the kernel, not worked around in userspace tools.
Architectures cannot use int and expect magic constants lager than INT_MAX
to work correctly. The kernel header needs to be fixed.
Even coreutils cannot handle it:
#define RAMFS_MAGIC 0x858458f6
# stat -f -c%t /
ffffffff858458f6
#define BTRFS_SUPER_MAGIC 0x9123683E
# stat -f -c%t /mnt
ffffffff9123683e
Although I found the perfect working macro to fix the thing :)
__extension__ ({ \
bool _ret = false; \
switch(f) { case c: _ret=true; }; \
( _ret ); \
})
On some architectures (like s390x) the kernel has the type int for
f_type, but long in userspace.
Assigning the 32 bit magic constants from linux/magic.h to the 31 bit
signed f_type in the kernel, causes f_type to be negative for some
constants.
glibc extends the int to long for those architecures in 64 bit mode, so
the negative int becomes a negative long, which cannot be simply
compared to the original magic constant, because the compiler would
automatically cast the constant to long.
To workaround this issue, we also compare to the (int)MAGIC value in a
macro. Of course, we could do #ifdef with the architecure, but it has to
be maintained, and the magic constants are 32 bit anyway.
Someday, when the int is unsigned or long for all architectures, we can
remove this macro again. Until then, keep it as simple as it can be.
Instead of making a type up, just use __SWORD_TYPE, after reading
statfs(2).
Too bad, this does not fix s390x because __SWORD_TYPE is (long int) and
the kernel uses (int) to fill in the field!!!!!!
