summaryrefslogtreecommitdiffstats
path: root/src/shared (follow)
Commit message (Collapse)AuthorAgeFilesLines
* json: don't assert() if we add a NULL element via json_variant_set_field()Lennart Poettering2021-11-251-1/+0
| | | | | | The rest of our JSON code tries hard to magically convert NULL inputs into "null" JSON objects, let's make sure this also works with json_variant_set_field().
* repart,homed: split out disk cleanup macros into generic headerLennart Poettering2021-11-252-0/+16
|
* Merge pull request #21503 from poettering/ioprio-fixYu Watanabe2021-11-251-0/+1
|\ | | | | work around linux 5.15 ioprio API breakage
| * shared: split out ioprio related stuff into ioprio-util.[ch]Lennart Poettering2021-11-241-0/+1
| | | | | | | | No actual code changes, just some splitting out.
* | build: fix build without seccompDominique Martinet2021-11-251-0/+10
| | | | | | | | | | | | | | | | | | | | - execute.c: bpf functions were in the middle of an #if HAVE_SECCOMP block for no reason - test-fd-util.c: make seccomp-util.h includable without depending on <seccomp.h>, and make is_seccomp_available() hardcoded to returning false in this case. Also fix a stray DEFINED() -- HAVE_SECCOMP is defined as 0, so normal #if should be used like everywhere else.
* | dissect-image: always say "file of image" when reporting about the imageZbigniew Jędrzejewski-Szmek2021-11-241-8/+8
| | | | | | | | | | | | We give a path, but the path is only meaningful inside of the image. Some messages made it clear that it's a path in the image, let's make them all do that.
* | dissect-image: provide a more useful message when ENOMEDIUM is returnedZbigniew Jędrzejewski-Szmek2021-11-241-7/+10
| |
* | dissect-image: do not enable "verification" when trying to acquire metadataZbigniew Jędrzejewski-Szmek2021-11-243-8/+9
| | | | | | | | | | | | | | | | | | The whole point of acquiring metadata is quite often to figure out why the image does not pass verification. Refusing to provide metadata is just being hostile to the user. When called from other places (e.g. image_read_metadata()), verification is still performed.
* | dissect-image: reuse common exit pathZbigniew Jędrzejewski-Szmek2021-11-241-4/+2
| |
* | shared/format-table: drop unnecessary _cleanup_Zbigniew Jędrzejewski-Szmek2021-11-241-13/+13
|/
* extension-release.d/: add a new field SYSEXT_SCOPE= for clarifying what a ↵Lennart Poettering2021-11-235-8/+34
| | | | | | | | | | | | | | | | system extension is for This should make things a bit more robust since it ensures system extension can only applied to the right environments. Right now three different "scopes" are defined: 1. "system" (for regular OS systems, after the initrd transition) 2. "initrd" (for sysext images that apply to the initrd environment) 3. "portable" (for sysext images that apply to portable images) If not specified we imply a default of "system portable", i.e. any image where the field is not specified is implicitly OK for application to OS images and for portable services – but not for initrds.
* dissect-image: when extracting metadata from image also check if it contains ↵Lennart Poettering2021-11-232-9/+67
| | | | | | init system It's good to know whether we can boot the image.
* pretty-print: add helper for quickly outputting red/green cross/check marksLennart Poettering2021-11-231-0/+23
| | | | Compound constructors FTW!
* Merge pull request #21479 from keszybz/cosmetic-initialization-adjustmentsLennart Poettering2021-11-231-1/+1
|\ | | | | Cosmetic initialization adjustments
| * shared/format-table: add cosmetic initializationZbigniew Jędrzejewski-Szmek2021-11-231-1/+1
| | | | | | | | | | p is unconditionally initialized below, but our coding style says that initialization should be added anyway.
* | Merge pull request #21443 from poettering/homed-grow-shrink-on-login-logoutLennart Poettering2021-11-233-0/+62
|\ \ | | | | | | homed: add ability to auto-grow home dir in login and auto-shrink on logout (if luks2+btrfs is used)
| * | user-record: add auto-resize propertyLennart Poettering2021-11-233-0/+62
| | |
* | | core/automount: Add ExtraOptions fieldAndrew Stone2021-11-231-1/+2
|/ /
* / resolved: add "proxy-only" stub on 127.0.0.54Lennart Poettering2021-11-222-3/+6
|/ | | | | | | | | | | | | | | | | | | | This beefs up the DNS stub logic to listen on two IP addresses: 127.0.0.53 (as before) + 127.0.0.54 (new). When the latter is contact our stub will operate in "bypass" mode only, i.e we'll try to pass DNS requests as unmodified upstream as we can (and not do mDNS/LLMNR and such, also no DNSSEC validation – but we'll still do DNS-over-TLS wrapping). This is supposed to be useful for container environments or tethering: this stub could be exposed (via NAT redirect) to clients of this system and we'll try to stay out of the way with doing too much DNS magic ourselves, but still expose whatever the current DNS server is from upstream under a stable address/port. How to use this: # iptables -t nat -I PREROUTING -p udp -i <interface> --dport 53 -j DNAT --to 127.0.0.54:53 # echo 1 > /proc/sys/net/ipv4/conf/<interface>/route_localnet
* Merge pull request #21425 from keszybz/ppc64-fixesLennart Poettering2021-11-223-194/+315
|\ | | | | Add base-filesystem defines for arm64/ppc64el/riscv64 and make build quiet again
| * shared/base-filesystem: use LIB_ARCH_TUPLE instead of stringZbigniew Jędrzejewski-Szmek2021-11-191-5/+6
| |
| * shared/gpt: fix bit-flip in LoongArch root partition UUIDZbigniew Jędrzejewski-Szmek2021-11-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 4e767154891083069a58c5c960f386974ad87fb4 added a slightly different UUID in the header and in the docs. This makes the code match the docs. > As some downstream projects are already using the UUID as in the docs, most > notably util-linux [1], we should adjust code to match doc; no shipping > LoongArch systems are using upstream systemd, and no open-source distro is > merging LoongArch support yet, so the change should break no one. This also > matches the work being done by @yetist at loongarch64/systemd#7. [1] https://github.com/util-linux/util-linux/commit/2d29fccaad267d1b003dc0ed2bb9634ff76f3e49
| * docs: generate table from header using a scriptZbigniew Jędrzejewski-Szmek2021-11-191-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a helper script: $ python3 tools/list-discoverable-partitions.py <src/shared/gpt.h <!-- generated with tools/list-discoverable-partitions.py --> | Partition Type UUID | Name | Allowed File Systems | Explanation | |---------------------|------|----------------------|-------------| | _Root Partition (Alpha)_ | `6523f8ae-3eb1-4e2a-a05a-18b695ae656f` | [Root Partition] | [Root Partition more] | | _Root Partition (ARC)_ | `d27f46ed-2919-4cb8-bd25-9531f3c16534` | ditto | ditto | ... The output can be pasted into the markdown file. I think this works better than trying to match the two lists by hand.
| * shared/gpt: ARM_64 → ARM64Zbigniew Jędrzejewski-Szmek2021-11-192-14/+14
| | | | | | | | "arm64" is generally written without the underscore.
| * shared/gpt: add entries for a bunch of architecturesZbigniew Jędrzejewski-Szmek2021-11-192-2/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I don't think we want people to send us pull requests over the next two years. Let's just make something up ourselves, this is going to have at least as good results, and will be much quicker. Note that this only includes architectures for which there's some indication that they are in active use. In architecture.h there are some more esoteric ones like ARC_BE. We can add those if there's some actual user demand. In particular, I included everything on the Debian "List of official ports" [1] and a few other arches that we have received patches for in recent times. [1] https://www.debian.org/ports/#portlist-released
| * shared/gpt: add a macro to make the definitions a bit less onerousZbigniew Jędrzejewski-Szmek2021-11-191-109/+47
| |
| * shared/gpt: reorder arches alphabeticallyZbigniew Jędrzejewski-Szmek2021-11-192-76/+71
| | | | | | | | It's just too annoying to add new ones otherwise.
| * shared/base-filesystem: add define for s390xZbigniew Jędrzejewski-Szmek2021-11-191-0/+4
| | | | | | | | | | | | | | | | This is based on the information in #14311 and https://refspecs.linuxfoundation.org/LSB_3.2.0/LSB-Core-S390X/LSB-Core-S390X.pdf and https://wiki.debian.org/Multiarch/Tuples. Fixes #14311.
| * shared/base-filesystem: m68k is 32-bit onlyZbigniew Jędrzejewski-Szmek2021-11-191-0/+2
| |
| * shared/base-filesystem: add define for armZbigniew Jędrzejewski-Szmek2021-11-191-0/+2
| | | | | | | | | | | | | | | | $ ls -l /lib /lib64 ls: cannot access '/lib64': No such file or directory lrwxrwxrwx. 1 root root 7 Jan 26 2021 /lib -> usr/lib $ ldd /bin/sh|grep ld /lib/ld-linux-armhf.so.3 (0xb6f80000)
| * shared/base-filesystem: add define for riscv64Zbigniew Jędrzejewski-Szmek2021-11-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://wiki.debian.org/ArchitectureSpecificsMemo shows the triplet, but no the linker paths. I used the linker path from Fedora. $ ls -l /lib /lib64 lrwxrwxrwx. 1 root root 7 Aug 13 2020 /lib -> usr/lib lrwxrwxrwx. 1 root root 9 Aug 13 2020 /lib64 -> usr/lib64 $ ldd /bin/sh|grep ld /lib/ld-linux-riscv64-lp64d.so.1 (0x0000003fb8185000) $ ls -l /lib/ld-linux-riscv64-lp64d.so.1 lrwxrwxrwx 1 root root 19 Aug 4 19:28 /lib/ld-linux-riscv64-lp64d.so.1 -> ../lib64/ld-2.32.so $ uname -r 5.10.6+ So even though the canonical linker path uses /lib/, we need the /lib64 symlink to be present.
| * shared/base-filesystem: add define for ppc64elZbigniew Jędrzejewski-Szmek2021-11-191-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://wiki.debian.org/ArchitectureSpecificsMemo shows the triplet, but no the linker paths. I used the linker path from Fedora, but I can't look up the linker paths for BE and 32 bit. At least the ifdef scaffolding is provided, so it should be trivial to fill in if somebody has access to such a system. $ ls -l /lib /lib64 lrwxrwxrwx. 1 root root 7 Jan 26 2021 /lib -> usr/lib lrwxrwxrwx. 1 root root 9 Jan 26 2021 /lib64 -> usr/lib64 $ ldd /bin/sh|grep ld /lib64/ld64.so.2 (0x00007fffa0a90000) $ uname -r 5.14.9-200.fc34.ppc64le Note that the macro defines listed in the wiki page don't match what I get on Fedora: __PPC64__ vs. __ppc64__. $ cpp -dM < /dev/null |grep -iE '__(powerpc|ppc)'|sort #define __powerpc__ 1 #define __powerpc64__ 1 #define __PPC__ 1 #define __PPC64__ 1 First half of the fix for #14311.
| * shared/base-filesystem: add define for arm64Zbigniew Jędrzejewski-Szmek2021-11-191-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://wiki.debian.org/ArchitectureSpecificsMemo: > arm64 aarch64-linux-gnu 64 AARCH64 /lib/ld-linux-aarch64.so.1 aarch64 aarch64 Fedora: $ ls -l /lib /lib64 lrwxrwxrwx. 1 root root 7 Jul 27 2020 /lib -> usr/lib lrwxrwxrwx. 1 root root 9 Jul 27 2020 /lib64 -> usr/lib64 $ ldd /bin/sh|grep ld /lib/ld-linux-aarch64.so.1 (0x0000ffff8c905000) $ ls -l /lib/ld-linux-aarch64.so.1 /lib64/ld-2.32.so lrwxrwxrwx. 1 root root 19 Jul 13 07:28 /lib/ld-linux-aarch64.so.1 -> ../lib64/ld-2.32.so -rwxr-xr-x. 1 root root 961248 Jul 13 07:56 /lib64/ld-2.32.so $ uname -r 5.14.16-101.fc33.aarch64 So we need both /lib and /lib64 to be present, even though the canonical linker path uses /lib.
| * shared/base-filesystem: add (empty) iffdery for the tableZbigniew Jędrzejewski-Szmek2021-11-191-8/+29
| | | | | | | | | | | | I think this is going to be very annoying for our downstream maintainers. Let's at least provide the ifdef scaffolding so that only filling in the actual entries remains. The structure is copied from missing_syscall.h.
| * shared/gpt: drop outdated commentZbigniew Jędrzejewski-Szmek2021-11-191-4/+0
| | | | | | | | C.f. 1fb2d8fcb69bcdbab0a5dd23bbf02f729e47e656.
* | analyze: fix printing config when there is no main config fileZbigniew Jędrzejewski-Szmek2021-11-211-14/+29
|/ | | | | | | | | | | | | | | | | | Since 8b8024f1c231c166f5c450905c8fd91d11704ae7 and the follow-up commits, the main config file may be located in /usr or in other paths. But the code in analyze.c was still assuming that it must be in /etc. Things mostly worked for our own config files because we usually install a comments-only file in /etc, but was not correct in the general case. This fixes in particular 'systemd-analyze cat-config systemd/zram-generator.conf'. In Fedora we distribute a config file in zram-generator-defaults.rpm that is in /usr/lib, and 'cat-config' would refuse to show it because /etc/systemd/zram-generator.conf does not exist. The main config file is optional, but let's print an informative message because this is a slightly unusual case. The file paths that we printed were missing the root prefix.
* gpt: make gpt_partition_type_uuid_from_string() return parameter optionalLennart Poettering2021-11-191-2/+2
|
* systemd-coredump: allow setting external core size to infinityThomas Blume2021-11-192-0/+26
| | | | Make it compatible to the ulimit setting: unlimited
* Merge pull request #21424 from keszybz/json-doubleLuca Boccassi2021-11-184-101/+90
|\ | | | | Use double and int64_t types in json
| * shared/json: use int64_t instead of intmax_tZbigniew Jędrzejewski-Szmek2021-11-184-68/+60
| | | | | | | | | | | | | | | | | | | | | | We were already asserting that the intmax_t and uintmax_t types are the same as int64_t and uint64_t. Pretty much everywhere in the code base we use the latter types. In principle intmax_t could be something different on some new architecture, and then the code would fail to compile or behave differently. We actually do not want the code to behave differently on those architectures, because that'd break interoperability. So let's just use int64_t/uint64_t since that's what we indend to use.
| * shared/json: stop using long doubleZbigniew Jędrzejewski-Szmek2021-11-183-37/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems that the implementation of long double on ppc64el doesn't really work: long double cast to integer and back compares as unequal to itself. Strangely, this effect happens without optimization and both with gcc and clang, so it seems to be an effect of how long double is implemented by the architecture. Dumping the values shows the following pattern: 00 00 00 00 00 00 24 40 00 00 00 00 00 00 00 00 # long double v = 10; 00 00 00 00 00 00 24 40 00 00 00 00 00 00 80 39 # (long double)(intmax_t) v Instead of trying to make this work, I think it's most reasonable to switch to normal doubles. Notably, we had no tests for floating point behaviour. The first test we added (for values even not in the range outside of double), showed failures. Common implementations of JSON (in particular JavaScript) use 64 bit double. If we stick to this, users are likely to be happy when they exchange data with those tools. Exporting values that cannot be represented in other tools would just cause interop problems. I don't think the extra precision would be much used. Long double seems to make most sense as a transient format used in calculations to get extra precision in operations, and not a storage or exchange format. So I expect low-level numerical routines that have to know about hardware to make use of it, but it shouldn't be used by our (higher-level) system library. In particular, we would have to add tests for implementations conforming to IEEE 754, and those that don't conform, and account for various implementation differences. It just doesn't seem worth the effort. https://en.wikipedia.org/wiki/Long_double#Implementations shows that the situation is "complicated": > On the x86 architecture, most C compilers implement long double as the 80-bit > extended precision type supported by x86 hardware. An exception is Microsoft > Visual C++ for x86, which makes long double a synonym for double. The Intel > C++ compiler on Microsoft Windows supports extended precision, but requires > the /Qlong‑double switch for long double to correspond to the hardware's > extended precision format. > Compilers may also use long double for the IEEE 754 quadruple-precision > binary floating-point format (binary128). This is the case on HP-UX, > Solaris/SPARC, MIPS with the 64-bit or n32 ABI, 64-bit ARM (AArch64) (on > operating systems using the standard AAPCS calling conventions, such as > Linux), and z/OS with FLOAT(IEEE). Most implementations are in software, but > some processors have hardware support. > On some PowerPC and SPARCv9 machines, long double is implemented as a > double-double arithmetic, where a long double value is regarded as the exact > sum of two double-precision values, giving at least a 106-bit precision; with > such a format, the long double type does not conform to the IEEE > floating-point standard. Otherwise, long double is simply a synonym for > double (double precision), e.g. on 32-bit ARM, 64-bit ARM (AArch64) (on > Windows and macOS) and on 32-bit MIPS (old ABI, a.k.a. o32). > With the GNU C Compiler, long double is 80-bit extended precision on x86 > processors regardless of the physical storage used for the type (which can be > either 96 or 128 bits). On some other architectures, long double can be > double-double (e.g. on PowerPC) or 128-bit quadruple precision (e.g. on > SPARC). As of gcc 4.3, a quadruple precision is also supported on x86, but as > the nonstandard type __float128 rather than long double. > Although the x86 architecture, and specifically the x87 floating-point > instructions on x86, supports 80-bit extended-precision operations, it is > possible to configure the processor to automatically round operations to > double (or even single) precision. Conversely, in extended-precision mode, > extended precision may be used for intermediate compiler-generated > calculations even when the final results are stored at a lower precision > (i.e. FLT_EVAL_METHOD == 2). With gcc on Linux, 80-bit extended precision is > the default; on several BSD operating systems (FreeBSD and OpenBSD), > double-precision mode is the default, and long double operations are > effectively reduced to double precision. (NetBSD 7.0 and later, however, > defaults to 80-bit extended precision). However, it is possible to override > this within an individual program via the FLDCW "floating-point load > control-word" instruction. On x86_64, the BSDs default to 80-bit extended > precision. Microsoft Windows with Visual C++ also sets the processor in > double-precision mode by default, but this can again be overridden within an > individual program (e.g. by the _controlfp_s function in Visual C++). The > Intel C++ Compiler for x86, on the other hand, enables extended-precision > mode by default. On IA-32 OS X, long double is 80-bit extended precision. So, in short, the only thing that can be said is that nothing can be said. In common scenarios, we are getting only a bit of extra precision (80 bits instead of 64), but use space for padding. In other scenarios we are getting no extra precision. And the variance in implementations is a big issue: we can expect strange differences in behaviour between architectures, systems, compiler versions, compilation options, and even the other things that the program is doing. Fixes #21390.
* | tree-wide: port various places over to open_mkdir_at()Lennart Poettering2021-11-172-14/+6
| |
* | hwdb: voidify call to mkdir_parents_labelLuca Boccassi2021-11-171-1/+1
|/ | | | CID#1466060
* Merge pull request #21326 from poettering/mkdir-tweaksLennart Poettering2021-11-1619-72/+61
|\ | | | | various tweaks to mkdir code
| * shared: clean up mkdir.h/label.h situationLennart Poettering2021-11-1615-25/+32
| | | | | | | | | | | | | | | | | | | | Previously the mkdir_label() family of calls was implemented in src/shared/mkdir-label.c but its functions partly declared ins src/shared/label.h and partly in src/basic/mkdir.h (!!). That's weird (and wrong). Let's clean this up, and add a proper mkdir-label.h matching the .c file.
| * mkdir: drop mkdir_errno_wrapper(), use mkdirat_errno_wrapper() insteadLennart Poettering2021-11-161-3/+3
| | | | | | | | | | | | | | Let's reduce our code duplication, and let's focus on using xyzat() style APIs more, hence drop mkdir_errno_wrapper() and stick to mkdirar_errno_wrapper() wherever we can, it's a true superset of functionality after all.
| * tree-wide: don't use mkdir_errno_wrapper() without reasonLennart Poettering2021-11-161-1/+1
| | | | | | | | Simple mkdir() is fine, too, no need to use the wrapper
| * mkdir-label: make mkdir_label() a wrapper around mkdirat_label()Lennart Poettering2021-11-162-18/+6
| |
| * selinux: make mac_selinux_create_file_prepare() at wrapper around _at()Lennart Poettering2021-11-162-28/+15
| | | | | | | | | | | | Let's make sure mac_selinux_create_file_prepare_at() works fine with AT_FDCWD, and then make mac_selinux_create_file_prepare() just a inline wrapper around it.
| * smack make mac_smack_fix_at() useful when called with dir_fd=AT_FDCWDLennart Poettering2021-11-161-2/+9
| |
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-30 08:32:38 +0100