* [PATCH 0/2] Add options to enable building lsblk and dmesg
From: Henrik Lindström @ 2024-09-21 8:23 UTC (permalink / raw)
To: util-linux; +Cc: Henrik Lindström
When using --disable-all-programs, it was not possible to build lsblk or
dmesg since no configure arguments existed for enabling them.
Henrik Lindström (2):
lsblk: allow enabling with --disable-all-programs
dmesg: allow enabling with --disable-all-programs
configure.ac | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--
2.39.5
^ permalink raw reply
* [PATCH 1/2] lsblk: allow enabling with --disable-all-programs
From: Henrik Lindström @ 2024-09-21 8:23 UTC (permalink / raw)
To: util-linux; +Cc: Henrik Lindström
In-Reply-To: <20240921082310.232867-1-henrik@lxm.se>
Signed-off-by: Henrik Lindström <henrik@lxm.se>
---
configure.ac | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 0ca2ebcf7..838047720 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1835,7 +1835,11 @@ AC_CHECK_FUNCS([swapon])
AC_CHECK_FUNCS([swapoff])
-UL_BUILD_INIT([lsblk], [check])
+AC_ARG_ENABLE([lsblk],
+ AS_HELP_STRING([--disable-lsblk], [do not build lsblk]),
+ [], [UL_DEFAULT_ENABLE([lsblk], [check])]
+)
+UL_BUILD_INIT([lsblk])
UL_REQUIRES_LINUX([lsblk])
UL_REQUIRES_BUILD([lsblk], [libblkid])
UL_REQUIRES_BUILD([lsblk], [libmount])
--
2.39.5
^ permalink raw reply related
* [PATCH 2/2] dmesg: allow enabling with --disable-all-programs
From: Henrik Lindström @ 2024-09-21 8:23 UTC (permalink / raw)
To: util-linux; +Cc: Henrik Lindström
In-Reply-To: <20240921082310.232867-1-henrik@lxm.se>
Signed-off-by: Henrik Lindström <henrik@lxm.se>
---
configure.ac | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 838047720..8a788179d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2165,7 +2165,11 @@ UL_BUILD_INIT([readprofile], [check])
UL_REQUIRES_LINUX([readprofile])
AM_CONDITIONAL([BUILD_READPROFILE], [test "x$build_readprofile" = xyes])
-UL_BUILD_INIT([dmesg], [check])
+AC_ARG_ENABLE([dmesg],
+ AS_HELP_STRING([--disable-dmesg], [do not build dmesg]),
+ [], [UL_DEFAULT_ENABLE([dmesg], [check])]
+)
+UL_BUILD_INIT([dmesg])
UL_REQUIRES_LINUX([dmesg])
AM_CONDITIONAL([BUILD_DMESG], [test "x$build_dmesg" = xyes])
--
2.39.5
^ permalink raw reply related
* Re: [ptxdist] util-linux build error with meson and older glibc
From: Alexander Dahl @ 2024-09-10 11:01 UTC (permalink / raw)
To: Michael Olbrich; +Cc: util-linux, ptxdist
In-Reply-To: <ZuAYutgoVwik51tk@pengutronix.de>
Hello,
Am Tue, Sep 10, 2024 at 12:00:26PM +0200 schrieb Michael Olbrich:
> On Tue, Sep 10, 2024 at 09:07:01AM +0200, Alexander Dahl wrote:
> > Hello everyone,
> >
> > building util-linux with ptxdist [1] here. After switching to meson
> > build [2], compiling util-linux fails with OSELAS.Toolchain-2020.08.0
> > which contains gcc-10.2.1 and glibc-2.32. Building for architecture
> > arm-v5te-linux-gnueabi here, console output below.
> >
> > Autotools build was fine. Build with a more recent toolchain
> > (OSELAS.Toolchain-2023.07, gcc 13.2.1, glibc 2.37) is successful.
> >
> > From looking at the linker options I suspect -lutil missing?
> > According to manpage that's a BSD function present in glibc.
> > I suspect a change in glibc 2.34 integrating libutil in core glibc,
> > which makes it work with recent version 2.37. So this is probably a
> > flaw in meson build not setting the necessary linker options for glibc
> > up to 2.33? Could anyone point me how to fix this or does anyone by
> > chance already have a patch for this? (Disclaimer: I have zero
> > experience with meson.)
>
>
> There is a -Dlibutil=disabled in rules/util-linux.make. Maybe try to
> enable that?
This did it. Sent a patch already:
Link: https://lore.ptxdist.org/ptxdist/20240910105459.3468520-1-ada@thorsis.com/T/#u
Thanks and Greets
Alex
>
> Michael
>
> > % p -v -j1 compile util-linux
> >
> > --------------------------
> > target: util-linux.compile
> > --------------------------
> >
> > ptxdist: executing: PATH=/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-cross/usr/bin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-cross/usr/sbin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/lib/wrapper:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/bin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/sbin:/home/adahl/Work/bsp/thorsis/ncl/tmp/selected_toolchain:/usr/local/lib/ptxdist-2024.05.0/bin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/bin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/sbin:/home/adahl/Work/bsp/thorsis/ncl/tmp/selected_toolchain:/usr/local/lib/ptxdist-2024.04.0/bin:/home/adahl/bin:/home/adahl/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/games HTTPS_PROXY=PTXDIST-UNALLOWED-DOWNLOAD HTTP_PROXY=PTXDIST-UNALLOWED-DOWNLOAD https_proxy=PTXDIST-UNALLOWED-DOWNLOAD http_proxy=PTXDIST-UNALLOWED-DOWNLOAD PKGCONFIG_WHITELIST_HOST='' PKGCONFIG_WHITELIST_TARGET='' PKGCONFIG_WHITELIST_SRC='util-linux' SYSROOT='/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-target' V=1 VERBOSE=1 LC_ALL='C.utf8' KBUILD_BUILD_TIMESTAMP=2020-08-01T00:00:00+00:00 KBUILD_BUILD_USER=ptxdist KBUILD_BUILD_HOST=ptxdist ninja -C /home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/build-target/util-linux-2.40.2-build -v -j1
> >
> > ninja: Entering directory `/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/build-target/util-linux-2.40.2-build'
> > [1/75] arm-v5te-linux-gnueabi-gcc -o test_pty test_pty.p/lib_pty-session.c.o test_pty.p/lib_monotonic.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,--start-group lib/libcommon.a -lm -lrt -Wl,--end-group
> > FAILED: test_pty
> > arm-v5te-linux-gnueabi-gcc -o test_pty test_pty.p/lib_pty-session.c.o test_pty.p/lib_monotonic.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,--start-group lib/libcommon.a -lm -lrt -Wl,--end-group
> > /opt/OSELAS.Toolchain-2020.08.0/arm-v5te-linux-gnueabi/gcc-10.2.1-glibc-2.32-binutils-2.35-kernel-5.8-sanitized/lib/gcc/arm-v5te-linux-gnueabi/10.2.1/../../../../arm-v5te-linux-gnueabi/bin/ld: test_pty.p/lib_pty-session.c.o: in function `ul_pty_setup':
> > platform-ncl/build-target/util-linux-2.40.2-build/../util-linux-2.40.2/lib/pty-session.c:198: undefined reference to `openpty'
> > /opt/OSELAS.Toolchain-2020.08.0/arm-v5te-linux-gnueabi/gcc-10.2.1-glibc-2.32-binutils-2.35-kernel-5.8-sanitized/lib/gcc/arm-v5te-linux-gnueabi/10.2.1/../../../../arm-v5te-linux-gnueabi/bin/ld: platform-ncl/build-target/util-linux-2.40.2-build/../util-linux-2.40.2/lib/pty-session.c:188: undefined reference to `openpty'
> > collect2: error: ld returned 1 exit status
> > ninja: build stopped: subcommand failed.
> > make: *** [/usr/local/lib/ptxdist-2024.05.0/rules/post/ptxd_make_world_compile.make:20: /home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/state/util-linux.compile] Error 1
> >
> > Greets
> > Alex
> >
> > [1] https://www.ptxdist.org/
> > [2] https://git.pengutronix.de/cgit/ptxdist/commit/?id=18c9c0f89c4148f3007b9fcc7833d99af60084dc
> >
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
^ permalink raw reply
* Re: util-linux build error with meson and older glibc
From: Karel Zak @ 2024-09-10 10:45 UTC (permalink / raw)
To: util-linux, ptxdist
In-Reply-To: <13593969.uLZWGnKmhe@ada-pc>
On Tue, Sep 10, 2024 at 09:07:01AM GMT, Alexander Dahl wrote:
> building util-linux with ptxdist [1] here. After switching to meson
> build [2], compiling util-linux fails with OSELAS.Toolchain-2020.08.0
> which contains gcc-10.2.1 and glibc-2.32. Building for architecture
> arm-v5te-linux-gnueabi here, console output below.
Which version of util-linux are you currently using? Is it the current
git tree?
> From looking at the linker options I suspect -lutil missing?
It seems so.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [ptxdist] util-linux build error with meson and older glibc
From: Michael Olbrich @ 2024-09-10 10:00 UTC (permalink / raw)
To: util-linux, ptxdist
In-Reply-To: <13593969.uLZWGnKmhe@ada-pc>
On Tue, Sep 10, 2024 at 09:07:01AM +0200, Alexander Dahl wrote:
> Hello everyone,
>
> building util-linux with ptxdist [1] here. After switching to meson
> build [2], compiling util-linux fails with OSELAS.Toolchain-2020.08.0
> which contains gcc-10.2.1 and glibc-2.32. Building for architecture
> arm-v5te-linux-gnueabi here, console output below.
>
> Autotools build was fine. Build with a more recent toolchain
> (OSELAS.Toolchain-2023.07, gcc 13.2.1, glibc 2.37) is successful.
>
> From looking at the linker options I suspect -lutil missing?
> According to manpage that's a BSD function present in glibc.
> I suspect a change in glibc 2.34 integrating libutil in core glibc,
> which makes it work with recent version 2.37. So this is probably a
> flaw in meson build not setting the necessary linker options for glibc
> up to 2.33? Could anyone point me how to fix this or does anyone by
> chance already have a patch for this? (Disclaimer: I have zero
> experience with meson.)
There is a -Dlibutil=disabled in rules/util-linux.make. Maybe try to
enable that?
Michael
> % p -v -j1 compile util-linux
>
> --------------------------
> target: util-linux.compile
> --------------------------
>
> ptxdist: executing: PATH=/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-cross/usr/bin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-cross/usr/sbin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/lib/wrapper:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/bin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/sbin:/home/adahl/Work/bsp/thorsis/ncl/tmp/selected_toolchain:/usr/local/lib/ptxdist-2024.05.0/bin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/bin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/sbin:/home/adahl/Work/bsp/thorsis/ncl/tmp/selected_toolchain:/usr/local/lib/ptxdist-2024.04.0/bin:/home/adahl/bin:/home/adahl/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/games HTTPS_PROXY=PTXDIST-UNALLOWED-DOWNLOAD HTTP_PROXY=PTXDIST-UNALLOWED-DOWNLOAD https_proxy=PTXDIST-UNALLOWED-DOWNLOAD http_proxy=PTXDIST-UNALLOWED-DOWNLOAD PKGCONFIG_WHITELIST_HOST='' PKGCONFIG_WHITELIST_TARGET='' PKGCONFIG_WHITELIST_SRC='util-linux' SYSROOT='/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-target' V=1 VERBOSE=1 LC_ALL='C.utf8' KBUILD_BUILD_TIMESTAMP=2020-08-01T00:00:00+00:00 KBUILD_BUILD_USER=ptxdist KBUILD_BUILD_HOST=ptxdist ninja -C /home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/build-target/util-linux-2.40.2-build -v -j1
>
> ninja: Entering directory `/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/build-target/util-linux-2.40.2-build'
> [1/75] arm-v5te-linux-gnueabi-gcc -o test_pty test_pty.p/lib_pty-session.c.o test_pty.p/lib_monotonic.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,--start-group lib/libcommon.a -lm -lrt -Wl,--end-group
> FAILED: test_pty
> arm-v5te-linux-gnueabi-gcc -o test_pty test_pty.p/lib_pty-session.c.o test_pty.p/lib_monotonic.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,--start-group lib/libcommon.a -lm -lrt -Wl,--end-group
> /opt/OSELAS.Toolchain-2020.08.0/arm-v5te-linux-gnueabi/gcc-10.2.1-glibc-2.32-binutils-2.35-kernel-5.8-sanitized/lib/gcc/arm-v5te-linux-gnueabi/10.2.1/../../../../arm-v5te-linux-gnueabi/bin/ld: test_pty.p/lib_pty-session.c.o: in function `ul_pty_setup':
> platform-ncl/build-target/util-linux-2.40.2-build/../util-linux-2.40.2/lib/pty-session.c:198: undefined reference to `openpty'
> /opt/OSELAS.Toolchain-2020.08.0/arm-v5te-linux-gnueabi/gcc-10.2.1-glibc-2.32-binutils-2.35-kernel-5.8-sanitized/lib/gcc/arm-v5te-linux-gnueabi/10.2.1/../../../../arm-v5te-linux-gnueabi/bin/ld: platform-ncl/build-target/util-linux-2.40.2-build/../util-linux-2.40.2/lib/pty-session.c:188: undefined reference to `openpty'
> collect2: error: ld returned 1 exit status
> ninja: build stopped: subcommand failed.
> make: *** [/usr/local/lib/ptxdist-2024.05.0/rules/post/ptxd_make_world_compile.make:20: /home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/state/util-linux.compile] Error 1
>
> Greets
> Alex
>
> [1] https://www.ptxdist.org/
> [2] https://git.pengutronix.de/cgit/ptxdist/commit/?id=18c9c0f89c4148f3007b9fcc7833d99af60084dc
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* util-linux build error with meson and older glibc
From: Alexander Dahl @ 2024-09-10 7:07 UTC (permalink / raw)
To: util-linux, ptxdist
Hello everyone,
building util-linux with ptxdist [1] here. After switching to meson
build [2], compiling util-linux fails with OSELAS.Toolchain-2020.08.0
which contains gcc-10.2.1 and glibc-2.32. Building for architecture
arm-v5te-linux-gnueabi here, console output below.
Autotools build was fine. Build with a more recent toolchain
(OSELAS.Toolchain-2023.07, gcc 13.2.1, glibc 2.37) is successful.
From looking at the linker options I suspect -lutil missing?
According to manpage that's a BSD function present in glibc.
I suspect a change in glibc 2.34 integrating libutil in core glibc,
which makes it work with recent version 2.37. So this is probably a
flaw in meson build not setting the necessary linker options for glibc
up to 2.33? Could anyone point me how to fix this or does anyone by
chance already have a patch for this? (Disclaimer: I have zero
experience with meson.)
% p -v -j1 compile util-linux
--------------------------
target: util-linux.compile
--------------------------
ptxdist: executing: PATH=/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-cross/usr/bin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-cross/usr/sbin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/lib/wrapper:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/bin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/sbin:/home/adahl/Work/bsp/thorsis/ncl/tmp/selected_toolchain:/usr/local/lib/ptxdist-2024.05.0/bin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/bin:/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-host/usr/sbin:/home/adahl/Work/bsp/thorsis/ncl/tmp/selected_toolchain:/usr/local/lib/ptxdist-2024.04.0/bin:/home/adahl/bin:/home/adahl/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/games HTTPS_PROXY=PTXDIST-UNALLOWED-DOWNLOAD HTTP_PROXY=PTXDIST-UNALLOWED-DOWNLOAD https_proxy=PTXDIST-UNALLOWED-DOWNLOAD http_proxy=PTXDIST-UNALLOWED-DOWNLOAD PKGCONFIG_WHITELIST_HOST='' PKGCONFIG_WHITELIST_TARGET='' PKGCONFIG_WHITELIST_SRC='util-linux' SYSROOT='/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/sysroot-target' V=1 VERBOSE=1 LC_ALL='C.utf8' KBUILD_BUILD_TIMESTAMP=2020-08-01T00:00:00+00:00 KBUILD_BUILD_USER=ptxdist KBUILD_BUILD_HOST=ptxdist ninja -C /home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/build-target/util-linux-2.40.2-build -v -j1
ninja: Entering directory `/home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/build-target/util-linux-2.40.2-build'
[1/75] arm-v5te-linux-gnueabi-gcc -o test_pty test_pty.p/lib_pty-session.c.o test_pty.p/lib_monotonic.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,--start-group lib/libcommon.a -lm -lrt -Wl,--end-group
FAILED: test_pty
arm-v5te-linux-gnueabi-gcc -o test_pty test_pty.p/lib_pty-session.c.o test_pty.p/lib_monotonic.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,--start-group lib/libcommon.a -lm -lrt -Wl,--end-group
/opt/OSELAS.Toolchain-2020.08.0/arm-v5te-linux-gnueabi/gcc-10.2.1-glibc-2.32-binutils-2.35-kernel-5.8-sanitized/lib/gcc/arm-v5te-linux-gnueabi/10.2.1/../../../../arm-v5te-linux-gnueabi/bin/ld: test_pty.p/lib_pty-session.c.o: in function `ul_pty_setup':
platform-ncl/build-target/util-linux-2.40.2-build/../util-linux-2.40.2/lib/pty-session.c:198: undefined reference to `openpty'
/opt/OSELAS.Toolchain-2020.08.0/arm-v5te-linux-gnueabi/gcc-10.2.1-glibc-2.32-binutils-2.35-kernel-5.8-sanitized/lib/gcc/arm-v5te-linux-gnueabi/10.2.1/../../../../arm-v5te-linux-gnueabi/bin/ld: platform-ncl/build-target/util-linux-2.40.2-build/../util-linux-2.40.2/lib/pty-session.c:188: undefined reference to `openpty'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
make: *** [/usr/local/lib/ptxdist-2024.05.0/rules/post/ptxd_make_world_compile.make:20: /home/adahl/Work/bsp/thorsis/ncl/tmp/platform-ncl/state/util-linux.compile] Error 1
Greets
Alex
[1] https://www.ptxdist.org/
[2] https://git.pengutronix.de/cgit/ptxdist/commit/?id=18c9c0f89c4148f3007b9fcc7833d99af60084dc
^ permalink raw reply
* Re: [PATCH 0/2] chcpu documentation update
From: Karel Zak @ 2024-09-03 9:51 UTC (permalink / raw)
To: Mete Durlu; +Cc: util-linux, hca
In-Reply-To: <20240902150553.1969571-1-meted@linux.ibm.com>
On Mon, Sep 02, 2024 at 05:05:51PM GMT, Mete Durlu wrote:
> Mete Durlu (2):
> chcpu(8): Fix typo
> chcpu(8): Document CPU deconfiguring behavior
Applied, thanks!
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* [PATCH 1/2] chcpu(8): Fix typo
From: Mete Durlu @ 2024-09-02 15:05 UTC (permalink / raw)
To: kzak; +Cc: util-linux, hca
In-Reply-To: <20240902150553.1969571-1-meted@linux.ibm.com>
Signed-off-by: Mete Durlu <meted@linux.ibm.com>
---
sys-utils/chcpu.8.adoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sys-utils/chcpu.8.adoc b/sys-utils/chcpu.8.adoc
index 80dfc5f20..0b0bcbc57 100644
--- a/sys-utils/chcpu.8.adoc
+++ b/sys-utils/chcpu.8.adoc
@@ -38,7 +38,7 @@ Enable the specified CPUs. Enabling a CPU means that the kernel sets it online.
*-g*, *--deconfigure* _cpu-list_::
Deconfigure the specified CPUs. Deconfiguring a CPU means that the hypervisor removes the CPU from the virtual hardware on which the Linux instance runs and returns it to the CPU pool. A CPU must be offline, see *-d*, before it can be deconfigured.
+
-*chcpu -g* is not supported on IBM z/VM, CPUs are always in a configured.
+*chcpu -g* is not supported on IBM z/VM, CPUs are always in a configured state.
*-p*, *--dispatch* _mode_::
Set the CPU dispatching _mode_ (polarization). This option has an effect only if your hardware architecture and hypervisor support CPU polarization. Available _modes_ are:
--
2.46.0
^ permalink raw reply related
* [PATCH 2/2] chcpu(8): Document CPU deconfiguring behavior
From: Mete Durlu @ 2024-09-02 15:05 UTC (permalink / raw)
To: kzak; +Cc: util-linux, hca
In-Reply-To: <20240902150553.1969571-1-meted@linux.ibm.com>
If architecture supports (de)configuring CPUs, the user should
deconfigure disabled CPUs to prevent performance penalties.
Signed-off-by: Mete Durlu <meted@linux.ibm.com>
---
sys-utils/chcpu.8.adoc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sys-utils/chcpu.8.adoc b/sys-utils/chcpu.8.adoc
index 0b0bcbc57..f08b5a6ab 100644
--- a/sys-utils/chcpu.8.adoc
+++ b/sys-utils/chcpu.8.adoc
@@ -39,6 +39,8 @@ Enable the specified CPUs. Enabling a CPU means that the kernel sets it online.
Deconfigure the specified CPUs. Deconfiguring a CPU means that the hypervisor removes the CPU from the virtual hardware on which the Linux instance runs and returns it to the CPU pool. A CPU must be offline, see *-d*, before it can be deconfigured.
+
*chcpu -g* is not supported on IBM z/VM, CPUs are always in a configured state.
++
+if *chcpu -g* is supported, any *disabled* CPUs should be *deconfigured* to inform the hypervisor that these CPUs won't be used, avoiding potential performance penalties.
*-p*, *--dispatch* _mode_::
Set the CPU dispatching _mode_ (polarization). This option has an effect only if your hardware architecture and hypervisor support CPU polarization. Available _modes_ are:
--
2.46.0
^ permalink raw reply related
* [PATCH 0/2] chcpu documentation update
From: Mete Durlu @ 2024-09-02 15:05 UTC (permalink / raw)
To: kzak; +Cc: util-linux, hca
This patch series, fixes a typo and adds a CPU (de)configuration hint
to the chcpu manual.
Mete Durlu (2):
chcpu(8): Fix typo
chcpu(8): Document CPU deconfiguring behavior
sys-utils/chcpu.8.adoc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
2.46.0
^ permalink raw reply
* Request For Inquiry
From: Vivian @ 2024-08-28 9:42 UTC (permalink / raw)
To: util-linux
Dear Supplier
Nice to contact you again
Hope this mail find you well
We are interested in importing your product
i would like to place an order from your company this month,
kindly send me your catalogue and price through our E-MAIL or
skype,
Please treat this as urgent
thanks
Purchase Manager vivian
Email: vivian@internationaluniforms.com
Beim Strohhause 2
20097 Hamburg – Germany
Phone: +49/40/284 24-321
Fax: +49/40/284 24-236
^ permalink raw reply
* Re: fuse mount failure when type contains '.'
From: John Rinehart @ 2024-08-24 2:23 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: Karel Zak, util-linux
In-Reply-To: <CAJfpegtgyyEv1O5D43J=DWP+CqyJEsg=dteT9T0yPxqsnArkMw@mail.gmail.com>
Thanks for your response.
But, hold up. I demonstrated a(n apparently) valid use case, shared
links where other people have hit this problem over the years, and
proposed an implementation accommodating it (which I'm using in a
patched/forked version of `util-linux`, currently). Since the
requested change would allow for subtypes to include `.` in addition
to [a-zA-Z0-9_]* I don't see a theoretical restriction (even if the
implementation as proposed is unacceptable as-is based on style or
unforeseen edge cases). Users want to use `.` in subtypes, it's
backward-compatible, it doesn't violate any documentation/guarantee
(as far as I can tell) and a working solution has been provided.
What's the rationale for prohibiting this use case?
Thank you.
On Thu, Aug 22, 2024, 07:09 Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Mon, 5 Aug 2024 at 11:49, Karel Zak <kzak@redhat.com> wrote:
> >
> >
> > Hi John,
> >
> > On Thu, Aug 01, 2024 at 11:16:30AM GMT, John Rinehart wrote:
> > > `util-linux` seems to fail to handle a use case that users like me seem to
> > > be hitting with some frequency. The issue is around
> > > https://github.com/util-linux/util-linux/blob/86b6684e7a215a0608bd130371bd7b3faae67aca/libmount/src/context.c#L2115-L2121
> > > and seems rooted in the fact that `util-linux` operates on `type` where
> > > type is always of the form <a>.<b> but where <b> is apparently assumed to
> > > not contain Unicode U+002E (ASCII 2E): '.' ("dotless"). I say it "appears
> > > to assume" this since the logic which appears to remove the subtype does so
> > > by using `strrchr`, which addresses only the last period in the `helper`
> > > string. If the `subtype`, itself, has a U+002E character then this won't
> > > remove the subtype.
> > >
> > > As an example, if `helper` looks like
> > > `path/name.type./subtype/path/with/a.period` then the modified `helper`
> > > after `strrchr` will look like `path/name.type./subtype/path/with/a`
> > > instead of the apparently-intended `path/name.type`.
> >
> > the convention for filesystem names is (was):
> >
> > <type>[.<subtype>]
> >
> > For example, for the "mount" helper, it is:
> >
> > /path/mount.<type>[.<subtype>]
> >
> > I believe it is acceptable for the "path" to contain dots (or any
> > other characters). The important thing is the last segment of the path
> > (e.g. /mount.<type>[.<subtype>]). We should not be concerned with
> > anything else besides the last segment.
> >
> > It is strange to assume that <subtype> can also contain path-like
> > segments and dots. It seems like someone may want to use <subtype> to
> > encode additional information ...
> >
> > Miklos (CC:), what is your opinion? Is it correct to assume that <subtype>
> > is whatever?
>
> We can assume that subtype is just [a-zA-Z0-9_]*, I think.
>
> Thanks,
> Miklos
>
>
>
> >
> > Karel
> >
> >
> > > This crops up for users like me because I use NixOS which is a store-based
> > > Linux operating system using paths like:
> > > ```
> > > $ readlink -f $(which s3fs)
> > >
> > > /nix/store/xwbx0fbg65ml2qjl86p9p2w58kghqn8r-s3fs-fuse-1.94/bin/s3fs
> > > ```
> > > (So, paths like `/nix/store/<hash>-<name>-<version>/bin/<cmd>`). `version`
> > > is usually a dot-delimited string like `1.23`.
> > >
> > > I've generated a patch which seems to ameliorate this behavior. It's
> > > attached (sorry if attachments are not the way to go with this mailing
> > > list, specifically, or mailing lists, generally - this is my first time
> > > submitting a patch to a mailing list). The logic is simple, but it
> > > basically iterates through all possible substrings according to the number
> > > of U+002E characters in the `type` string. It's a more generic form of the
> > > logic already present, but it's a little heavy-handed. Happy with any and
> > > all changes which preserve the apparently-corrected behavior.
> > >
> > > Please let me know if I should make any changes or if a change like this
> > > won't be accepted for some reason or if I'm misunderstanding the
> > > problem/solution.
> > >
> > > Thank you!
> > >
> > > Cf.
> > > 1. https://discourse.nixos.org/t/how-to-setup-s3fs-mount/6283/5
> > > 2. https://github.com/NixOS/nixpkgs/issues/46529#issuecomment-655536831
> > >
> > > -- John Rinehart
> >
> >
> >
> > --
> > Karel Zak <kzak@redhat.com>
> > http://karelzak.blogspot.com
> >
^ permalink raw reply
* Re: fuse mount failure when type contains '.'
From: Miklos Szeredi @ 2024-08-22 14:08 UTC (permalink / raw)
To: Karel Zak; +Cc: John Rinehart, util-linux
In-Reply-To: <bytzy2l3mhrcxpcmhqqmyxj7jeu6jafbyu7pmkx3ocupii5tue@qeiobojgjess>
On Mon, 5 Aug 2024 at 11:49, Karel Zak <kzak@redhat.com> wrote:
>
>
> Hi John,
>
> On Thu, Aug 01, 2024 at 11:16:30AM GMT, John Rinehart wrote:
> > `util-linux` seems to fail to handle a use case that users like me seem to
> > be hitting with some frequency. The issue is around
> > https://github.com/util-linux/util-linux/blob/86b6684e7a215a0608bd130371bd7b3faae67aca/libmount/src/context.c#L2115-L2121
> > and seems rooted in the fact that `util-linux` operates on `type` where
> > type is always of the form <a>.<b> but where <b> is apparently assumed to
> > not contain Unicode U+002E (ASCII 2E): '.' ("dotless"). I say it "appears
> > to assume" this since the logic which appears to remove the subtype does so
> > by using `strrchr`, which addresses only the last period in the `helper`
> > string. If the `subtype`, itself, has a U+002E character then this won't
> > remove the subtype.
> >
> > As an example, if `helper` looks like
> > `path/name.type./subtype/path/with/a.period` then the modified `helper`
> > after `strrchr` will look like `path/name.type./subtype/path/with/a`
> > instead of the apparently-intended `path/name.type`.
>
> the convention for filesystem names is (was):
>
> <type>[.<subtype>]
>
> For example, for the "mount" helper, it is:
>
> /path/mount.<type>[.<subtype>]
>
> I believe it is acceptable for the "path" to contain dots (or any
> other characters). The important thing is the last segment of the path
> (e.g. /mount.<type>[.<subtype>]). We should not be concerned with
> anything else besides the last segment.
>
> It is strange to assume that <subtype> can also contain path-like
> segments and dots. It seems like someone may want to use <subtype> to
> encode additional information ...
>
> Miklos (CC:), what is your opinion? Is it correct to assume that <subtype>
> is whatever?
We can assume that subtype is just [a-zA-Z0-9_]*, I think.
Thanks,
Miklos
>
> Karel
>
>
> > This crops up for users like me because I use NixOS which is a store-based
> > Linux operating system using paths like:
> > ```
> > $ readlink -f $(which s3fs)
> >
> > /nix/store/xwbx0fbg65ml2qjl86p9p2w58kghqn8r-s3fs-fuse-1.94/bin/s3fs
> > ```
> > (So, paths like `/nix/store/<hash>-<name>-<version>/bin/<cmd>`). `version`
> > is usually a dot-delimited string like `1.23`.
> >
> > I've generated a patch which seems to ameliorate this behavior. It's
> > attached (sorry if attachments are not the way to go with this mailing
> > list, specifically, or mailing lists, generally - this is my first time
> > submitting a patch to a mailing list). The logic is simple, but it
> > basically iterates through all possible substrings according to the number
> > of U+002E characters in the `type` string. It's a more generic form of the
> > logic already present, but it's a little heavy-handed. Happy with any and
> > all changes which preserve the apparently-corrected behavior.
> >
> > Please let me know if I should make any changes or if a change like this
> > won't be accepted for some reason or if I'm misunderstanding the
> > problem/solution.
> >
> > Thank you!
> >
> > Cf.
> > 1. https://discourse.nixos.org/t/how-to-setup-s3fs-mount/6283/5
> > 2. https://github.com/NixOS/nixpkgs/issues/46529#issuecomment-655536831
> >
> > -- John Rinehart
>
>
>
> --
> Karel Zak <kzak@redhat.com>
> http://karelzak.blogspot.com
>
^ permalink raw reply
* Re: [PATCH] lscpu: optimize query virt pci device
From: Karel Zak @ 2024-08-22 11:30 UTC (permalink / raw)
To: Guixin Liu; +Cc: qcai, util-linux
In-Reply-To: <20240821084954.21566-1-kanie@linux.alibaba.com>
On Wed, Aug 21, 2024 at 04:49:54PM GMT, Guixin Liu wrote:
> sys-utils/lscpu-virt.c | 39 ++++++++++++++++++++++-----------------
> 1 file changed, 22 insertions(+), 17 deletions(-)
Thanks, the patch looks good. I'll merge it later after it passes CI:
https://github.com/util-linux/util-linux/pull/3177.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* [PATCH] lscpu: optimize query virt pci device
From: Guixin Liu @ 2024-08-21 8:49 UTC (permalink / raw)
To: qcai; +Cc: util-linux
The lscpu command needs to traverse the /proc/bus/pci/devices file
three times to check for any PCI devices related to virtualization.
If there are many PCI devices on the machine, this can lead to
increased execution time for lscpu. It would be beneficial to
consolidate these queries into a single check to optimize the
execution time of lscpu.
Use time command to test on a machine with 13000 PCI devices:
before:
real 0m13.506s
user 0m0.028s
sys 0m13.409s
after:
real 0m5.834s
user 0m0.018s
sys 0m5.771s
Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
---
sys-utils/lscpu-virt.c | 39 ++++++++++++++++++++++-----------------
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/sys-utils/lscpu-virt.c b/sys-utils/lscpu-virt.c
index 051384622..f559d9c14 100644
--- a/sys-utils/lscpu-virt.c
+++ b/sys-utils/lscpu-virt.c
@@ -273,16 +273,15 @@ static int read_hypervisor_dmi(void)
return rc < 0 ? VIRT_VENDOR_NONE : rc;
}
-static int has_pci_device(struct lscpu_cxt *cxt,
- unsigned int vendor, unsigned int device)
+static int find_virt_pci_device(struct lscpu_cxt *cxt)
{
FILE *f;
- unsigned int num, fn, ven, dev;
- int res = 1;
+ int num, fn, ven, dev;
+ int vendor = VIRT_VENDOR_NONE;
f = ul_path_fopen(cxt->procfs, "r", "bus/pci/devices");
if (!f)
- return 0;
+ return vendor;
/* for more details about bus/pci/devices format see
* drivers/pci/proc.c in linux kernel
@@ -290,14 +289,28 @@ static int has_pci_device(struct lscpu_cxt *cxt,
while(fscanf(f, "%02x%02x\t%04x%04x\t%*[^\n]",
&num, &fn, &ven, &dev) == 4) {
- if (ven == vendor && dev == device)
+ if (ven == hv_vendor_pci[VIRT_VENDOR_XEN] &&
+ dev == hv_graphics_pci[VIRT_VENDOR_XEN]) {
+ vendor = VIRT_VENDOR_XEN;
+ goto found;
+ }
+
+ if (ven == hv_vendor_pci[VIRT_VENDOR_VMWARE] &&
+ dev == hv_graphics_pci[VIRT_VENDOR_VMWARE]) {
+ vendor = VIRT_VENDOR_VMWARE;
+ goto found;
+ }
+
+ if (ven == hv_vendor_pci[VIRT_VENDOR_VBOX] &&
+ dev == hv_graphics_pci[VIRT_VENDOR_VBOX]) {
+ vendor = VIRT_VENDOR_VBOX;
goto found;
+ }
}
- res = 0;
found:
fclose(f);
- return res;
+ return vendor;
}
#if defined(__x86_64__) || defined(__i386__)
@@ -597,16 +610,8 @@ struct lscpu_virt *lscpu_read_virtualization(struct lscpu_cxt *cxt)
virt->vendor = VIRT_VENDOR_XEN;
/* Xen full-virt on non-x86_64 */
- } else if (has_pci_device(cxt, hv_vendor_pci[VIRT_VENDOR_XEN], hv_graphics_pci[VIRT_VENDOR_XEN])) {
- virt->vendor = VIRT_VENDOR_XEN;
+ } else if ((virt->vendor = find_virt_pci_device(cxt))) {
virt->type = VIRT_TYPE_FULL;
- } else if (has_pci_device(cxt, hv_vendor_pci[VIRT_VENDOR_VMWARE], hv_graphics_pci[VIRT_VENDOR_VMWARE])) {
- virt->vendor = VIRT_VENDOR_VMWARE;
- virt->type = VIRT_TYPE_FULL;
- } else if (has_pci_device(cxt, hv_vendor_pci[VIRT_VENDOR_VBOX], hv_graphics_pci[VIRT_VENDOR_VBOX])) {
- virt->vendor = VIRT_VENDOR_VBOX;
- virt->type = VIRT_TYPE_FULL;
-
/* IBM PR/SM */
} else if ((fd = ul_path_fopen(cxt->procfs, "r", "sysinfo"))) {
--
2.30.1 (Apple Git-130)
^ permalink raw reply related
* Re: util-linux bug: mkfs(8) has -V for -v
From: Karel Zak @ 2024-08-15 7:28 UTC (permalink / raw)
To: Jeremy Dilatush; +Cc: util-linux@vger.kernel.org
In-Reply-To: <0ca8b22dbbde43e0b65857877ec9a624@checkpoint.com>
On Thu, Aug 08, 2024 at 06:07:26PM GMT, Jeremy Dilatush wrote:
> > The manpage mkfs(8) lists "-V, --verbose" which should be "-v, --verbose" (uncapitalized).
> > Seen on as recent a version as 2.38.1 (on Raspberry Pi OS), also seen on 2.23.2 (on CentOS 7).
> > Not as trivial a fault as it might seem, since "-V" unlike "-v" causes mkfs to do nothing.
>
> 25% user error on my part: Looks like there are two bugs here and one is already fixed:
> "mkfs -j -t ext4 -V Tempy" gives version on 2.23.2 but verbose on 2.38.1.
> The manpage still probably should have "-v, --verbose".
I believe the current version of the man page is quite clear on this
matter:
-V, --version
Print version and exit. (Option -V will display version information only when it is
the only parameter, otherwise it will work as --verbose.)
and important is also the first line of the man page:
This mkfs frontend is deprecated in favour of filesystem specific mkfs.<type> utils.
;-)
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* RE: util-linux bug: mkfs(8) has -V for -v
From: Jeremy Dilatush @ 2024-08-08 18:07 UTC (permalink / raw)
To: util-linux@vger.kernel.org
In-Reply-To: <28f8d3ca8b3545e5af64e2a7699b4b03@checkpoint.com>
> The manpage mkfs(8) lists "-V, --verbose" which should be "-v, --verbose" (uncapitalized).
> Seen on as recent a version as 2.38.1 (on Raspberry Pi OS), also seen on 2.23.2 (on CentOS 7).
> Not as trivial a fault as it might seem, since "-V" unlike "-v" causes mkfs to do nothing.
25% user error on my part: Looks like there are two bugs here and one is already fixed:
"mkfs -j -t ext4 -V Tempy" gives version on 2.23.2 but verbose on 2.38.1.
The manpage still probably should have "-v, --verbose".
--- Jeremy
^ permalink raw reply
* Re: fuse mount failure when type contains '.'
From: John Rinehart @ 2024-08-05 19:19 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux, Miklos Szeredi
In-Reply-To: <bytzy2l3mhrcxpcmhqqmyxj7jeu6jafbyu7pmkx3ocupii5tue@qeiobojgjess>
> Hi John,
Hi Karel (and Miklos, CCed) 👋!
> On Thu, Aug 01, 2024 at 11:16:30AM GMT, John Rinehart wrote:
> > `util-linux` seems to fail to handle a use case that users like me seem to
> > be hitting with some frequency. The issue is around
> > https://github.com/util-linux/util-linux/blob/86b6684e7a215a0608bd130371bd7b3faae67aca/libmount/src/context.c#L2115-L2121
> > and seems rooted in the fact that `util-linux` operates on `type` where
> > type is always of the form <a>.<b> but where <b> is apparently assumed to
> > not contain Unicode U+002E (ASCII 2E): '.' ("dotless"). I say it "appears
> > to assume" this since the logic which appears to remove the subtype does so
> > by using `strrchr`, which addresses only the last period in the `helper`
> > string. If the `subtype`, itself, has a U+002E character then this won't
> > remove the subtype.
> >
> > As an example, if `helper` looks like
> > `path/name.type./subtype/path/with/a.period` then the modified `helper`
> > after `strrchr` will look like `path/name.type./subtype/path/with/a`
> > instead of the apparently-intended `path/name.type`.
>
> the convention for filesystem names is (was):
>
> <type>[.<subtype>]
>
> For example, for the "mount" helper, it is:
>
> /path/mount.<type>[.<subtype>]
>
> I believe it is acceptable for the "path" to contain dots (or any
> other characters). The important thing is the last segment of the path
> (e.g. /mount.<type>[.<subtype>]). We should not be concerned with
> anything else besides the last segment.
>
> It is strange to assume that <subtype> can also contain path-like
> segments and dots. It seems like someone may want to use <subtype> to
> encode additional information ...
Thanks for your response! If I can restate/augment my case:
`util-linux`'s `mount` implementation will fail to properly delimit
`type` from `subtype` if `subtype` contains `.`. `subtype` is expected
by `mount.fuse` to be an executable compatible with `fuse`. If the
executable isn't reachable from the `$PATH` (which appears to be the
case with the `systemd` mount target auto-generated from my fstab)
then it should be specified absolutely (although this isn't documented
in the man pages for `mount.fuse`). You can understand this logic by
taking a look at
https://github.com/libfuse/libfuse/blob/beff8a8ebe1b413b4b572b93ddca24aaeb904f7a/util/mount.fuse.c#L295-L296
followed by
https://github.com/libfuse/libfuse/blob/beff8a8ebe1b413b4b572b93ddca24aaeb904f7a/util/mount.fuse.c#L432
In the case of my OS's absolute path to the `s3fs` binary (compatible
with and called by `mount.fuse`), it contains a `.` (because of the
version string described previously) which breaks `util-linux`'s
`mount` implementation when it attempts to separate the `type` from
the `subtype`.
`util-linux` hasn't documented any restrictions on character values
contained within `subtype`. So, in consideration of Hyrum's law and in
the spirit of being liberal in what's accepted while conservative in
what's emitted, I'd kindly ask `util-linux` maintainers to support `.`
characters in the `subtype` so that users like me can fearlessly
specify absolute paths to FUSE binaries in their subtype.
> Miklos (CC:), what is your opinion? Is it correct to assume that <subtype>
> is whatever?
>
> Karel
>
>
> > This crops up for users like me because I use NixOS which is a store-based
> > Linux operating system using paths like:
> > ```
> > $ readlink -f $(which s3fs)
> >
> > /nix/store/xwbx0fbg65ml2qjl86p9p2w58kghqn8r-s3fs-fuse-1.94/bin/s3fs
> > ```
> > (So, paths like `/nix/store/<hash>-<name>-<version>/bin/<cmd>`). `version`
> > is usually a dot-delimited string like `1.23`.
> >
> > I've generated a patch which seems to ameliorate this behavior. It's
> > attached (sorry if attachments are not the way to go with this mailing
> > list, specifically, or mailing lists, generally - this is my first time
> > submitting a patch to a mailing list). The logic is simple, but it
> > basically iterates through all possible substrings according to the number
> > of U+002E characters in the `type` string. It's a more generic form of the
> > logic already present, but it's a little heavy-handed. Happy with any and
> > all changes which preserve the apparently-corrected behavior.
> >
> > Please let me know if I should make any changes or if a change like this
> > won't be accepted for some reason or if I'm misunderstanding the
> > problem/solution.
> >
> > Thank you!
> >
> > Cf.
> > 1. https://discourse.nixos.org/t/how-to-setup-s3fs-mount/6283/5
> > 2. https://github.com/NixOS/nixpkgs/issues/46529#issuecomment-655536831
> >
> > -- John Rinehart
>
>
>
> --
> Karel Zak <kzak@redhat.com>
> http://karelzak.blogspot.com
>
^ permalink raw reply
* Re: fuse mount failure when type contains '.'
From: Karel Zak @ 2024-08-05 9:49 UTC (permalink / raw)
To: John Rinehart; +Cc: util-linux, Miklos Szeredi
In-Reply-To: <CAGc5Yo9G2mJkbgVAbZESVvBVCK9OF7MWbEf=Mt0tY2XBFg+=yQ@mail.gmail.com>
Hi John,
On Thu, Aug 01, 2024 at 11:16:30AM GMT, John Rinehart wrote:
> `util-linux` seems to fail to handle a use case that users like me seem to
> be hitting with some frequency. The issue is around
> https://github.com/util-linux/util-linux/blob/86b6684e7a215a0608bd130371bd7b3faae67aca/libmount/src/context.c#L2115-L2121
> and seems rooted in the fact that `util-linux` operates on `type` where
> type is always of the form <a>.<b> but where <b> is apparently assumed to
> not contain Unicode U+002E (ASCII 2E): '.' ("dotless"). I say it "appears
> to assume" this since the logic which appears to remove the subtype does so
> by using `strrchr`, which addresses only the last period in the `helper`
> string. If the `subtype`, itself, has a U+002E character then this won't
> remove the subtype.
>
> As an example, if `helper` looks like
> `path/name.type./subtype/path/with/a.period` then the modified `helper`
> after `strrchr` will look like `path/name.type./subtype/path/with/a`
> instead of the apparently-intended `path/name.type`.
the convention for filesystem names is (was):
<type>[.<subtype>]
For example, for the "mount" helper, it is:
/path/mount.<type>[.<subtype>]
I believe it is acceptable for the "path" to contain dots (or any
other characters). The important thing is the last segment of the path
(e.g. /mount.<type>[.<subtype>]). We should not be concerned with
anything else besides the last segment.
It is strange to assume that <subtype> can also contain path-like
segments and dots. It seems like someone may want to use <subtype> to
encode additional information ...
Miklos (CC:), what is your opinion? Is it correct to assume that <subtype>
is whatever?
Karel
> This crops up for users like me because I use NixOS which is a store-based
> Linux operating system using paths like:
> ```
> $ readlink -f $(which s3fs)
>
> /nix/store/xwbx0fbg65ml2qjl86p9p2w58kghqn8r-s3fs-fuse-1.94/bin/s3fs
> ```
> (So, paths like `/nix/store/<hash>-<name>-<version>/bin/<cmd>`). `version`
> is usually a dot-delimited string like `1.23`.
>
> I've generated a patch which seems to ameliorate this behavior. It's
> attached (sorry if attachments are not the way to go with this mailing
> list, specifically, or mailing lists, generally - this is my first time
> submitting a patch to a mailing list). The logic is simple, but it
> basically iterates through all possible substrings according to the number
> of U+002E characters in the `type` string. It's a more generic form of the
> logic already present, but it's a little heavy-handed. Happy with any and
> all changes which preserve the apparently-corrected behavior.
>
> Please let me know if I should make any changes or if a change like this
> won't be accepted for some reason or if I'm misunderstanding the
> problem/solution.
>
> Thank you!
>
> Cf.
> 1. https://discourse.nixos.org/t/how-to-setup-s3fs-mount/6283/5
> 2. https://github.com/NixOS/nixpkgs/issues/46529#issuecomment-655536831
>
> -- John Rinehart
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* fuse mount failure when type contains '.'
From: John Rinehart @ 2024-08-01 18:16 UTC (permalink / raw)
To: util-linux
[-- Attachment #1.1: Type: text/plain, Size: 2183 bytes --]
`util-linux` seems to fail to handle a use case that users like me seem to
be hitting with some frequency. The issue is around
https://github.com/util-linux/util-linux/blob/86b6684e7a215a0608bd130371bd7b3faae67aca/libmount/src/context.c#L2115-L2121
and seems rooted in the fact that `util-linux` operates on `type` where
type is always of the form <a>.<b> but where <b> is apparently assumed to
not contain Unicode U+002E (ASCII 2E): '.' ("dotless"). I say it "appears
to assume" this since the logic which appears to remove the subtype does so
by using `strrchr`, which addresses only the last period in the `helper`
string. If the `subtype`, itself, has a U+002E character then this won't
remove the subtype.
As an example, if `helper` looks like
`path/name.type./subtype/path/with/a.period` then the modified `helper`
after `strrchr` will look like `path/name.type./subtype/path/with/a`
instead of the apparently-intended `path/name.type`.
This crops up for users like me because I use NixOS which is a store-based
Linux operating system using paths like:
```
$ readlink -f $(which s3fs)
/nix/store/xwbx0fbg65ml2qjl86p9p2w58kghqn8r-s3fs-fuse-1.94/bin/s3fs
```
(So, paths like `/nix/store/<hash>-<name>-<version>/bin/<cmd>`). `version`
is usually a dot-delimited string like `1.23`.
I've generated a patch which seems to ameliorate this behavior. It's
attached (sorry if attachments are not the way to go with this mailing
list, specifically, or mailing lists, generally - this is my first time
submitting a patch to a mailing list). The logic is simple, but it
basically iterates through all possible substrings according to the number
of U+002E characters in the `type` string. It's a more generic form of the
logic already present, but it's a little heavy-handed. Happy with any and
all changes which preserve the apparently-corrected behavior.
Please let me know if I should make any changes or if a change like this
won't be accepted for some reason or if I'm misunderstanding the
problem/solution.
Thank you!
Cf.
1. https://discourse.nixos.org/t/how-to-setup-s3fs-mount/6283/5
2. https://github.com/NixOS/nixpkgs/issues/46529#issuecomment-655536831
-- John Rinehart
[-- Attachment #1.2: Type: text/html, Size: 2920 bytes --]
[-- Attachment #2: util-linux.patch --]
[-- Type: text/x-patch, Size: 980 bytes --]
diff --git a/libmount/src/context.c b/libmount/src/context.c
index d38e3671f..411f98f3f 100644
--- a/libmount/src/context.c
+++ b/libmount/src/context.c
@@ -2097,6 +2097,11 @@ int mnt_context_prepare_helper(struct libmnt_context *cxt, const char *name,
if (!ns_old)
return -MNT_ERR_NAMESPACE;
+ /* Record number of '.' in `type` so we can try a few things later. */
+ int dot_count = 0;
+ for (int i=0; type[i]; i++)
+ dot_count += (type[i] == '.');
+
/* Ignore errors when search in $PATH and do not modify @rc
*/
path = strtok_r(search_path, ":", &p);
@@ -2112,8 +2117,8 @@ int mnt_context_prepare_helper(struct libmnt_context *cxt, const char *name,
continue;
found = mnt_is_path(helper);
- if (!found && strchr(type, '.')) {
- /* If type ends with ".subtype" try without it */
+ /* If type contains '.' then try without them. */
+ for (int cnt = dot_count; !found && cnt; --cnt) {
char *hs = strrchr(helper, '.');
if (hs)
*hs = '\0';
^ permalink raw reply related
* Re: [PATCH] agetty: Prevent cursor escape
From: Stanislav Brabec @ 2024-07-23 22:50 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
In-Reply-To: <kbdtjvbk6d7tazpqblki75tjatmqvq54hzxyybrb4uh4kjwevl@rzsfd2cofobp>
Dne 23. 07. 24 v 14:56 Karel Zak napsal(a):
> On Sun, Jul 21, 2024 at 03:01:42PM GMT, Stanislav Brabec wrote:
>
>> + write_all(1, "^[", 2);
> Not sure if we need anything more robust here. If you have access to
> the terminal, you can write whatever you want and it will be interpreted
> as a username (meaning non-terminal code will interpret it).
Anything better would be complicated. We are reading stdin byte after
byte. So we need to do something with the yet unfinished sequence. And
we cannot read more, as the select() guarantees just a single character.
Ando this is just equal to ICANON | ECHOCTL terminal mode. Additionally,
it returns behavior that was here before 8b58ffdd, but now processing
network events better.
By the way, login is affected by the same problem. But in that case, it
is the fault of pam. I proposed the same solution here. But in that
case, it can be handled on the terminal level:
https://github.com/linux-pam/linux-pam/pull/816
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com
Křižíkova 148/34 (Corso IIa) tel: +420 284 084 060
186 00 Praha 8-Karlín fax: +420 284 084 001
Czech Republic http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
^ permalink raw reply
* Re: [PATCH] agetty: Prevent cursor escape
From: Karel Zak @ 2024-07-23 12:56 UTC (permalink / raw)
To: Stanislav Brabec; +Cc: util-linux
In-Reply-To: <20240721130142.468136-1-sbrabec@suse.cz>
On Sun, Jul 21, 2024 at 03:01:42PM GMT, Stanislav Brabec wrote:
> term-utils/agetty.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
Applied, thanks.
> + write_all(1, "^[", 2);
Not sure if we need anything more robust here. If you have access to
the terminal, you can write whatever you want and it will be interpreted
as a username (meaning non-terminal code will interpret it).
There is include/carefulputc.h:fputs_careful(), but it's currently
based on FILE streams rather than file descriptors.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* [PATCH] agetty: Prevent cursor escape
From: Stanislav Brabec @ 2024-07-21 13:01 UTC (permalink / raw)
To: util-linux; +Cc: Stanislav Brabec
Starting with 5de97519, it is possible to escape the login dialog on the
screen by arrow characters or using escape sequences.
Since full processing of escape sequences and ignore them would be
complicated, use a work around: instead of sending ESC to output, send a
printable character.
It could cause a rendering regression in a very obscure condition: compiled
without IUTF8, encoding is ISO-11548-1 and BRAILLE PATTERN DOTS-1245 is
part of login name. I believe that it is out of supported combinations.
Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
---
term-utils/agetty.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/term-utils/agetty.c b/term-utils/agetty.c
index 275c59362..e20e7a454 100644
--- a/term-utils/agetty.c
+++ b/term-utils/agetty.c
@@ -2286,7 +2286,14 @@ static char *get_logname(struct issue *ie, struct options *op, struct termios *t
if ((size_t)(bp - logname) >= sizeof(logname) - 1)
log_err(_("%s: input overrun"), op->tty);
if ((tp->c_lflag & ECHO) == 0)
- write_all(1, &c, 1); /* echo the character */
+ /* Visualize escape sequence instead of its execution */
+ if (ascval == CTL('['))
+ /* Ideally it should be "\xe2\x90\x9b"
+ * if (op->flags & (F_UTF8)),
+ * but only some fonts contain it */
+ write_all(1, "^[", 2);
+ else
+ write_all(1, &c, 1); /* echo the character */
*bp++ = ascval; /* and store it */
break;
}
--
2.45.2
^ permalink raw reply related
* Re: lsblk: mount point in btrfs raid
From: Karel Zak @ 2024-07-10 10:39 UTC (permalink / raw)
To: lukaro; +Cc: util-linux
In-Reply-To: <48C84F1A-9A8A-4E02-8E32-B171461DC0CC@lrose.de>
On Sat, Jul 06, 2024 at 04:17:30AM GMT, lukaro wrote:
> Hi everyone,
>
> in lsblk, I'm used to seeing the mount point for all devices in an mdadm raid, like so:
>
> sdb 8:16 0 16.4T 0 disk
> └─sdb1 8:17 0 16.4T 0 part
> └─md127 9:127 0 32.8T 0 raid5 /store/RAID_A
> sdc 8:32 0 16.4T 0 disk
> └─sdc1 8:33 0 16.4T 0 part
> └─md127 9:127 0 32.8T 0 raid5 /store/RAID_A
> sdd 8:48 0 16.4T 0 disk
> └─sdd1 8:49 0 16.4T 0 part
> └─md127 9:127 0 32.8T 0 raid5 /store/RAID_A
>
> However, with btrfs raid, the mount point is only shown for the first device:
>
> sdf 8:80 1 7,3T 0 disk
> ├─sdf1 8:81 1 7,3T 0 part
> │ └─video_4b0 254:4 0 7,2T 0 crypt /mnt/video
> └─sdf2 8:82 1 28G 0 part
> sdg 8:96 1 7,3T 0 disk
> ├─sdg1 8:97 1 7,3T 0 part
> │ └─video_5f2 254:5 0 7,2T 0 crypt
> └─sdg2 8:98 1 28G 0 part
> sdh 8:112 1 7,3T 0 disk
> ├─sdh1 8:113 1 7,3T 0 part
> │ └─video_666 254:6 0 7,2T 0 crypt
> └─sdh2 8:114 1 28G 0 part
> sdi 8:128 1 7,3T 0 disk
> ├─sdi1 8:129 1 7,3T 0 part
> │ └─video_9b1 254:7 0 7,2T 0 crypt
> └─sdi2 8:130 1 28G 0 part
>
> Where in the sysfs does lsblk obtain the mount point information?
>
> Is it possible that the btrfs module is lacking this information? I
> would like to understand why lsblk is lacking this information for
> btrfs.
The list of mount points can be found in /proc/self/mountinfo. When
searching for a mount point, lsblk uses the device number (major and
minor) or the device path.
The /proc/self/mountinfo contains a list of unique mount nodes. This
means that the Virtual File System (VFS) of Linux does not have
knowledge of how the filesystems internally implement the RAID.
The mdadm RAID maps all the disks to one virtual device, which is
visible to the system as a normal block device. However, for btrfs,
there is no such thing and all operations are handled internally
within the filesystem.
It would probably be possible to add additional support for btrfs to
lsblk in order to request more details from the filesystem, but this
feature has not been implemented.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox