Re: Can't build 6.6 kernel for x86_64
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Was able to get a build with: --- a/kernel-config +++ b/kernel-config @@ -35,6 +35,8 @@ CONFIG_CHR_DEV_SG=m CONFIG_CLZ_TAB=y CONFIG_COREDUMP=y CONFIG_CRASH_DUMP=y +CONFIG_CRASH_HOTPLUG=y +CONFIG_CRASH_MAX_MEMORY_RANGES=8192 CONFIG_CRYPTO_ABLK_HELPER=y CONFIG_CRYPTO_AKCIPHER=y CONFIG_CRYPTO_AKCIPHER2=y @@ -67,6 +69,8 @@ CONFIG_CRYPTO_HW=y CONFIG_CRYPTO_JITTERENTROPY=y CONFIG_CRYPTO_KPP=y CONFIG_CRYPTO_KPP2=y +# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set +# CONFIG_CRYPTO_MANAGER_EXTRA_TESTS is not set CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_POLY1305=y > On Jul 10, 2024, at 9:55 PM, Philip Prindeville > wrote: > > Hi, > > I rebased Sunday to HEAD on master because it had been over a year since I > updated my firmware, and I'm thinking either the config is broken or I missed > a step. > > I have a env/kernel-config file but after I rebased, reindexed with > "scripts/feeds update -i && scripts/feeds install -a", and did "make > oldconfig defconfig", nothing in my kernel-config seemed to change. > > And when I built, I got this: > > ... > + x86_64-openwrt-linux-musl-ld -m elf_x86_64 -z noexecstack > --no-warn-rwx-segments -z max-page-size=0x20 --build-id=sha1 -X > --orphan-handling=warn --script=./arch/x86/kernel/vmlinux.lds --strip-debug > -o .tmp_vmlinux.kallsyms1 --whole-archive vmlinux.a .vmlinux.export.o > init/version-timestamp.o --no-whole-archive --start-group --end-group > x86_64-openwrt-linux-musl-ld: > drivers/crypto/intel/qat/qat_common/qat_comp_algs.o: in function > `qat_comp_algs_register': > /home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36/drivers/crypto/intel/qat/qat_common/qat_comp_algs.c:478:(.text+0xbec): > undefined reference to `crypto_register_acomps' > x86_64-openwrt-linux-musl-ld: > drivers/crypto/intel/qat/qat_common/qat_comp_algs.o: in function > `qat_comp_algs_unregister': > /home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36/drivers/crypto/intel/qat/qat_common/qat_comp_algs.c:487:(.text+0xc48): > undefined reference to `crypto_unregister_acomps' > make[7]: *** [scripts/Makefile.vmlinux:37: vmlinux] Error 1 > make[6]: *** > [/home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36/Makefile:1164: > vmlinux] Error 2 > make[5]: *** [Makefile:234: __sub-make] Error 2 > make[5]: Leaving directory > '/home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36' > make[4]: *** [Makefile:26: > /home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36/.modules] > Error 2 > make[4]: Leaving directory '/home/philipp/lede/target/linux/x86' > make[3]: *** [Makefile:11: compile] Error 2 > make[3]: Leaving directory '/home/philipp/lede/target/linux' > time: target/linux/compile#2821.60#261.82#3080.51 >ERROR: target/linux failed to build. > make[2]: *** [target/Makefile:32: target/linux/compile] Error 1 > make[2]: Leaving directory '/home/philipp/lede' > make[1]: *** [target/Makefile:25: > /home/philipp/lede/staging_dir/target-x86_64_musl/stamp/.target_compile] > Error 2 > make[1]: Leaving directory '/home/philipp/lede' > make: *** [/home/philipp/lede/include/toplevel.mk:248: world] Error 2 > > > I unset "CONFIG_PACKAGE_kmod-crypto-acompress" in my .config and set > "CONFIG_CRYPTO_ACOMP2=y" in my kernel-config, but no joy. > > What am I missing? And what are the steps to refresh your kernel config > after a rebase? > > Thanks, > > -Philip > --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Can't build 6.6 kernel for x86_64
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, I rebased Sunday to HEAD on master because it had been over a year since I updated my firmware, and I'm thinking either the config is broken or I missed a step. I have a env/kernel-config file but after I rebased, reindexed with "scripts/feeds update -i && scripts/feeds install -a", and did "make oldconfig defconfig", nothing in my kernel-config seemed to change. And when I built, I got this: ... + x86_64-openwrt-linux-musl-ld -m elf_x86_64 -z noexecstack --no-warn-rwx-segments -z max-page-size=0x20 --build-id=sha1 -X --orphan-handling=warn --script=./arch/x86/kernel/vmlinux.lds --strip-debug -o .tmp_vmlinux.kallsyms1 --whole-archive vmlinux.a .vmlinux.export.o init/version-timestamp.o --no-whole-archive --start-group --end-group x86_64-openwrt-linux-musl-ld: drivers/crypto/intel/qat/qat_common/qat_comp_algs.o: in function `qat_comp_algs_register': /home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36/drivers/crypto/intel/qat/qat_common/qat_comp_algs.c:478:(.text+0xbec): undefined reference to `crypto_register_acomps' x86_64-openwrt-linux-musl-ld: drivers/crypto/intel/qat/qat_common/qat_comp_algs.o: in function `qat_comp_algs_unregister': /home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36/drivers/crypto/intel/qat/qat_common/qat_comp_algs.c:487:(.text+0xc48): undefined reference to `crypto_unregister_acomps' make[7]: *** [scripts/Makefile.vmlinux:37: vmlinux] Error 1 make[6]: *** [/home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36/Makefile:1164: vmlinux] Error 2 make[5]: *** [Makefile:234: __sub-make] Error 2 make[5]: Leaving directory '/home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36' make[4]: *** [Makefile:26: /home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36/.modules] Error 2 make[4]: Leaving directory '/home/philipp/lede/target/linux/x86' make[3]: *** [Makefile:11: compile] Error 2 make[3]: Leaving directory '/home/philipp/lede/target/linux' time: target/linux/compile#2821.60#261.82#3080.51 ERROR: target/linux failed to build. make[2]: *** [target/Makefile:32: target/linux/compile] Error 1 make[2]: Leaving directory '/home/philipp/lede' make[1]: *** [target/Makefile:25: /home/philipp/lede/staging_dir/target-x86_64_musl/stamp/.target_compile] Error 2 make[1]: Leaving directory '/home/philipp/lede' make: *** [/home/philipp/lede/include/toplevel.mk:248: world] Error 2 I unset "CONFIG_PACKAGE_kmod-crypto-acompress" in my .config and set "CONFIG_CRYPTO_ACOMP2=y" in my kernel-config, but no joy. What am I missing? And what are the steps to refresh your kernel config after a rebase? Thanks, -Philip --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Issues w/ kexec-tools when building images
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Actually, I *am* selecting kexec which is part of kexec-tools… though I forget why. It might be a hangover from when I was bringing up various x86_64 platforms and I needed to be able to boot into a failsafe kernel if the kernel-under-test hung for whatever reason and the watchdog fired… In any case, it should still build. I’ll dig into it if I get a chance. The suspect part is here: x86_64-openwrt-linux-musl-gcc -mcmodel=large -I./purgatory/include -I./purgatory/arch/x86_64/include -I./util_lib/include -I./include -Iinclude -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-13.2.0_musl/lib/gcc/x86_64-openwrt-linux-musl/13.2.0/include -c -MD -o purgatory/arch/i386/entry32-16.o purgatory/arch/i386/entry32-16.S And looking at the Makefile: https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/purgatory/arch/x86_64/Makefile#n18 that is indeed what it wants. The top-level Makefile says: AS = x86_64-openwrt-linux-musl-gcc -c -Os -pipe -g3 -fno-caller-saves -fno-plt -fhonour-copts -fmacro-prefix-map=/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28=kexec-tools-2.0.28 -ffunction-sections -fdata-sections -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro but that’s not how it’s being built. and no ARCH specific flags are defined: ASFLAGS = $($(ARCH)_ASFLAGS) and the top-level Makefile also has: %.o: %.S @$(MKDIR) -p $(@D) $(COMPILE.S) -MD -o $@ $< so the default definition of COMPILE.S seems to be lacking. At which point I run out of -fu, because I can’t remember how to get “make” to dump its default definitions (i.e. the equivalent of "echo | gcc -dM -E -“ for make). > On May 7, 2024, at 4:25 PM, Enéas Ulir de Queiroz > wrote: > > I’m nowhere close to being able to even check this, but I will give you a > pointer. This usually happens when some Makefile defines multiple packages, > one of them depending on kexec-tools (or any package define in its Makefile), > and another one—which you are selecting—that doesn’t. The build dependencies > are resolved at the Makefile level, so kexec is pulled if any package in that > Makefile is selected. > > To fix this, you can add a PACKAGE_foo: conditional to the kexec-tools > dependency. Then the build dependency will also have that condition, and > kexec-tools will not be built. Look at the OpenSSL Makefile for an example > (taking it from memory). > > Cheers, > > Eneas > >> Em 6 de mai. de 2024, à(s) 17:09, Philip Prindeville via openwrt-devel >> escreveu: >> >> The sender domain has a DMARC Reject/Quarantine policy which disallows >> sending mailing list messages using the original "From" header. >> >> To mitigate this problem, the original message has been wrapped >> automatically by the mailing list software. >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Issues w/ kexec-tools when building images (redux)
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, Sorry, had to add filters to turn DMARC off when sending mailing list mail…. I fetched/rebased recently and now I’m not able to build images. It fails in kexec-tools, which is odd, because that’s not selected and nothing depends on it. philipp@ubuntu22:~/lede$ grep kexec-tools .config # CONFIG_PACKAGE_kexec-tools is not set philipp@ubuntu22:~/lede$ Here’s how the build reliably fails: make[3]: Entering directory '/home/philipp/lede/package/boot/kexec-tools' rm -f /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built touch /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built_check make -C /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28 DESTDIR="/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/ipkg-install" all install make[4]: Entering directory '/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28' x86_64-openwrt-linux-musl-gcc -mcmodel=large -I./purgatory/include -I./purgatory/arch/x86_64/include -I./util_lib/include -I./include -Iinclude -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-13.2.0_musl/lib/gcc/x86_64-openwrt-linux-musl/13.2.0/include -c -MD -o purgatory/arch/i386/entry32-16.o purgatory/arch/i386/entry32-16.S purgatory/arch/i386/entry32-16.S: Assembler messages: purgatory/arch/i386/entry32-16.S:23: Error: 64bit mode not supported on `i386'. make[4]: *** [Makefile:128: purgatory/arch/i386/entry32-16.o] Error 1 make[4]: Leaving directory '/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28' make[3]: *** [Makefile:133: /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built] Error 2 make[3]: Leaving directory '/home/philipp/lede/package/boot/kexec-tools' time: package/boot/kexec-tools/compile#0.23#0.07#0.27 ERROR: package/boot/kexec-tools failed to build. make[2]: *** [package/Makefile:129: package/boot/kexec-tools/compile] Error 1 I’m building for x86_64/generic on HEAD. Any ideas? And who is the maintainer for kexec-tools? Thanks, -Philip --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Issues w/ kexec-tools when building images
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, I fetched/rebased recently and now I’m not able to build images. It fails in kexec-tools, which is odd, because that’s not selected and nothing depends on it. philipp@ubuntu22:~/lede$ grep kexec-tools .config # CONFIG_PACKAGE_kexec-tools is not set philipp@ubuntu22:~/lede$ Here’s how the build reliably fails: make[3]: Entering directory '/home/philipp/lede/package/boot/kexec-tools' rm -f /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built touch /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built_check make -C /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28 DESTDIR="/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/ipkg-install" all install make[4]: Entering directory '/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28' x86_64-openwrt-linux-musl-gcc -mcmodel=large -I./purgatory/include -I./purgatory/arch/x86_64/include -I./util_lib/include -I./include -Iinclude -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-13.2.0_musl/lib/gcc/x86_64-openwrt-linux-musl/13.2.0/include -c -MD -o purgatory/arch/i386/entry32-16.o purgatory/arch/i386/entry32-16.S purgatory/arch/i386/entry32-16.S: Assembler messages: purgatory/arch/i386/entry32-16.S:23: Error: 64bit mode not supported on `i386'. make[4]: *** [Makefile:128: purgatory/arch/i386/entry32-16.o] Error 1 make[4]: Leaving directory '/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28' make[3]: *** [Makefile:133: /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built] Error 2 make[3]: Leaving directory '/home/philipp/lede/package/boot/kexec-tools' time: package/boot/kexec-tools/compile#0.23#0.07#0.27 ERROR: package/boot/kexec-tools failed to build. make[2]: *** [package/Makefile:129: package/boot/kexec-tools/compile] Error 1 I’m building for x86_64/generic on HEAD. Any ideas? And who is the maintainer for kexec-tools? Thanks, -Philip --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Issues w/ kexec-tools when building images
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, I fetched/rebased recently and now I’m not able to build images. It fails in kexec-tools, which is odd, because that’s not selected and nothing depends on it. philipp@ubuntu22:~/lede$ grep kexec-tools .config # CONFIG_PACKAGE_kexec-tools is not set philipp@ubuntu22:~/lede$ Here’s how the build reliably fails: make[3]: Entering directory '/home/philipp/lede/package/boot/kexec-tools' rm -f /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built touch /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built_check make -C /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28 DESTDIR="/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/ipkg-install" all install make[4]: Entering directory '/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28' x86_64-openwrt-linux-musl-gcc -mcmodel=large -I./purgatory/include -I./purgatory/arch/x86_64/include -I./util_lib/include -I./include -Iinclude -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-13.2.0_musl/lib/gcc/x86_64-openwrt-linux-musl/13.2.0/include -c -MD -o purgatory/arch/i386/entry32-16.o purgatory/arch/i386/entry32-16.S purgatory/arch/i386/entry32-16.S: Assembler messages: purgatory/arch/i386/entry32-16.S:23: Error: 64bit mode not supported on `i386'. make[4]: *** [Makefile:128: purgatory/arch/i386/entry32-16.o] Error 1 make[4]: Leaving directory '/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28' make[3]: *** [Makefile:133: /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built] Error 2 make[3]: Leaving directory '/home/philipp/lede/package/boot/kexec-tools' time: package/boot/kexec-tools/compile#0.23#0.07#0.27 ERROR: package/boot/kexec-tools failed to build. make[2]: *** [package/Makefile:129: package/boot/kexec-tools/compile] Error 1 I’m building for x86_64/generic on HEAD. Any ideas? And who is the maintainer for kexec-tools? Thanks, -Philip --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Scripting question how to filter list of files based on globs
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > On Apr 9, 2024, at 6:03 PM, Paul D wrote: > > On 2024-04-09 23:30, Philip Prindeville via openwrt-devel wrote: >> I'm trying to modify a script generates a list of filenames one per >> line, but should be filtered against a blacklist of file globs. >> >> Something like: >> >> % find dir -print | grep -v -f blacklist > > > I got this. When I run it on the openwrt source, where package is the > packages directory: > > Vanilla Output > > find package -type f -print > > === > ... > package/utils/uencrypt/src/CMakeLists.txt > package/utils/uencrypt/src/uencrypt-mbedtls.c > package/utils/uencrypt/src/uencrypt-openssl.c > package/utils/uencrypt/src/uencrypt.c > package/utils/uencrypt/src/uencrypt.h > package/utils/uencrypt/Makefile > package/utils/zyxel-bootconfig/Makefile > package/utils/zyxel-bootconfig/files/95_apply_bootconfig > package/utils/zyxel-bootconfig/src/Makefile > package/utils/zyxel-bootconfig/src/zyxel-bootconfig.c > package/utils/ucode-mod-bpf/Makefile > package/utils/ucode-mod-bpf/src/bpf.c > package/utils/firmware-utils/Makefile > package/utils/yafut/Makefile > package/utils/debugcc/Makefile > === > > > Exclude 'Makefile's > > find package -type f -name 'Makefile' -prune -o -type f -print > > === > ... > package/utils/util-linux/patches/001-meson-properly-handle-gettext-non-existence.patch > package/utils/uencrypt/src/CMakeLists.txt > package/utils/uencrypt/src/uencrypt-mbedtls.c > package/utils/uencrypt/src/uencrypt-openssl.c > package/utils/uencrypt/src/uencrypt.c > package/utils/uencrypt/src/uencrypt.h > package/utils/zyxel-bootconfig/files/95_apply_bootconfig > package/utils/zyxel-bootconfig/src/zyxel-bootconfig.c > package/utils/ucode-mod-bpf/src/bpf.c > === > > Exclude Makefiles and c files > > find package -type f -name 'Makefile' -o -name '*.c' -prune -o -type f -print > > === > ... > package/utils/util-linux/patches/001-meson-properly-handle-gettext-non-existence.patch > package/utils/uencrypt/src/CMakeLists.txt > package/utils/uencrypt/src/uencrypt.h > package/utils/zyxel-bootconfig/files/95_apply_bootconfig > === > > Exclude Makefiles and c files and patch files > > > find package -type f -name 'Makefile' -o -name '*.c' -o -name '*.patch' > -prune -o -type f -print > === > ... > package/utils/uencrypt/src/CMakeLists.txt > package/utils/uencrypt/src/uencrypt.h > package/utils/zyxel-bootconfig/files/95_apply_bootconfig > === > > find package -type f -name 'Makefile' -o -type d -name 'utils' -prune -o > -type f -print > > === > ... > === > > > Set your -type accordingly. The issue is that the pattern of names to exclude is user-defined, so we don't know it in advance. -Philip --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Scripting question how to filter list of files based on globs
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, I'm trying to modify a script generates a list of filenames one per line, but should be filtered against a blacklist of file globs. Something like: % find dir -print | grep -v -f blacklist if this were a version of grep that understood shell-style globs instead of basic regular expressions. Worst case I could try to mangle the globs patterns into regular-expressions, but I was hoping for something simpler. Any ideas? Thanks, -Philip --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Scripting question how to filter list of files based on globs
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, I'm trying to modify a script generates a list of filenames one per line, but should be filtered against a blacklist of file globs. Something like: % find dir -print | grep -v -f blacklist if this were a version of grep that understood shell-style globs instead of basic regular expressions. Worst case I could try to mangle the globs patterns into regular-expressions, but I was hoping for something simpler. Any ideas? Thanks, -Philip --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Migrating ISC to Kea DHCP blocked on related PR's
> On Dec 11, 2023, at 5:49 AM, Paul D wrote: > > On 2023-12-09 23:47, Philip Prindeville wrote: >> Hi all, >> I'm working on a drop-in for Kea that will parse existing ISC-DHCP >> configurations in UCI and crank out the derivative JSON config files for >> Kea, but I have a couple of PR's that are necessary to making this happen >> that have been pending for several weeks: >> https://github.com/openwrt/openwrt/pull/13765 >> https://github.com/openwrt/libubox/pull/6 > > For those who don't know: Kea DHCP is ISC's replacement for its own ISC DHCP > daemon. ISC DHCP reached end of life 2022. Yes, thanks for pointing that out. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Migrating ISC to Kea DHCP blocked on related PR's
Hi all, I'm working on a drop-in for Kea that will parse existing ISC-DHCP configurations in UCI and crank out the derivative JSON config files for Kea, but I have a couple of PR's that are necessary to making this happen that have been pending for several weeks: https://github.com/openwrt/openwrt/pull/13765 https://github.com/openwrt/libubox/pull/6 The first PR takes the original ipcalc.sh (which, despite its name, was an AWK script for calculating subnet ranges for DHCP pools) and rewrites it both as a Shell library for manipulating IP addresses, subnets, masks, prefixes, etc. as well as a front-end ipcalc.sh that leverages this library and provides the original functionality of ipcalc.sh for scripts still requiring such. The need to rewrite as a library was so that better error checking could be done in the initialization script for Kea, as well as the need to associate host leases back to their relevant subnet (since reservations are more efficiently done on per-interface basis, than globally, which doesn't scale up). The 2nd PR includes improvements to libubox's jshn.sh, in particular the ability to save the "cursor" as one builds multiple empty tables, and then come back to them (by repositioning the cursor) on a subsequent pass to populate them. As you probably guessed, interface tables as created in one pass in the Kea init.d script, and then the host reservations are plugged into them after the reserved address is mapped back to the corresponding subnet/interface pair on the 2nd pass. This requires "warping" the cursor to the appropriate table, as there is no requirement for ordering of DHCP host reservations vis-a-vis DHCP subnet definitions, etc. Small COTS WAP's and low-cost routers might be good candidates for dnsmasq, but there are a lot of people using 1U x86_64 or ARM64 pizza boxes with a half dozen or more interfaces in a medium-sized or even branch enterprise scenario who run ISC-DHCP (and soon, hopefully, Kea). Help me support those users by reviewing these PRs so I can move them forward to merger. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Best practices for shell libraries (specifically error-checking)
Hi all,
I'm trying to figure out what best practices are for shell libraries, as I'm
working on changes to a pretty significant library which I envision being
leveraged in a lot of places.
My questions are these:
* should a good library do error-checking for the caller, or expect the caller
to have done his own validation? Given that most exploits are the result in
insufficient input validation (more than 60% according to a study by the SEI),
it seems that the library should do it. Also, it's one-and-done, rather than
duplicating error-checking in all the places that the library might be used.
And if a missing check is uncovered later? I'd rather have one place to patch
it than many.
* in my case, the library has both predicate tests that do validation and their
only output is a true/false return value, as well as functions that perform a
calculation on their inputs and echo an output to stdout. So there's a mix of:
if ! is_validity_check "$myarg"; then
# do some stuff
fi
as well as:
var="$(compute_something "$n" "$m")"
and it's this later that is a little more thorny. The issue is that we're
capturing itss output, but if it's also performing error-checking, then this
will happen in a sub shell and the only way to indicate failure is either to
generate no output, or to check the exit value of the sub shell. So we can do:
var="$(compute_something "$n" "$m")"
if [ -z "$var" ]; then
# handle the error
fi
or else:
var="$(compute_something "$n" "$m")" || { # handle the error ; }
And I'm inclined to go with the later, it's less wordy and the handling can
often be something like a function that takes an argument which it then echos
to stderr, and then exits non-zero. Easy-peasy and simple to read and
understand.
The hard part is when this function that writes its result to standard output
is being used in a different, uncommon way that things get complicate. Like:
( compute_something "$n" "$m" >> something.conf ) || { # handle the error ;
}
where they aren't invoking the function via a sub shell unless they do so
explicitly (and they might not have read the functions or accompanying comments
and be aware of how to use them safely).
* so then there's a third option. Always return a true/false status code,
don't emit anything to standard output, and just set some unlikely global
variables like __compute_something_ret_val1, etc. Ugly, but potentially less
disastrous if not invoked properly... but the flip-side is that the user might
not check return values and continue on his bliss, perilous way. It also
avoids fork/exec pairs and everything runs in a single process, so that's nice
(as an aside, an enhancement to shell might have been to have $(...) run in a
separate thread if it only used built-ins, and you could still use a pipe to
capture its output).
Yeah, shell is a 40+ year old language that we're asking to do more than it was
ever intended to do. It would have been nice if in the last 20 years someone
had come up with a way to add new built-in functions via .so plugins that
provided language extensions. But they didn't and that's not on option.
What is the collective wisdom? Coming from a security coding background, I
prefer to make things blow up on invalid input unless the user (caller) takes
steps to recover meaningfully from that failure.
But if I write a library that no one wants to use, then what's the purpose of
that?
I put it to you: what's the best practice for writing shell libraries for
OpenWRT and the limitations of busybox shell.
Thanks,
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
> On Nov 13, 2023, at 10:44 PM, Elliott Mitchell wrote: > > On Tue, Nov 14, 2023 at 03:44:57AM +, Daniel Golle wrote: >> On Mon, Nov 13, 2023 at 06:26:04PM -0800, Elliott Mitchell wrote: >>> On Mon, Nov 13, 2023 at 12:48:14PM +, Daniel Golle wrote: On Mon, Nov 13, 2023 at 01:30:10PM +0100, Paul Spooren wrote: > > How about we follow the approach of Alpine Linux[1] and offer a standard, > an extended and a virtual firmware for the x86/64 target? > > What packages specifically is another discussion but the approach could > be that standard contains all kmods to get network working on all device, > extended includes extra LED drivers etc and virtual only contains network > drivers for, well, virtual things. +1 I like that much more than adding board-specific images on a platform with standardized boot process (such as x86 or armsr). >>> >>> Are you stating you're planning to modify OpenWRT's boot process to >>> match the standard way of dealing with that standardized boot process? >>> Mainly, using a minimal kernel and then using an initial ramdisk to >>> load device drivers as appropriate to the hardware. >> >> Using squashfs (which is what we are doing) has actually quite >> a similar effect than using initramfs. Filesystem cache of files which >> aren't accessed gets freed. >> >> What is missing is hotplug-based loading of kmods based on present >> devices -- right now every module present gets loaded and remains >> loaded indefinitely even if the hardware isn't present. > > First, an initial ramdisk allows the kernel to not include any block > drivers, but instead load them during boot. ie a VM build could include > drivers for interacting with every hypervisor, but only load the ones > for the hypervisor in use. > > Second, while suboptimal having those drivers as modules allows them to > be unloaded. If the drivers for every hypervisor were unconditionally > loaded, the inappropriate ones might be unloaded by /etc/rc.local. > > >>> Each hypervisor will have a small set of drivers guaranteed to be >>> present. These though will be completely different between hypervisors. >> >> Do you really think having just the (partially shared) drivers for 3 >> hypervisors (KVM/virtio, Hyper-V, VMWare) present in one image is too >> much? Those drivers are very tiny... > > Permanently built into the kernel? Not acceptable. Every once-in-a-while a vulnerable driver is discovered that is a CVE even when it's not active. Having the modules linked in makes it harder to blacklist their initialization. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
> On Nov 13, 2023, at 7:26 PM, Elliott Mitchell wrote: > > On Mon, Nov 13, 2023 at 12:48:14PM +, Daniel Golle wrote: >> On Mon, Nov 13, 2023 at 01:30:10PM +0100, Paul Spooren wrote: >>> >>> How about we follow the approach of Alpine Linux[1] and offer a standard, >>> an extended and a virtual firmware for the x86/64 target? >>> >>> What packages specifically is another discussion but the approach could be >>> that standard contains all kmods to get network working on all device, >>> extended includes extra LED drivers etc and virtual only contains network >>> drivers for, well, virtual things. >> >> +1 >> I like that much more than adding board-specific images on a platform >> with standardized boot process (such as x86 or armsr). > > [...] > > The real issue is VMs are unlikely to see devices typically present on > bare metal computers. Thermal capabilities? Nope. Processor frequency > selection? Nope. Microcode reloading? Nope. > > Each hypervisor will have a small set of drivers guaranteed to be > present. These though will be completely different between hypervisors. With KVM and kmod-vfio-pci you can do reverse-pass thru where the host isn't controlling the hardware but the guest is. I know some people who do this to test WiFi drivers from KVM guests. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
> On Sep 14, 2023, at 5:19 PM, Stefan Lippers-Hollmann wrote:
>
> Hi
>
> On 2023-09-14, Paul Spooren wrote:
>> Hi,
>>
>> I’d like to merge the PR which adds the Mellanox Spectrum SN2100 to
>> OpenWrt[1]. In its current state a new x86 image would be added next
>> to the generic x86 image. Another approach is to add all related
>> packages to the default image. Either way creates a working image.
>>
>> I remember that people were complaining about a “bloated” x86 image
>> which slows down their container/VM needs. So what would be a simple
>> way forward here?
> [...]
>
> If at all reasonably possible (assuming the size increase is roughly in
> the ball park of 1-2 MB for the total image), I'd suggest to stick to a
> single x86_64 image for maintenance and testing reasons alone. The bump
> of the x86 targets to kernel v6.1 -while easy- is mostly stalled due to
> there being three 32 bit x86 sub-targets and the need to go through the
> kernel config rebase three times, which is wearing thin the patience and
> motivation of doing so (x86_64 alone would have been ready >2 months
> ago). Unless these SN2100 devices suddenly become a cheap commodity and
> ubiquitous among OpenWrt developers and -users, I fear that it would
> just add to this churn and pretty much rot away in the tree, while at
> the same time making progress harder for the other x86{,_64} devices.
>
> Regards
> Stefan Lippers-Hollmann
Sometime back I tried to add "pcituils" and "usbutils" to the generic x86_64
image, and was told that they weren't sufficiently "ubiquitous" to add to the
default image.
I note that they can be removed from the BOM easily by doing:
DEVICE_PACKAGES += -pciutils -usbutils
And that would remove them if they were already present in $(DEVICE_PACKAGES).
I've never encountered an x86_64 platform that didn't have both USB and PCI, as
they've without question become a "cheap commodity".
Contrarily, I've yet to own or operate a platform that has a Mellanox switch.
This seems arbitrary.
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86 64: Add new device Cordoba Edge Platform
That’s a question for a core maintainer. I’m just a lowly package maintainer. > On Oct 29, 2023, at 10:29 PM, Xiaojun Liu wrote: > > Hi Philip, > > Thank you! Do you know when it will be merged to Openwrt main thread ? > > -Original Message- > From: Philip Prindeville > Sent: Saturday, October 28, 2023 11:09 AM > To: Xiaojun Liu > Cc: openwrt-devel@lists.openwrt.org > Subject: Re: [PATCH] x86 64: Add new device Cordoba Edge Platform > > LGTM > > >> On Oct 23, 2023, at 8:52 PM, Xiaojun Liu wrote: >> >> Add new device Cordoba Edge Platform >> Device name:Cordoba Edge Platform >> hardware specifications: CPU - Intel Atom C3000 >> WiFi - mt7915e >> >> Signed-off-by: Xiaojun Liu mailto:xiaojun@silicom.co.il >> --- >> >> target/linux/x86/base-files/etc/board.d/02_network | 11 +++ >> target/linux/x86/image/64.mk | 10 ++ >> 2 files changed, 21 insertions(+) >> >> >> diff --git a/target/linux/x86/base-files/etc/board.d/02_network >> b/target/linux/x86/base-files/etc/board.d/02_network >> index e00e8c04dd..be56153695 100644 >> --- a/target/linux/x86/base-files/etc/board.d/02_network >> +++ b/target/linux/x86/base-files/etc/board.d/02_network >> @@ -75,6 +75,17 @@ traverse-technologies-geos) >>macaddr="$(cat /sys/class/net/eth0/address)" 2>/dev/null >>[ -n "$macaddr" ] && ucidef_set_interface_macaddr "wan" "$macaddr" >>;; >> +silicom-80500-0214-e53) >> +ucidef_set_network_device_path "wan0" >> "pci:00/:00:16.0/:03:00.0" >> +ucidef_set_network_device_path "wan1" >> "pci:00/:00:16.0/:03:00.1" >> +ucidef_set_network_device_path "media0" >> "pci:00/:00:17.0/:02:00.0" >> +ucidef_set_network_device_path "media1" >> "pci:00/:00:17.0/:02:00.1" >> +ucidef_set_network_device_path "eth0" >> "pci:00/:00:0c.0/:04:00.0" >> +ucidef_set_network_device_path "eth1" >> "pci:00/:00:0e.0/:05:00.0" >> +ucidef_set_network_device_path "eth2" >> "pci:00/:00:0f.0/:06:00.0" >> +ucidef_set_network_device_path "eth3" >> "pci:00/:00:10.0/:07:00.0" >> +ucidef_set_interfaces_lan_wan "eth0 eth1 eth2 eth3" "wan0" >> +;; >> esac >> board_config_flush >> >> diff --git a/target/linux/x86/image/64.mk >> b/target/linux/x86/image/64.mk index 5ec9978b66..4aeb98 100644 >> --- a/target/linux/x86/image/64.mk >> +++ b/target/linux/x86/image/64.mk >> @@ -8,3 +8,13 @@ define Device/generic >> GRUB2_VARIANT := generic >> endef >> TARGET_DEVICES += generic >> + >> +define Device/cordoba >> + DEVICE_VENDOR := Cordoba >> + DEVICE_MODEL := x86/64 >> + DEVICE_PACKAGES += \ >> +kmod-igc kmod-ixgbe \ >> +kmod-mt7915-firmware >> + GRUB2_VARIANT := generic >> +endef >> +TARGET_DEVICES += cordoba >> >> > Platform.patch>___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist >> s.openwrt.org%2Fmailman%2Flistinfo%2Fopenwrt-devel&data=05%7C01%7Cxiao >> jun.liu%40silicom.co.il%7C72c892dafba644e13de108dbd76352b5%7Cc9e326d8c >> e4749308612cc99d3c87ad1%7C0%7C0%7C638340593816809713%7CUnknown%7CTWFpb >> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >> %3D%7C3000%7C%7C%7C&sdata=iJGXzXkBnJaAuGcu3OrZSPxVeE1WvC2h7w4%2F3t2bLj >> Q%3D&reserved=0 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86 64: Add new device Cordoba Edge Platform
> On Oct 30, 2023, at 11:17 AM, Paul Spooren wrote: > > Hi, > > We kind of don’t add image just to contain extra drivers. Extra UCI defaults > for eth ordering are fine but please don’t add an extra image if it just > contains 1-2 extra packages, installable via the ImageBuilder or OPKG. > >> >>> On Oct 23, 2023, at 8:52 PM, Xiaojun Liu wrote: >>> >>> Add new device Cordoba Edge Platform >>> Device name:Cordoba Edge Platform >>> hardware specifications: CPU - Intel Atom C3000 >>>WiFi - mt7915e >>> >>> Signed-off-by: Xiaojun Liu mailto:xiaojun@silicom.co.il >>> --- >>> >>> target/linux/x86/base-files/etc/board.d/02_network | 11 +++ >>> target/linux/x86/image/64.mk | 10 ++ >>> 2 files changed, 21 insertions(+) >>> >>> >>> diff --git a/target/linux/x86/base-files/etc/board.d/02_network >>> b/target/linux/x86/base-files/etc/board.d/02_network >>> index e00e8c04dd..be56153695 100644 >>> --- a/target/linux/x86/base-files/etc/board.d/02_network >>> +++ b/target/linux/x86/base-files/etc/board.d/02_network >>> @@ -75,6 +75,17 @@ traverse-technologies-geos) >>> macaddr="$(cat /sys/class/net/eth0/address)" 2>/dev/null >>> [ -n "$macaddr" ] && ucidef_set_interface_macaddr "wan" "$macaddr" >>> ;; >>> +silicom-80500-0214-e53) >>> +ucidef_set_network_device_path "wan0" >>> "pci:00/:00:16.0/:03:00.0" >>> +ucidef_set_network_device_path "wan1" >>> "pci:00/:00:16.0/:03:00.1" >>> +ucidef_set_network_device_path "media0" >>> "pci:00/:00:17.0/:02:00.0" >>> +ucidef_set_network_device_path "media1" >>> "pci:00/:00:17.0/:02:00.1" >>> +ucidef_set_network_device_path "eth0" >>> "pci:00/:00:0c.0/:04:00.0" >>> +ucidef_set_network_device_path "eth1" >>> "pci:00/:00:0e.0/:05:00.0" >>> +ucidef_set_network_device_path "eth2" >>> "pci:00/:00:0f.0/:06:00.0" >>> +ucidef_set_network_device_path "eth3" >>> "pci:00/:00:10.0/:07:00.0" >>> +ucidef_set_interfaces_lan_wan "eth0 eth1 eth2 eth3" "wan0" >>> +;; >>> esac >>> board_config_flush >>> >>> diff --git a/target/linux/x86/image/64.mk >>> b/target/linux/x86/image/64.mk index 5ec9978b66..4aeb98 100644 >>> --- a/target/linux/x86/image/64.mk >>> +++ b/target/linux/x86/image/64.mk >>> @@ -8,3 +8,13 @@ define Device/generic >>> GRUB2_VARIANT := generic >>> endef >>> TARGET_DEVICES += generic >>> + >>> +define Device/cordoba >>> + DEVICE_VENDOR := Cordoba >>> + DEVICE_MODEL := x86/64 >>> + DEVICE_PACKAGES += \ >>> +kmod-igc kmod-ixgbe \ >>> +kmod-mt7915-firmware >>> + GRUB2_VARIANT := generic >>> +endef >>> +TARGET_DEVICES += cordoba > > Please remove those lines in 64.mk. > > Thanks for you work and interest in OpenWrt support for your device. > > Best, > Paul I’m not sure I understand why. Would you want someone to build the image and leave out the necessary drivers? They’re more than just “extra packages”, they’re *essential* packages. We have hundreds of profiles for other architectures, even different profiles for different versions of the same base design (like Archer C7). Why are we so miserly when it comes to x86_64? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86 64: Add new device Cordoba Edge Platform
LGTM > On Oct 23, 2023, at 8:52 PM, Xiaojun Liu wrote: > > Add new device Cordoba Edge Platform > Device name:Cordoba Edge Platform > hardware specifications: CPU - Intel Atom C3000 > WiFi - mt7915e > > Signed-off-by: Xiaojun Liu mailto:xiaojun@silicom.co.il > --- > > target/linux/x86/base-files/etc/board.d/02_network | 11 +++ > target/linux/x86/image/64.mk | 10 ++ > 2 files changed, 21 insertions(+) > > > diff --git a/target/linux/x86/base-files/etc/board.d/02_network > b/target/linux/x86/base-files/etc/board.d/02_network > index e00e8c04dd..be56153695 100644 > --- a/target/linux/x86/base-files/etc/board.d/02_network > +++ b/target/linux/x86/base-files/etc/board.d/02_network > @@ -75,6 +75,17 @@ traverse-technologies-geos) > macaddr="$(cat /sys/class/net/eth0/address)" 2>/dev/null > [ -n "$macaddr" ] && ucidef_set_interface_macaddr "wan" "$macaddr" > ;; > +silicom-80500-0214-e53) > +ucidef_set_network_device_path "wan0" > "pci:00/:00:16.0/:03:00.0" > +ucidef_set_network_device_path "wan1" > "pci:00/:00:16.0/:03:00.1" > +ucidef_set_network_device_path "media0" > "pci:00/:00:17.0/:02:00.0" > +ucidef_set_network_device_path "media1" > "pci:00/:00:17.0/:02:00.1" > +ucidef_set_network_device_path "eth0" > "pci:00/:00:0c.0/:04:00.0" > +ucidef_set_network_device_path "eth1" > "pci:00/:00:0e.0/:05:00.0" > +ucidef_set_network_device_path "eth2" > "pci:00/:00:0f.0/:06:00.0" > +ucidef_set_network_device_path "eth3" > "pci:00/:00:10.0/:07:00.0" > +ucidef_set_interfaces_lan_wan "eth0 eth1 eth2 eth3" "wan0" > +;; > esac > board_config_flush > > diff --git a/target/linux/x86/image/64.mk b/target/linux/x86/image/64.mk > index 5ec9978b66..4aeb98 100644 > --- a/target/linux/x86/image/64.mk > +++ b/target/linux/x86/image/64.mk > @@ -8,3 +8,13 @@ define Device/generic >GRUB2_VARIANT := generic > endef > TARGET_DEVICES += generic > + > +define Device/cordoba > + DEVICE_VENDOR := Cordoba > + DEVICE_MODEL := x86/64 > + DEVICE_PACKAGES += \ > +kmod-igc kmod-ixgbe \ > +kmod-mt7915-firmware > + GRUB2_VARIANT := generic > +endef > +TARGET_DEVICES += cordoba > > Platform.patch>___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CI/CD failures on non-x86 platforms
Thought I sent this earlier but I see no trace of it, so here goes again. Here it is again with the link to the build and the extracted logs from one of the failing builds: https://github.com/openwrt/packages/actions/runs/6629645917/job/18009391257?pr=22359 CFLAGS="-Os -pipe -mcpu=8548 -fno-caller-saves -fno-plt -fhonour-copts -msoft-float -ffile-prefix-map=/builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0=cligen-6.4.0 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/usr/include -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/include -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/include/fortify " CXXFLAGS="-Os -pipe -mcpu=8548 -fno-caller-saves -fno-plt -fhonour-copts -msoft-float -ffile-prefix-map=/builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0=cligen-6.4.0 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/usr/include -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/include -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/include/fortify " LDFLAGS="-L/bu ilder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/usr/lib -L/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/lib -fuse-ld=bfd -znow -zrelro " make -C /builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0/. AR="powerpc-openwrt-linux-musl-gcc-ar" AS="powerpc-openwrt-linux-musl-gcc -c -Os -pipe -mcpu=8548 -fno-caller-saves -fno-plt -fhonour-copts -msoft-float -ffile-prefix-map=/builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0=cligen-6.4.0 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro" LD="powerpc-openwrt-linux-musl-ld.bfd" NM="powerpc-openwrt-linux-musl-gcc-nm" CC="powerpc-openwrt-linux-musl-gcc" GCC="powerpc-openwrt-linux-musl-gcc" CXX="powerpc-openwrt-linux-musl-g++" RANLIB="powerpc-openwrt-linux-musl-gcc-ranlib" STRIP=powerpc-openwrt-linux-musl-strip OBJCOPY=powerpc-openwrt-linux-musl-objcopy OBJDUMP=powerpc-openwrt-linux-musl-objdump SIZE=powerpc-openwrt-linux-musl-size CROSS="powerpc-openwrt-linux-musl-" ARCH="powerpc" DESTDIR="/builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0/ipkg-install" install; make[3]: Entering directory '/builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0' echo "/* This file is generated from the CLIgen Makefile */" > build.c; date +"const char CLIGEN_BUILDSTR[49]=\"%Y.%m.%d %H:%M by `whoami` on `hostname`"\"\; >> build.c; echo "const char CLIGEN_VERSION[64]=\"6.4.0\""\; >> build.c; powerpc-openwrt-linux-musl-gcc -I. -I. -DHAVE_CONFIG_H -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/usr/include -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/include -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/include/fortify -fPIC -Os -pipe -mcpu=8548 -fno-caller-saves -fno-plt -fhonour-copts -msoft-float -ffile-prefix-map=/builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0=cligen-6.4.0 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -c build.c powerpc-openwrt-linux-musl-gcc -shared -o libcligen.so.6.4 cligen_object.o cligen_callback.o cligen_parsetree.o cligen_pt_head.o cligen_handle.o cligen_cv.o cligen_match.o cligen_result.o cligen_read.o cligen_io.o cligen_expand.o cligen_syntax.o cligen_print.o cligen_cvec.o cligen_buf.o cligen_util.o cligen_history.o cligen_regex.o cligen_getline.o build.o lex.cligen_parse.o cligen_parse.tab.o -L/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/usr/lib -L/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/lib -fuse-ld=bfd -znow -zrelro -Wl,-soname=libcligen.so.6.4 -L. file libcligen.so.6.4 libcligen.so.6.4: ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, with debug_info, not stripped /builder/staging_dir/host/bin/install -c -m 0755 -d /builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0/ipkg-install/usr/lib /builder/staging_dir/host/bin/install -c -m 0644 -s libcligen.so.6.4 /builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0/ipkg-install/usr/lib strip: Unable to recognise the format of the input file `/builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0/ipkg-install/usr/lib/libcligen.so.6.4' /builder/staging_dir/host/bin/install: strip process terminated abnormally make[3]: *** [Makefile:158: install-lib] Error 1 > On Oct 24, 2023, at 8:49 AM, Robert Marko wrote: > > On Tue, 24 Oct 2023 at 17:46, Philip Prindeville > wrote: >> >> Hi, >> >> I&
CI/CD failures on non-x86 platforms
Hi, I'm seeing the following: https://github.com/openwrt/packages/actions/runs/6621741418/job/17986176198?pr=22362 Specifically: mips-openwrt-linux-musl-gcc -shared -o libcligen.so.6.4 cligen_object.o cligen_callback.o cligen_parsetree.o cligen_pt_head.o cligen_handle.o cligen_cv.o cligen_match.o cligen_result.o cligen_read.o cligen_io.o cligen_expand.o cligen_syntax.o cligen_print.o cligen_cvec.o cligen_buf.o cligen_util.o cligen_history.o cligen_regex.o cligen_getline.o build.o lex.cligen_parse.o cligen_parse.tab.o -L/builder/staging_dir/toolchain-mips_24kc_gcc-12.3.0_musl/usr/lib -L/builder/staging_dir/toolchain-mips_24kc_gcc-12.3.0_musl/lib -fuse-ld=bfd -znow -zrelro -Wl,-soname=libcligen.so.6.4 -L. /builder/staging_dir/host/bin/install -c -m 0755 -d /builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/ipkg-install/usr/lib /builder/staging_dir/host/bin/install -c -m 0644 -s libcligen.so.6.4 /builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/ipkg-install/usr/lib strip: Unable to recognise the format of the input file `/builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/ipkg-install/usr/lib/libcligen.so.6.4' /builder/staging_dir/host/bin/install: strip process terminated abnormally make[3]: Leaving directory '/builder/build_dir/target-mips_24kc_musl/cligen-6.4.0' make[3]: *** [Makefile:157: install-lib] Error 1 make[2]: *** [Makefile:60: /builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/.built] Error 2 It looks like it's running on an x86_64 but the version of "install" doesn't understand MIPS binaries. Is that what's happening? And why is it only affecting me? There's nothing particular about my packaging: https://github.com/pprindeville/packages/blob/clixon-initial/utils/clixon/Makefile What am I missing? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Subject: [PATCH] x86 64: Add new device Cordoba Edge Platform
Doesn't this just have ixgbe and igc NIC's? And the mt7915e of course. Don't think we need the amd-xgbe, bnx2, e1000e, e1000, r8169, tg3 drivers. The BIOS we've been using has some odd enumeration of the PCI bus, so you might want to include a patch for target/linux/x86/base-files/etc/board.d/02_network And bind the PCI addresses to the ethernet device names. > On Oct 18, 2023, at 8:44 PM, Xiaojun Liu wrote: > > Add new device Cordoba Edge Platform > Device name: Cordoba Edge Platform > hardware specifications: CPU - Intel Atom C3000 > WiFi - mt7915e > > Signed-off-by: Xiaojun Liu mailto:xiaojun@silicom.co.il > --- > target/linux/x86/image/64.mk | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/target/linux/x86/image/64.mk b/target/linux/x86/image/64.mk > index 5ec9978b66..04ce0be13a 100644 > --- a/target/linux/x86/image/64.mk > +++ b/target/linux/x86/image/64.mk > @@ -8,3 +8,14 @@ define Device/generic >GRUB2_VARIANT := generic > endef > TARGET_DEVICES += generic > + > +define Device/cordoba > + DEVICE_VENDOR := Cordoba > + DEVICE_MODEL := x86/64 > + DEVICE_PACKAGES += \ > +kmod-amazon-ena kmod-amd-xgbe kmod-bnx2 kmod-e1000e kmod-e1000 \ > +kmod-forcedeth kmod-fs-vfat kmod-igb kmod-igc kmod-ixgbe kmod-r8169 \ > +kmod-tg3 kmod-mt7915-firmware > + GRUB2_VARIANT := generic > +endef > +TARGET_DEVICES += cordoba > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
New packages: cligen and clixon
Hi all, I know we've talked about replacing OpenWRT's native configuration representation with something more flexible... and things like NETCONF and OpenConfig come up from time to time. To that end, I've two PR's open: https://github.com/openwrt/packages/pull/22359 https://github.com/openwrt/packages/pull/22362 which will hopefully be merged before too long. I welcome anyone who's interested to play with these and checkout the capabilities of YANG, NetConf, and RestConf for provisioning network equipment. Comments welcome. There's work to be done in data modelings for devices, as well. https://www.openconfig.net/ https://github.com/openconfig/public/tree/master/release/models There's other stuff I can point to if anyone is interested. There's periodically some discussion about replacing UCI with something better, and YANG modeling comes up from time to time. Here's part of the infrastructure to do that. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Meta packages for wireless
Hi all, I was reading through some of the online documentations as I try to bring up a 5G modem w/ Verizon and modemmanager, and bounced between various settings (it's a Quectel EM120R-GL modem for the moment until something better arrives), trying to decide if I wanted to use QMI or MBIM, if I should use the "qui" protocol directly or "modemmanager" instead... And thought it would be nice to have 2 or 3 groups of meta packages that you select and the rest gets taken care of for you by dependencies. In particular: https://openwrt.org/docs/guide-user/network/wan/wwan/ltedongle Talks about kmod's and user-space tools necessary for QMI, different packages necessary for MBIM, and then what's needed for NCM (anyone still using that or 3G)... General debugging tools like minicom so you don't need to use "echo" or "socat"... Before I start on the effort (shouldn't take more than a couple of hours), does anyone object to the project (or conversely, is anyone willing to review and sign-off on it)? Eckert: thanks for the quick turnaround on the MBIM-disabled issue when building modemmanager... If anyone is wondering, no, I still don't have wireless up... not sure if that hardware is in a weird persistent state (a lot of settings get saved to NVRAM) or if modemmanager doesn't handle certain corner cases (although Verizon on a Quectel EM120R-GL using QMI would seem to be pretty mainstream). Please reach out to me if you have any troubleshooting suggestions, and I'll update the docs appropriately when I'm done. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Mofi still shipping Barrier Breaker (14.07)
Hi all, As we work on the 23.05 release, I was stunned to receive a Mofi MOFI4500-4GXeLTE-V3 router with 14.07 installed on it as part of my Unlimitedville enrollment. I thought, "wow, this must have been sitting in a warehouse a while! I'd better update it." So I went to the company's support site, grabbed the latest image, flashed it, rebooted and... still running 14.07. For those of you too young to remember, Barrier Breaker was released 10/2014 and included the 3.10.14 kernel (released 6/2013). How is this not cyber security malpractice? A firewall is your first line of defense against cyber attacks. If your firewall has long known, well documented vulnerabilities and exploits, you might as well not have a firewall at all. I wrote them asking why there wasn't a more recent, more secure release of the firewall firmware and this was their response: > Dear Philip, > You dint seem to know what you are talking about and should leave software to > Profesionals like us and relax I hope that most of the companies that use our software are more diligent, and don't incur repetitional damage to our efforts by continuing to ship EOL firmware. I get that not every company has kernel developers in-house, and frankly, providing an updated kernel release for their SoC is the manufacturer's responsibility, and MediaTek has not been responsive in this respect (for the longest time they were shipping a 2.6.36 SDK!). Some of the larger vendors (TPLink, ActionTec, Linksys, DLink, Netgear, et al) or their ODM partners have the option to hold their feet to the fire and make orders contingent on updated SDK's... I doubt that Mofi does the sort of volume that gives them any leverage. But I regress. Class Action suits are becoming more prevalent with computer and networking equipment manufacturers, as the public becomes aware of the increasing cyber security threats as well as manufacturers' implied responsibility to address vulnerabilities in a timely fashion as they become aware of them. I'm calling this out because I honestly hope it's the far outlier in our ecosystem, and not the rule. Sadly, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
hotplug deficiency -- HW network interfaces not generating events
Hi, I was looking at a way to address https://github.com/openwrt/openwrt/issues/13329 by leveraging hotplug instead (per Gorki's suggestion). Then it wouldn't matter if the drivers were loaded at preinit time (marked as "required to boot" in netdevices.mk) or not. But when I went to look into this, I noticed that "ifup" actions are generated for interfaces, but not for the device creation itself. If I look for devices generating ADD events, I only see dummy, loopback, SQM, XFRM, et. but not actual Ethernet NIC's. And /sys/class/net/eth0 has a uevent entry. Why are we not seeing hotplug events for actual network hardware? Any ideas what's required to have network interfaces generate ADD events? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Bringing up new hardware, and GPIO definitions
Seems logger isn't available in preinit, so I have to echo "$@" >/dev/kmsg instead. I made this further change: diff --git a/target/linux/x86/base-files/etc/board.d/02_network b/target/linux/x86/base-files/etc/board.d/02_network index e00e8c04dd..188cff7e1c 100644 --- a/target/linux/x86/base-files/etc/board.d/02_network +++ b/target/linux/x86/base-files/etc/board.d/02_network @@ -75,6 +75,18 @@ traverse-technologies-geos) macaddr="$(cat /sys/class/net/eth0/address)" 2>/dev/null [ -n "$macaddr" ] && ucidef_set_interface_macaddr "wan" "$macaddr" ;; +silicom-80500-0214-g02-sl01a) + ucidef_set_network_device_path "eth0" "pci:00/:00:17.0/:02:00.1" + ucidef_set_network_device_path "eth1" "pci:00/:00:17.0/:02:00.0" + ucidef_set_network_device_path "eth2" "pci:00/:00:16.0/:03:00.0" + ucidef_set_network_device_path "eth3" "pci:00/:00:16.0/:03:00.1" + ucidef_set_network_device_path "eth4" "pci:00/:00:0c.0/:04:00.0" + ucidef_set_network_device_path "eth5" "pci:00/:00:0e.0/:05:00.0" + ucidef_set_network_device_path "eth6" "pci:00/:00:0f.0/:06:00.0" + ucidef_set_network_device_path "eth7" "pci:00/:00:10.0/:07:00.0" + + ucidef_set_interfaces_lan_wan "eth4 eth5 eth6 eth7" "eth0 eth1 eth2 eth3" + ;; esac board_config_flush Digging into this, the problem seems to be here in preinit_config_board() # Find the current highest eth* max_eth=$(grep -o '^ *eth[0-9]*:' /proc/net/dev | tr -dc '[0-9]\n' | sort -n | tail -1) # Find and move netdevs using eth*s we are configuring json_get_keys keys "network_device" for netdev in $keys; do json_select "network_device" json_select "$netdev" json_get_vars path path if [ -n "$path" -a -h "/sys/class/net/$netdev" ]; then ip link set "$netdev" down ip link set "$netdev" name eth$((++max_eth)) fi json_select .. json_select .. done Before this block runs, all that exists in /sys/class/net/* is "lo". None of the other devices have yet been created, because they're of type "ixgbe" or "igc"... The difference being that they get loaded not with /etc/modules-boot.d/* but with /etc/modules.d/* ... which happens *after* the preinit script runs. Looking at netdevices.mk it seems a little arbitrary which modules have the "required for boot" flag and which ones don't: philipp@ubuntu22:~/lede$ grep -e KernelPackage -e AUTOLOAD:= package/kernel/linux/modules/netdevices.mk ... define KernelPackage/e1000 AUTOLOAD:=$(call AutoLoad,35,e1000) ... define KernelPackage/igb AUTOLOAD:=$(call AutoLoad,35,igb,1) ... define KernelPackage/ixgbe AUTOLOAD:=$(call AutoLoad,35,ixgbe) ... define KernelPackage/i40e AUTOLOAD:=$(call AutoProbe,i40e) ... define KernelPackage/igc AUTOLOAD:=$(call AutoProbe,igc) ... So, "igb" is "required for boot" (it is???) but "e1000", "ixgbe", "i40e", and "igc" aren't. Wha.aaat? So name assignments can only be done for a select few devices? Why can't renumbering also be handled for devices that get loaded later? Can boot() in /etc/init.d/boot be modified to finish the job? It's not as simple as duplicating the code, because you don't want to do it to the devices that have already been handled... > On Aug 21, 2023, at 1:49 PM, Philip Prindeville > wrote: > > On a somewhat related note, I got into my /etc/board.d/02_network file and > made this change: > > # > # Copyright © 2017 OpenWrt.org > # > > . /lib/functions/system.sh > . /lib/functions/uci-defaults.sh > > board_config_update > > +logger -p daemon.info <http://daemon.info/> "board_name: $(board_name)" > > case "$(board_name)" in > > But best as I can tell that line isn't being hit... or rather, the whole file > isn't. > > What would prevent that from happening? I'm not very familiar with the > preinit logic. > > Thanks > > > >> On Aug 21, 2023, at 11:34 AM, Philip Prindeville >> wrote: >> >> I have a new x86 prototype box I'm working with, and it doesn't h
Re: Bringing up new hardware, and GPIO definitions
On a somewhat related note, I got into my /etc/board.d/02_network file and made this change: # # Copyright © 2017 OpenWrt.org # . /lib/functions/system.sh . /lib/functions/uci-defaults.sh board_config_update +logger -p daemon.info <http://daemon.info/> "board_name: $(board_name)" case "$(board_name)" in But best as I can tell that line isn't being hit... or rather, the whole file isn't. What would prevent that from happening? I'm not very familiar with the preinit logic. Thanks > On Aug 21, 2023, at 11:34 AM, Philip Prindeville > wrote: > > I have a new x86 prototype box I'm working with, and it doesn't have a DTSI > file (obviously) or a platform driver... and given my experiences with > getting APU platform drivers upstream last time, I'm hesitant to do that all > over again. > > Anyway, is there an easy way to do GPIO assignments for LEDs and switches if > the kernel isn't doing this for me? > > Thanks > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Bringing up new hardware, and GPIO definitions
I have a new x86 prototype box I'm working with, and it doesn't have a DTSI file (obviously) or a platform driver... and given my experiences with getting APU platform drivers upstream last time, I'm hesitant to do that all over again. Anyway, is there an easy way to do GPIO assignments for LEDs and switches if the kernel isn't doing this for me? Thanks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Hostapd won't build after rebase yesterday
> On Aug 11, 2023, at 10:02 AM, Felix Fietkau wrote: > > On 11.08.23 17:58, Philip Prindeville wrote: >> I'm seeing the following breakage in hostapd: >> ../src/ap/ucode.c: In function 'uc_hostapd_iface_start': >> ../src/ap/ucode.c:337:23: error: 'struct hostapd_config' has no member named >> 'he_oper_centr_freq_seg0_idx'; did you mean 'vht_oper_centr_freq_seg0_idx'? >> 337 | conf->he_oper_centr_freq_seg0_idx = intval; >> | ^~~ >> | vht_oper_centr_freq_seg0_idx >> ../src/ap/ucode.c:344:23: error: 'struct hostapd_config' has no member named >> 'he_oper_centr_freq_seg1_idx'; did you mean 'vht_oper_centr_freq_seg1_idx'? >> 344 | conf->he_oper_centr_freq_seg1_idx = intval; >> | ^~~ >> | vht_oper_centr_freq_seg1_idx >> ../src/ap/ucode.c:352:23: error: 'struct hostapd_config' has no member named >> 'he_oper_chwidth'; did you mean 'vht_oper_chwidth'? >> 352 | conf->he_oper_chwidth = intval; >> | ^~~ >> | vht_oper_chwidth >> After rebasing yesterday. Anyone else seeing something similar? >> What's odd is that the package version didn't change in the rebasing. >> Is some code not properly gated by CONFIG_IEEE80211AX #ifdef's? > > Should already be fixed in 9c2c6d19f35708bb97462bb8902c54d2ec23001d > > Sorry for the noise, > > - Felix I fetched and that fixed it, thanks! I also got into my .config and enabled CONFIG_DRIVER_11AX_SUPPORT=y ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Reserving USERID
> On Aug 11, 2023, at 10:11 AM, Paul Spooren wrote: > > Hi, > >> Is explicit better or not? And if it is better, how do I go about reserving >> values that won't get stepped on? Who is our Numbers Czar, who is our IANA? > > I always used Gentoos numbers[1] whenever I added something. Since Clixon is > not part of that list, maybe use something that’s not yet in the list? >> >> And if the packaging requires that files be owned by a certain user, how is >> that handled in the Makefiles? > > Look for PKG_FILE_MODES in the repositories, i.e. busybox[2]. > > :Paul Awesome, thanks! On an unrelated note, where is a discussion of what OpenWRT represents configuration state as? Do we use JSON internally? How do I dump the "raw" state? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hostapd won't build after rebase yesterday
I'm seeing the following breakage in hostapd: ../src/ap/ucode.c: In function 'uc_hostapd_iface_start': ../src/ap/ucode.c:337:23: error: 'struct hostapd_config' has no member named 'he_oper_centr_freq_seg0_idx'; did you mean 'vht_oper_centr_freq_seg0_idx'? 337 | conf->he_oper_centr_freq_seg0_idx = intval; | ^~~ | vht_oper_centr_freq_seg0_idx ../src/ap/ucode.c:344:23: error: 'struct hostapd_config' has no member named 'he_oper_centr_freq_seg1_idx'; did you mean 'vht_oper_centr_freq_seg1_idx'? 344 | conf->he_oper_centr_freq_seg1_idx = intval; | ^~~ | vht_oper_centr_freq_seg1_idx ../src/ap/ucode.c:352:23: error: 'struct hostapd_config' has no member named 'he_oper_chwidth'; did you mean 'vht_oper_chwidth'? 352 | conf->he_oper_chwidth = intval; | ^~~ | vht_oper_chwidth After rebasing yesterday. Anyone else seeing something similar? What's odd is that the package version didn't change in the rebasing. Is some code not properly gated by CONFIG_IEEE80211AX #ifdef's? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Reserving USERID
Hi, I'm working on an updated release of Clixon for OpenWRT, and I want it to stop running as "root". Looking at all of the Makefiles, I see some packages reserve an explicit uid/gid associated with the user and group names, like ntp and ubus and network... while others don't (like docker and unbound). Is explicit better or not? And if it is better, how do I go about reserving values that won't get stepped on? Who is our Numbers Czar, who is our IANA? And if the packaging requires that files be owned by a certain user, how is that handled in the Makefiles? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Packaging ZFS
> On Aug 10, 2023, at 11:49 AM, Torbjörn Jansson wrote: > > On 2023-08-06 21:39, Philip Prindeville wrote: >> I don't know... I have a Xeon D-1548 based 1U Supermicro server with a 4TB >> NVMe stick that would make a decent file server/NAS... >>> On Aug 6, 2023, at 11:46 AM, Paul D wrote: >>> >>> Pretty sure not. I'm receptive to ZFS and have used it in a few projects. >>> Openwrt tends to focus on (devices with) smaller flash drives. Other FS >>> better suited to such env. >>> >>> No ZFS is in available software packages today, in any case. >>> >>> >>> On 2023-08-06 00:53, Philip Prindeville wrote: >>>> Has anyone tried to package ZFS (more correctly, OpenZFS) for OpenWRT? Is >>>> there any interest in doing so? >>>> >>>> https://github.com/openzfs/zfs >>>> >>>> >>>> > > you could always run openwrt as a vm under a hypervisor, for example proxmox. > then you can keep openwrt without any extra packages like zfs and create > extra vms as needed, proxmox already supports zfs if im not mistaken. > > if your lucky with the iommu groups you might even be able to pass thru one > or more physical network interfaces to the openwrt vm directly. I can't assume that the underlying hardware supports virtualization or does so in a meaningful way. Some of the platforms I'm looking at are resource lean. I threw out the Xeon-D as an example as my prototyping hardware, but I'm not going to assume that everyone has comparable hardware. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Packaging ZFS
> On Aug 8, 2023, at 3:14 PM, Luiz Angelo Daros de Luca > wrote: > >> Thanks, Alberto. I'm wondering how much work making it cross-build packages >> is going to be... >> >> Digging into it now... >> > > You should take a look at ksmbd package. It does compile an out-of-tree > module. > > Maintaining a package like that might be challenging for a stable > version. The kernel in the stable branch might receive updates during > its life but they are only published when a dot version (yy.mm.x+1) is > actually released. > However, packages are rebuilt as they are changed using the current > kernel in the stable branch. So, to build your module with a kernel > that will actually be published. you can only update a package with a > kernel module when you know the kernel in the stable branch is the one > that will be used by the next dot release. This "window of > opportunity" happens a little before or after the dot release is > built. Once the kernel is updated again, that window is closed. And > that updated kernel module will only be compatible with that specific > dot version, and not with any other dot version before or after it. > > Regards, > > Luiz There are a lot of modules that are built out-of-tree (like DPDK). How do they manage it? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Packaging ZFS
Thanks, Alberto. I'm wondering how much work making it cross-build packages is going to be... Digging into it now... > On Aug 7, 2023, at 3:23 AM, Alberto Bursi wrote: > > ZFS would be useful for any device with a few GB of RAM that has data drives > (a NAS for example). I've used ZFS extensively on x86 systems with other > Linux distros (Debian/Proxmox and OpenSUSE). > I think ZFS support is a good thing. > > Booting from ZFS is probably not necessary for OpenWrt but zfs snapshots are > used by some BSD distros (TrueNAS Core) and maybe Ubuntu as a way to version > the rootfs and revert to an older OS version in case of problems with updates > (similar to what the Turris Omnia and OpenSUSE does with btrfs afaik). > > Afaik the ZFS project does support the two "major" archs aka x86_64 and > ARM64, and maybe Power. People have been using ZFS on Raspberry Pis and on > some Rockchip boards (in Debian/Ubuntu/Armbian/RaspberryOS) for years at this > point. > > -Alberto > > On 06/08/23 21:39, Philip Prindeville wrote: >> I don't know... I have a Xeon D-1548 based 1U Supermicro server with a 4TB >> NVMe stick that would make a decent file server/NAS... >>> On Aug 6, 2023, at 11:46 AM, Paul D wrote: >>> >>> Pretty sure not. I'm receptive to ZFS and have used it in a few projects. >>> Openwrt tends to focus on (devices with) smaller flash drives. Other FS >>> better suited to such env. >>> >>> No ZFS is in available software packages today, in any case. >>> >>> >>> On 2023-08-06 00:53, Philip Prindeville wrote: >>>> Has anyone tried to package ZFS (more correctly, OpenZFS) for OpenWRT? Is >>>> there any interest in doing so? >>>> >>>> https://github.com/openzfs/zfs >>>> >>>> >>>> ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Packaging ZFS
I don't know... I have a Xeon D-1548 based 1U Supermicro server with a 4TB NVMe stick that would make a decent file server/NAS... > On Aug 6, 2023, at 11:46 AM, Paul D wrote: > > Pretty sure not. I'm receptive to ZFS and have used it in a few projects. > Openwrt tends to focus on (devices with) smaller flash drives. Other FS > better suited to such env. > > No ZFS is in available software packages today, in any case. > > > On 2023-08-06 00:53, Philip Prindeville wrote: > > Has anyone tried to package ZFS (more correctly, OpenZFS) for OpenWRT? Is > > there any interest in doing so? > > > > https://github.com/openzfs/zfs > > > > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Packaging ZFS
Has anyone tried to package ZFS (more correctly, OpenZFS) for OpenWRT? Is there any interest in doing so? https://github.com/openzfs/zfs ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Towards a unified /etc/config/dhcp
I'm the maintainer of ISC-DHCP which will be sunsetting soon. I'd like to take the UCI wrappers that I wrote to handle quite a few configuration options and port those to Kea since this makes the most sense as a migration path for people wishing to retain their configurations. That said, it strikes me that this is a broader "under-the-covers" implementation issue that we should shield users from. Would it make sense to try to coordinate with the dnsmasq folks on implementing as much common functionality as possible? Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Best practice for resetting (iptables) firewall state
Hi, I'm working on a wrapper for using xt_asn and xt_geoip in xtables-addons, and was wondering about how best to solve certain problems. Since, for now, I'll be using shell and UCI, I'm not going to maintain state (old/current vs. new/desired state) of the firewall so I won't be able to easily optimize firewall changes. The best I can do is detect the previous state, unload it, and then apply the new state. (Yes, in an ideal world, I'd apply any new rules, then unapply any old rules that aren't being used any more...) An example: I'm blocking the countries AA BB CC, but decide instead to block BB CC DD. The optimal path would be: 1. Add block DD 2. Remove block AA But that's more state than can be easily represented in a shell script that doesn't maintain any state beyond the current desired config which would be /etc/config/xyzzy. So, the easiest/most straightforward solution I can think of is: 1. Run "iptables-save | grep '^-A input_wan_rule .* -j myprefix_.*' to find where my rules are hooked in (ditto for "forwarding_wan_rule"); 2. Change '-A' to '-D' and delete the hooks; 3. Extract the rule name (target of -j above) and do "iptables -F rule_name" then "iptables -X rule_name" to remove the rule from the firewall 4. Generate the new rules based on the current contents of /etc/config/xyzzy And yes, obviously the firewall is most vulnerable while it's being reconfigured, since rules are being non-atomically torn down and built back up again, and depending on the number of rules and the speed of the processor, this can be a non-negligible amount of time. One observation: for the most part, the rules themselves while numerous are trivial. I don't have to worry about replacing an old version of a rule with a new but different version of that rule. If I'm blocking country AA, then the rule is present in a trivial and invariant form like: -A forwarding_wan_rule -m geoip --src-cc AA -j fwr_AA So the granularity of optimization would be: 1. If country X was in the old rules but not the new ones, delete it; 2. If country X is in both the old and new rules, don't do anything; 3. If country X wasn't in the old rules but is in the new ones, add it; With the only complexity being in preserving the ordering (although since countries don't overlap, ordering shouldn't make any difference). And another caveat: if the country database changes, and the CIDR list for country AA gets updated, then the only way to squirt the update into the kernel again by deletion/reinsertion, which invalidates (2) above because the country X isn't really 'invariant' in that case. Well, it could be if we were using ipset's and we could just apply the relevant deltas to the ipset, but we're not using ipsets. So deleting all the rules and adding them back might be unavoidable in any case, without doing a lot more work (which would involve keeping "last" and "next" versions of the country databases, and detecting if they've changed, etc). For atomicity, I suppose I could use a generational version of the rules, build generation N+1, insert the hook saying "use N+1", then delete the hook for N, then delete the chain for N... and "iptables -E ..." would help with renaming the new chain to the old chain after the old chain got deleted. Something like: # construct new rules for countries BB, CC, DD... iptables -N cc_BB_ iptables -A cc_BB_ -m limit --limit 1/sec --limit 5 -j LOG --log-level 4 --log-prefix "DROP cc BB: " iptables -A cc_BB_ -j DROP ... # create new container for new country rules iptables -N country_rules_ # hook in the individual new country rules iptables -A country_rules_ -m geoip --src-cc BB -g cc_BB_ iptables -A country_rules_ -m geoip --src-cc CC -g cc_CC_ .. # add the hook into the new country rules iptables -A forwarding_wan_rule -j country_rules_ # clean up the old country rules iptables -D country_rules -m geoip --src-cc AA -g cc_AA iptables -D country_rules -m geoip --src-cc BB -g cc_BB ... # remove the hook into the old country rules iptables -D forwarding_wan_rule -j country_rules # remove the old country rules iptables -F cc_AA iptables -F cc_BB ... # rename the new rules into the old names iptables -E country_rules_ country_rules iptables -E cc_BB_ cc_BB_ iptables -E cc_CC_ cc_CC_ ... Anyone have any suggestions, tips & tricks, etc. to give on how best manage firewall state without too much extra complexity? Also, how do you write an init.d wrapper that doesn't have a persistent foreground process, but handles "start", "stop", "reload", etc. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: armvirt -> armsr target rename [Was: Re: EFI / SystemReady support for OpenWrt on arm64]
> On Jun 9, 2023, at 1:23 AM, Petr Štetiar wrote: > > Hi, > > FYI there is an ongoing effort[1] to rename armvirt target to armsr (Arm > SystemReady) > > armvirt/32 becomes armsr/armv7 (title: 32-bit (armv7) machines) > armvirt/64 becomes armsr/armv8 (title: 64-bit (armv8) machines) > > BOARDNAME:=Arm SystemReady compliant (EFI) > > armv7/armv8 subtarget seems like a good fit for possibly upcoming armv9. > Should you've any objections or better ideas, please speak now otherwise I'm > going to merge this during a weekend, there is a plan[2] already to backport > this new naming scheme into the 23.05 as well. > > > 1. https://github.com/openwrt/openwrt/pull/12832 > 2. https://github.com/openwrt/openwrt/pull/12817 > > > Cheers, > > Petr I'm all in. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: EFI / SystemReady support for OpenWrt on arm64
> On May 28, 2023, at 2:09 AM, Petr Štetiar wrote: > > Mathew McBride [2023-05-26 16:16:31]: > > Hi Mathew, > >> I am just wondering if anyone has any significant objections that would >> stop this pull from being merged? (after I fix any current conflicts) > > we should support it, so we need to merge it. > >> 23.05 has branched and there is already a pull request for kernel 6.1 on >> master ( https://github.com/openwrt/openwrt/pull/12705 ), which will force >> a revision of this pull request. > > FYI it was merged. > >> I am willing to do the work for both branches but would like some >> indication of any required changes first. > > Great, I don't see any such objections in the PR, so feel free to ping me once > it's ready for 6.1, thanks! > > Cheers, > > Petr Looks good to me too. (What have replied sooner but was going through Cyrus mailbox recovery hell...) -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Non-SoC target for ARM64
> On Jun 1, 2023, at 1:18 PM, Tomasz Maciej Nowak wrote: > > W dniu 1.06.2023 o 18:58, Philip Prindeville pisze: >> Hi, > > Hi. > >> I'm thinking about the utility of being able to build a generalized ARM64 >> image (not "armvirt") for bring up on new platforms for testing. >> >> There are a lot of generalized computing platforms like the Ampere Altra >> servers that you might want to use as in inbound Apache proxy server, a load >> balancer, a traffic shaper, etc. >> >> Can we add a generic target for ARM64 just as x86_64 (or x86/64) is the >> generic AMD64 target? >> >> I'd like something that I could easily run on a Graviton2 or Altra or Ten64, >> etc. >> >> Also not clear to me why the various ARM targets like "layerscape", "imx", >> "octeontx", etc. don't live under a common directory. >> >> Yes, ARM is more optimized for SoCs that have I/O on-chip and hence there's >> less mix-n-match compared to x86, but it's not completely unheard of either. >> >> What do you all think of adding a generic target for aarch64? >> >> And how awful would refactoring arm and aarch64 be? > > Did You overlook this message > http://lists.openwrt.org/pipermail/openwrt-devel/2023-May/041091.html ? > Posted a week ago. I did in fact miss this message. > It's modifying armvirt target to boot it effortlessly on arm64 hardware. I think having an image with drivers built in for virtualization only is fine, but another more full-featured image for actual bare metal would also be good. > The name of target stays but that's only a name. > >> Thanks, >> >> -Philip > > Regards > > -- > TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Non-SoC target for ARM64
Hi, I'm thinking about the utility of being able to build a generalized ARM64 image (not "armvirt") for bring up on new platforms for testing. There are a lot of generalized computing platforms like the Ampere Altra servers that you might want to use as in inbound Apache proxy server, a load balancer, a traffic shaper, etc. Can we add a generic target for ARM64 just as x86_64 (or x86/64) is the generic AMD64 target? I'd like something that I could easily run on a Graviton2 or Altra or Ten64, etc. Also not clear to me why the various ARM targets like "layerscape", "imx", "octeontx", etc. don't live under a common directory. Yes, ARM is more optimized for SoCs that have I/O on-chip and hence there's less mix-n-match compared to x86, but it's not completely unheard of either. What do you all think of adding a generic target for aarch64? And how awful would refactoring arm and aarch64 be? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SoHo VPN providers and rDNS, etc -- recommendations?
> On May 12, 2023, at 12:25 PM, Mark Thurston wrote: > >> I've got a simple question. I'm in the US, and I'm looking for a VPN >> provider that uses IPsec and can provide an rDNS record for my public IPv4 >> pointing back to my domain. I've asked several VPN providers and they don't >> seem to understand what I'm asking (NordVPN, ProtonVPN, NordLayer, etc). >> Maybe I'm just asking wrong. >> >> How do you make SPF, DKIM, and X.509 TLS certificates with DNS: SNI's work >> without this? >> >> The other thing that would be handy is if they also provided DNS hosting for >> customer domains (so I could drop GoDaddy which I'm sick of). >> >> You'd think they'd offer both for one-stop-shopping but I can't seem to >> locate any. Does anyone use Amazon for this for a single or a couple of >> IPv4's? What's been your experience? >> >> Any others that people are happy with? >> > > I'm not sure a VPN service aimed at the average punter will provide this. > > I would suggest an entry-level VM on a cloud-provider (Linode's "nanode" > $5pm, for example). Then you can then choose your DNS nameserver allowing you > to configure your DNS yourself including all the extras that you need. I think you misunderstand what I'm saying: I don't want to host DNS, I want the provider to do that. I would edit my zonefiles locally and upload them via "nsupdate" (with authentication, of course) to the primary. I'd also need them to be the registrar for my domain. > Re VPNs, if you have the option and need speed, I would go with WireGuard > rather than IPSec. From a purely trying-to-keep-it-on-topic point of view, > the improved resource use of WireGuard will allow you to use a low-powered > embedded OpenWrt device at the other end of the VPN. I need it to be IPsec, and I'm one of the StrongSwan maintainers, so I have to dogfood. > The linuxserver.io wireguard Docker image > (https://docs.linuxserver.io/images/docker-wireguard) is excellent for fast > deployment of wireguard on off the shelf VMs. I don't need a dedicated server... I'm limited to less than 400mb/s so sharing a server is fine, as long as I get a dedicated address for my tunnel. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
SoHo VPN providers and rDNS, etc -- recommendations?
Hi, I've got a simple question. I'm in the US, and I'm looking for a VPN provider that uses IPsec and can provide an rDNS record for my public IPv4 pointing back to my domain. I've asked several VPN providers and they don't seem to understand what I'm asking (NordVPN, ProtonVPN, NordLayer, etc). Maybe I'm just asking wrong. How do you make SPF, DKIM, and X.509 TLS certificates with DNS: SNI's work without this? The other thing that would be handy is if they also provided DNS hosting for customer domains (so I could drop GoDaddy which I'm sick of). You'd think they'd offer both for one-stop-shopping but I can't seem to locate any. Does anyone use Amazon for this for a single or a couple of IPv4's? What's been your experience? Any others that people are happy with? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
> On May 1, 2023, at 6:59 PM, Alberto Bursi wrote: > > > > On 01/05/23 06:40, Philip Prindeville wrote: >>> On Apr 28, 2023, at 11:18 PM, Elliott Mitchell wrote: >>> >>> On Fri, Apr 28, 2023 at 12:04:15PM -0600, Philip Prindeville wrote: >>>> >>>>> [snip] >>> >>>> See above: the radios and antennae I can get as add-ons for a Xeon-D 1U >>>> pizza box or even an APU6 mPCIe slot are vastly inferior to what ODM >>>> purpose-built hardware like an U6-LR can do in terms of cost and >>>> performance. >>>> >>>> Um... you can't "virtualize" WiFi in any VM I've ever seen. >>> >>> You can though pass PCIe devices to a VM. The hardware will physically >>> attach to the control host, but a VM will be able to do anything it wants >>> with it. >> So the guest has the potential to crash or hang the host? > > Passthrough devices aren't really handled by the host OS (it's commonly > required to blacklist their kernel drivers to make sure the host does NOT > touch them) so in most cases if something hard-crashes and a kernel panics > it's still all drama that happens inside the VM. This is how it usually goes > in my experience. > > GPU passthrough can cause a whole host to lock up and require power cycle. > I've seen that happen in the wild only once (it was repeatable, fun times), > but imho it's a IOMMU or GPU issue not a "normal" thing that should happen. > > -Alberto You can also lock up the PCIe bus so that the CPU can't access the bus or bus-attached devices like disk controllers, network interfaces, etc. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
> On May 1, 2023, at 9:32 AM, Daniel Golle wrote: > > On Mon, May 01, 2023 at 09:01:29AM -0600, Philip Prindeville wrote: >> >> >>> On May 1, 2023, at 8:12 AM, Joseph Mullally wrote: >>> >>> On Mon, May 1, 2023 at 5:43 AM Philip Prindeville >>> wrote: >>>>> On Apr 28, 2023, at 11:18 PM, Elliott Mitchell >>>>> wrote: >>>>>> On Fri, Apr 28, 2023 at 12:04:15PM -0600, Philip Prindeville wrote: >>> >>>>>> Um... you can't "virtualize" WiFi in any VM I've ever seen. >>>>> >>>>> You can though pass PCIe devices to a VM. The hardware will physically >>>>> attach to the control host, but a VM will be able to do anything it wants >>>>> with it. >>>> >>>> So the guest has the potential to crash or hang the host? >>> >>> I ran the OpenWrt x86/64 image under KVM/libvirtd for years with an >>> Intel Wifi card connected through exclusive PCI passthrough, and it >>> worked fine. There is enough conjecture already. >> >> >> From one anecdotal episode I'm not going to extrapolate that this is a >> robust solution in all cases; I wouldn't get very far as a cyber security >> engineer thinking this way. > > Maybe the fact that PCI passthrough is facilitated by the IOMMU which > takes care of resource isolation makes you feel a bit better about it? > The host from this point on doesn't deal with that PCIe slot any more, > and passtrough is happening entirely in hardware. > > However, keep in mind that access to PCIe in most cases (such as WiFi > adapters) doesn't assume the user could be a bad actor. You will probably > still be able to do bad things with it, esp. if you know the hardware > well (such as triggering overheat/overcurrent, deliberately creating > radio interference with other system parts, ...). Malicious activity aside, there's always the potential of poorly backported device driver patches, or even running a bleeding-edge kernel, to break things badly... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 9/9] kernel/x86: remove DRM support
> On Apr 28, 2023, at 9:45 PM, Elliott Mitchell wrote: > > On Thu, Apr 27, 2023 at 11:21:28AM +0200, Thibaut wrote: >> >>> Le 27 avr. 2023 à 02:11, Elliott Mitchell a écrit : >>> >>> On Thu, Apr 27, 2023 at 12:50:52AM +0200, Stefan Lippers-Hollmann wrote: On 2023-04-19, Elliott Mitchell wrote: > Direct Rendering Manager is mainly for running X (possibly Wayland > too). As OpenWRT is meant for networking devices, there is no need > for the support to be present. That is only partially true, the Linux kernel is making a strong push away from deprecated (FB_*) graphics drivers to DRM based ones, with kernel based mode setting this is getting more (any) attention for console support as well. Even without getting anywhere near X/ Wayland, there is more than just a 80x25 tty on real hardware (and even VMs). >>> >>> Real x86 hardware often has the capability to use a serial port as >>> console. The conventional UEFI implementation fully supports this use >>> case. I can well believe a number of manufacturers disabling the >>> functionality though. >>> >>> VMs *can* have more than a 80x25 tty. By the time you're getting to 4 >>> or more VMs you should be thinking about disabling the functionality due >>> to the heavy overhead (unless the OS in the VM doesn't support serial >>> consoles). >> >> You seem to assume that x86 is only/mainly run on VMs. >> That is not necessarily the case, and I see no reason to degrade device >> support that way. > > Okay, as already stated there are at least two solutions to this. > > 1> Turn most functionality into modules and include support for runtime > loading of kernel modules. > > 2> Create more kernel variants for OpenWRT/x86. > > >> Would you mind documenting the measurable gains from your changes, so we >> have some metric to assess their relevance? >> > > I had suspected as much, but fully disabling ISA DMA didn't directly > have much impact (less than 4195 byte reduction). I was already guessing > most of the gain was CONFIG_ISA=n, but hoped purging ISA DMA might > squeeze out a bit more. > > Removing AGP shrunk vmlinux.bin by 4KB. Since the kernel is a multiple > of page size, this means a reduction of 1-8191 bytes. This though may > have translated into a larger impact when CONFIG_DRM was set to no. > > Setting CONFIG_DRM=n resulted in a vmlinux.bin delta of -2203648 bytes. > Not quite a 10% reduction in kernel runtime size, but close. Here we > have a major impact on kernel size. > > Removing USB support is certainly inappropriate for a desktop build, but > appropriate for something using a serial console (some types of VM). > That has a delta of -2117632 bytes. I occasionally use the USB pass-thru with memory sticks to install or recover an VM. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
> On May 1, 2023, at 8:12 AM, Joseph Mullally wrote: > > On Mon, May 1, 2023 at 5:43 AM Philip Prindeville > wrote: >>> On Apr 28, 2023, at 11:18 PM, Elliott Mitchell wrote: >>>> On Fri, Apr 28, 2023 at 12:04:15PM -0600, Philip Prindeville wrote: > >>>> Um... you can't "virtualize" WiFi in any VM I've ever seen. >>> >>> You can though pass PCIe devices to a VM. The hardware will physically >>> attach to the control host, but a VM will be able to do anything it wants >>> with it. >> >> So the guest has the potential to crash or hang the host? > > I ran the OpenWrt x86/64 image under KVM/libvirtd for years with an > Intel Wifi card connected through exclusive PCI passthrough, and it > worked fine. There is enough conjecture already. From one anecdotal episode I'm not going to extrapolate that this is a robust solution in all cases; I wouldn't get very far as a cyber security engineer thinking this way. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/9] kernel: change CONFIG_HW_RANDOM default to y
> On Apr 29, 2023, at 12:08 AM, Elliott Mitchell wrote: > > On Fri, Apr 28, 2023 at 10:29:29AM -0600, Philip Prindeville wrote: >> Why isn't this migrating upwards into target/linux/generic/config-5.15 and >> target/linux/generic/config-5.10 in that case? >> >> And for the platforms where it was turned off, like >> target/linux/armvirt/32/config-5.15, why isn't that staying unchanged? > > I'm guessing you're unaware of a subtlety of how the .config system > actually works. Take a second look, some handy examples: > >>> On Apr 22, 2023, at 11:46 AM, Elliott Mitchell wrote: > >>> diff --git a/target/linux/armvirt/32/config-5.10 >>> b/target/linux/armvirt/32/config-5.10 >>> index 3c6443bcbf..2f7cd03b5f 100644 >>> --- a/target/linux/armvirt/32/config-5.10 >>> +++ b/target/linux/armvirt/32/config-5.10 >>> @@ -47,6 +47,7 @@ CONFIG_EDAC_ATOMIC_SCRUB=y >>> CONFIG_GENERIC_VDSO_32=y >>> CONFIG_HARDEN_BRANCH_PREDICTOR=y >>> CONFIG_HAVE_SMP=y >>> +CONFIG_HW_RANDOM=n >>> CONFIG_HZ_FIXED=0 >>> CONFIG_HZ_PERIODIC=y >>> CONFIG_MIGHT_HAVE_CACHE_L2X0=y >>> diff --git a/target/linux/armvirt/32/config-5.15 >>> b/target/linux/armvirt/32/config-5.15 >>> index bf6e2a5cde..bb2a7a320f 100644 >>> --- a/target/linux/armvirt/32/config-5.15 >>> +++ b/target/linux/armvirt/32/config-5.15 >>> @@ -49,6 +49,7 @@ CONFIG_GENERIC_IRQ_MULTI_HANDLER=y >>> CONFIG_GENERIC_VDSO_32=y >>> CONFIG_HARDEN_BRANCH_PREDICTOR=y >>> CONFIG_HAVE_SMP=y >>> +CONFIG_HW_RANDOM=n >>> CONFIG_HZ_FIXED=0 >>> CONFIG_HZ_PERIODIC=y >>> CONFIG_MIGHT_HAVE_CACHE_L2X0=y > > >>> diff --git a/target/linux/armvirt/64/config-5.10 >>> b/target/linux/armvirt/64/config-5.10 >>> index 275fe4571d..af46939ad2 100644 >>> --- a/target/linux/armvirt/64/config-5.10 >>> +++ b/target/linux/armvirt/64/config-5.10 >>> @@ -102,7 +102,6 @@ CONFIG_GPIO_GENERIC=y >>> CONFIG_GPIO_GENERIC_PLATFORM=y >>> CONFIG_HDMI=y >>> CONFIG_HOLES_IN_ZONE=y >>> -CONFIG_HW_RANDOM=y >>> CONFIG_HW_RANDOM_VIRTIO=y >>> CONFIG_I2C=y >>> CONFIG_I2C_ALGOBIT=y >>> diff --git a/target/linux/armvirt/64/config-5.15 >>> b/target/linux/armvirt/64/config-5.15 >>> index 19ae3dc0cf..88f2f64cde 100644 >>> --- a/target/linux/armvirt/64/config-5.15 >>> +++ b/target/linux/armvirt/64/config-5.15 >>> @@ -103,7 +103,6 @@ CONFIG_GENERIC_FIND_FIRST_BIT=y >>> CONFIG_GPIO_GENERIC=y >>> CONFIG_GPIO_GENERIC_PLATFORM=y >>> CONFIG_HDMI=y >>> -CONFIG_HW_RANDOM=y >>> CONFIG_HW_RANDOM_ARM_SMCCC_TRNG=y >>> CONFIG_HW_RANDOM_VIRTIO=y >>> CONFIG_I2C=y >>> diff --git a/target/linux/ath25/config-5.10 b/target/linux/ath25/config-5.10 >>> index ef764820e4..41e65c72ad 100644 > > >>> diff --git a/target/linux/generic/config-5.10 >>> b/target/linux/generic/config-5.10 >>> index f6f1fb0278..853c13852d 100644 >>> --- a/target/linux/generic/config-5.10 >>> +++ b/target/linux/generic/config-5.10 >>> @@ -2343,7 +2343,7 @@ CONFIG_HPET_MMAP_DEFAULT=y >>> # CONFIG_HWSPINLOCK is not set >>> # CONFIG_HWSPINLOCK_OMAP is not set >>> CONFIG_HW_PERF_EVENTS=y >>> -# CONFIG_HW_RANDOM is not set >>> +CONFIG_HW_RANDOM=y >>> # CONFIG_HW_RANDOM_AMD is not set >>> # CONFIG_HW_RANDOM_ATMEL is not set >>> # CONFIG_HW_RANDOM_BA431 is not set >>> diff --git a/target/linux/generic/config-5.15 >>> b/target/linux/generic/config-5.15 >>> index ac75a480a1..bf38732b31 100644 >>> --- a/target/linux/generic/config-5.15 >>> +++ b/target/linux/generic/config-5.15 >>> @@ -2444,7 +2444,7 @@ CONFIG_HPET_MMAP_DEFAULT=y >>> # CONFIG_HWSPINLOCK is not set >>> # CONFIG_HWSPINLOCK_OMAP is not set >>> CONFIG_HW_PERF_EVENTS=y >>> -# CONFIG_HW_RANDOM is not set >>> +CONFIG_HW_RANDOM=y >>> # CONFIG_HW_RANDOM_AMD is not set >>> # CONFIG_HW_RANDOM_ARM_SMCCC_TRNG is not set >>> # CONFIG_HW_RANDOM_ATMEL is not set > > armvirt/32 previously had it off and it is still off. armvirt/64 > previously had it on and it is still on. > > Most similar systems would treat "# is not set" as undefined or > no preference (use the default value). The Linux kernel system treats > this as "no" due to the history of the system. Yet it also honors "n" > as "no". > > I tend to prefer "n" as it hints at a value being deliberately chosen, > instead of being left unset/undefined. Enumerating it explicitly saves me having to get into the kernel sources and grep Config files for a default. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
> On Apr 28, 2023, at 11:18 PM, Elliott Mitchell wrote: > > On Fri, Apr 28, 2023 at 12:04:15PM -0600, Philip Prindeville wrote: >> >>> [snip] > >> See above: the radios and antennae I can get as add-ons for a Xeon-D 1U >> pizza box or even an APU6 mPCIe slot are vastly inferior to what ODM >> purpose-built hardware like an U6-LR can do in terms of cost and performance. >> >> Um... you can't "virtualize" WiFi in any VM I've ever seen. > > You can though pass PCIe devices to a VM. The hardware will physically > attach to the control host, but a VM will be able to do anything it wants > with it. So the guest has the potential to crash or hang the host? > >>> Problem is instead of the recommended 128MB memory, 16MB of storage >>> (https://openwrt.org/supported_devices/432_warning) the virtualization >>> examples (https://openwrt.org/docs/guide-user/virtualization/start) are >>> suggesting massively more memory. 256MB (small Xen example), 512MB >>> (VMware OpenWRT/15.05) or 1GB (Qemu examples). >> >> Sorry, why is this a "problem"? >> >> I spent $1100 on a Xeon-D box with 128GB of DRAM, 16 hyper threaded cores, >> and 2TB of NVMe. > > If those numbers are to be believed (which is now suspect), it means a > *requirement* to devote that much to network operations. Not being a > requirement means one could use the memory for other things. Or I could > allow more than that to do extra complicated network things. Which part is a lie? [philipp@kvm1 ~]$ sudo dmidecode # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 2.8 present. 39 structures occupying 2183 bytes. Table at 0x000EB000. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 1.1c Release Date: 10/03/2016 Address: 0xF Runtime Size: 64 kB ROM Size: 16 MB Characteristics: PCI is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) ACPI is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported UEFI is supported BIOS Revision: 5.6 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Supermicro Product Name: Super Server Version: 0123456789 Serial Number: 0123456789 UUID: ----0cc47a971b8e Wake-up Type: Power Switch SKU Number: To be filled by O.E.M. Family: To be filled by O.E.M. Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: Supermicro Product Name: X10SDV-8C-TLN4F Version: 2.00 Serial Number: ZM16AS037277 Asset Tag: To be filled by O.E.M. Features: Board is a hosting board Board is replaceable Location In Chassis: To be filled by O.E.M. Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Handle 0x0003, DMI type 3, 25 bytes Chassis Information Manufacturer: Supermicro Type: Main Server Chassis Lock: Not Present Version: 0123456789 Serial Number: 0123456789 Asset Tag: To Be Filled By O.E.M. Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x Height: Unspecified Number Of Power Cords: 1 Contained Elements: 1 (0) SKU Number: To be filled by O.E.M. ... Handle 0x0019, DMI type 16, 23 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: Multi-bit ECC Maximum Capacity: 128 GB Error Information Handle: Not Provided Number Of Devices: 4 Handle 0x001A, DMI type 19, 31 bytes Memory Array Mapped Address Starting Address: 0x000 Ending Address: 0x01003FF Range Size: 64 GB Physical Array Handle: 0x0019 Partition Width: 2 Handle 0x001B, DMI type 17, 40 bytes Memory Device Array Handle: 0x0019 Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 32 GB Form Factor: DIMM Set: None Locator: DIMMA1 Bank Locator: P0_Node0_Channel0_Dimm0 Type: DDR4 Type Detail: Synchronous Speed: 2400 MT/s Manufacturer: Undefined Serial Number: F019B10C Asset Tag: (Date:16/50) Part Number: 9965640-006.A01GRank: 2 Configured Memory Speed: 2133 MT/s Minimum Voltage: Unknown Maximum Voltage: Unknown Configured Voltage: 0.003 V ... Handle 0x001D, DMI type 17, 40 bytes Memory Device Array Handle: 0x0019 Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: DIMMA2 Bank Locator: P0_Node0_Channel0_Dimm1 Type:
Re: [PATCH 1/9] kernel/generic: remove CONFIG_FB_NOTIFY
Reviewed-by: Philip Prindeville > On Apr 25, 2023, at 5:23 PM, Elliott Mitchell wrote: > > I don't know what version of Linux this option disappeared at, but > it is clearly gone now. > > Signed-off-by: Elliott Mitchell > --- > target/linux/generic/config-5.10 | 1 - > target/linux/generic/config-5.15 | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/target/linux/generic/config-5.10 > b/target/linux/generic/config-5.10 > index cde0fdb0a0..f6f1fb0278 100644 > --- a/target/linux/generic/config-5.10 > +++ b/target/linux/generic/config-5.10 > @@ -1892,7 +1892,6 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" > # CONFIG_FB_MXS is not set > # CONFIG_FB_N411 is not set > # CONFIG_FB_NEOMAGIC is not set > -CONFIG_FB_NOTIFY=y > # CONFIG_FB_NVIDIA is not set > # CONFIG_FB_OF is not set > # CONFIG_FB_OMAP2 is not set > diff --git a/target/linux/generic/config-5.15 > b/target/linux/generic/config-5.15 > index 239a645231..ac75a480a1 100644 > --- a/target/linux/generic/config-5.15 > +++ b/target/linux/generic/config-5.15 > @@ -1979,7 +1979,6 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" > # CONFIG_FB_MXS is not set > # CONFIG_FB_N411 is not set > # CONFIG_FB_NEOMAGIC is not set > -CONFIG_FB_NOTIFY=y > # CONFIG_FB_NVIDIA is not set > # CONFIG_FB_OF is not set > # CONFIG_FB_OMAP2 is not set > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+open...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
> On Apr 26, 2023, at 2:17 PM, Elliott Mitchell wrote: > > Well, was a specific objective ever chosen for the x86 version of > OpenWRT? Does it need one? As the most ubiquitous hardware out there for many users, why would we need to box it in? Someone might want to throw a generic image onto a PC they have lying around until they decide it's worth bringing up specialized hardware... going out an buying it, building an image, installing it, troubleshooting it, etc. > I can state my goal/hope for OpenWRT/x86. The *WRT Linux distributions > were so named for originally targeting the LinkSys WRT54G. This was a > small AP, so one might expect builds to be for small APs. By today's > standards 128MB RAM and 16MB of storage is relatively small. Yeah, we had a discussion some years ago about "FAT" vs. "SKINNY" platforms that never went anywhere. All of the AMD64 platforms were FAT. Having robust hardware that you can prototype on, including CPU or memory hungry development, allows us to prove the value of new capabilities that might be ubiquitous in the next generation of COTS and SoHo routers. After all, the BoM for an extra GB of DRAM is literally pennies in large production volumes. BTW, I run OpenWrt for its firewall capabilities... None of my boxes actually has wireless hardware at this point, and I use a few Ubiquiti AP-AC-Pro's or U6-LR's scattered around the house. The rule of thumb when I worked at MIT on the X Window System, was that what's the top-of-the-line workstation today will be "budget" hardware 3-4 years out, so to not worry about hardware constraints because by the time you release stable, production quality software, the hardware will have gone through one or two evolutions... Today's one-off advanced prototyping platform is tomorrow's BestBuy budget/clearance item... > Since this network is in the moving towards the server phase, the AP drew > my attention. Turns out all of the hardware of an AP is available for > servers, though in distinct form-factors. If the server has a full > IOMMU, the hardware can be directed to a VM and you have a proper AP in a > VM. "Moving towards the server phase"? I'm not getting what you mean by this. See above: the radios and antennae I can get as add-ons for a Xeon-D 1U pizza box or even an APU6 mPCIe slot are vastly inferior to what ODM purpose-built hardware like an U6-LR can do in terms of cost and performance. Um... you can't "virtualize" WiFi in any VM I've ever seen. > Problem is instead of the recommended 128MB memory, 16MB of storage > (https://openwrt.org/supported_devices/432_warning) the virtualization > examples (https://openwrt.org/docs/guide-user/virtualization/start) are > suggesting massively more memory. 256MB (small Xen example), 512MB > (VMware OpenWRT/15.05) or 1GB (Qemu examples). Sorry, why is this a "problem"? I spent $1100 on a Xeon-D box with 128GB of DRAM, 16 hyper threaded cores, and 2TB of NVMe. > I don't yet have a full handle on the issues. My first thought was the > large sizes come from early stage development and not wanting to bother > with memory limitations. Another possibility is this comes from simply a > thought pattern of "x86 memory is cheap, just throw memory at it". You're looking at it backwards. Think of it as "what could I do if I have more RAM and CPU?" Could I do on-board real-time data reduction of firewall logs? Could I run fail2ban near-realtime? Could I run a sandboxed Apache proxy to all of my internal HTTP-based services and used certificate-based authentication with centralized management? I've been running VoIP on my firewall for 12 years now, with find-me follow me, and 22 extensions. I'm thinking of adding 4K video-conferencing capability if I can find the time... My security cameras do H.265 in their highest quality mode, but the renderer in Safari on my iPhone can only handle H.264... but I don't care, because I can configure a transcoding proxy to run in Apache+VLC!!! > Yet if one is wanting to use this for serious purposes, memory IS a > concern. GCC is pretty capable for x86, a quick check suggests GCC tends > to produce binaries for x86 which are four-fifths the size of those for > ARM. Yet everything for OpenWRT/x86 is suggesting at least *double* the > memory?! If I need something for "serious purposes", I budget appropriately... > One issue I've found is the kernel configurations seem ill-suited to x86. > Almost any storage driver used by 10 or more people is built into the > kernel. As a result the *single* kernel is huge. If it's not used as a boot device, we could make it kmod-able... otherwise we'd need to add initramfs... I don't think anyone wants to go down that road. Too easy to brick devices. I think we should leverage more subtargets and profiles, but that's a separate discussion. > The conventional approach for x86 is to use an initial ramdisk and build > everything as modules. Issue here
Re: [PATCH 9/9] kernel/x86: remove DRM support
> On Apr 27, 2023, at 3:21 AM, Thibaut wrote: > > > >> Le 27 avr. 2023 à 02:11, Elliott Mitchell a écrit : >> >> On Thu, Apr 27, 2023 at 12:50:52AM +0200, Stefan Lippers-Hollmann wrote: >>> On 2023-04-19, Elliott Mitchell wrote: Direct Rendering Manager is mainly for running X (possibly Wayland too). As OpenWRT is meant for networking devices, there is no need for the support to be present. >>> >>> That is only partially true, the Linux kernel is making a strong push >>> away from deprecated (FB_*) graphics drivers to DRM based ones, with >>> kernel based mode setting this is getting more (any) attention for >>> console support as well. Even without getting anywhere near X/ Wayland, >>> there is more than just a 80x25 tty on real hardware (and even VMs). >> >> Real x86 hardware often has the capability to use a serial port as >> console. The conventional UEFI implementation fully supports this use >> case. I can well believe a number of manufacturers disabling the >> functionality though. >> >> VMs *can* have more than a 80x25 tty. By the time you're getting to 4 >> or more VMs you should be thinking about disabling the functionality due >> to the heavy overhead (unless the OS in the VM doesn't support serial >> consoles). > > You seem to assume that x86 is only/mainly run on VMs. > That is not necessarily the case, and I see no reason to degrade device > support that way. > > Would you mind documenting the measurable gains from your changes, so we have > some metric to assess their relevance? > > Cheers, > T True enough. I have net4801 (Geode), net5501 (Geode), alix2 (Geode), apu6 (GX-412TC), and Supermicro Xeon D1548 based routers right in front of me. Let's also not forget that Openwrt is used downstream in many projects that we have limited visibility into. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 6/9] kernel/x86: enable x32 support for amd64
> On Apr 26, 2023, at 6:00 PM, Elliott Mitchell wrote: > > On Thu, Apr 27, 2023 at 12:46:49AM +0200, Stefan Lippers-Hollmann wrote: >> >> On 2023-03-30, Elliott Mitchell wrote: >>> Full amd64 support isn't really appropriate for most situations >>> OpenWRT is deployed. Whereas x86-x32 seems extremely appropriate for >>> these situations. As such enable x86-x32 support. >>> >>> CONFIG_ARCH_MMAP_RND_COMPAT_BITS is required to follow along, >>> otherwise the kernel build breaks. >>> >>> Signed-off-by: Elliott Mitchell >>> --- >>> I suggest OpenWRT should be placing quite a bit of effort towards >>> x86-x32. x86-x32 seems a rather superior generic target for OpenWRT. >>> Only issue is it could be valuable to have at least minimal amd64 >>> userland support alongside the x86-x32 version. >> >> x86_32 is pretty much dead in the water, with almost zero deployment >> by general purpose distributions - apart from VM data centre >> environments doing their own thing (least amount of RAM usage >> possible, everything else being secondary at best). At least Debian >> did raise security concerns about the x86_32 ISA in the past. > > Error: undefined symbol "x86_32" > > Without the extra context I would resolve that to "i386"/"ia32". I think > "x32" or "x86_x32" are better strings for this case. > > According to what I had read that was in the past when x32 was sharing > less of the i386 ABI. Notably x32 had been trying to pass time values > in a distinct fashion. I will conceed I'm unsure whether x32 is ever > truly going to get a seat at the table. > > On a different news front, Linux 5.10 has an option > CONFIG_X86_X32_DISABLED which leaves x32 disabled by default (Debian's > kernels were configured this way). Whereas 5.15 has removed the > CONFIG_X86_X32_DISABLED option which seems to suggest the concerns may > have been assuaged. > >> While I might understand (understand, not support) a desire for this >> as a dedicated subtarget (to appease the virtualization crowd), >> although I still don't see a reason or sufficient uptake in more >> conventional Linux environments. I would not be happy (at all) to >> lose 'normal' x86_64 support (on real hardware) for this exotic >> fringe hybrid. I can imagine that actually building for this >> environment (with a 32 bit userland) might lead to 'funny' results >> as well (as in major toolchain changes necessary to get it working >> as expected). > > I'm not proposing removing amd64 support, I'm proposing x32 is likely a > more valuable target. Yet what you're describing reads like your desire > is for OpenWRT/x86 to simply be yet another desktop Linux distribution. > > Unless you feel a networking device really needs 256GB of memory, virtual > machines are precisely what OpenWRT/x86 *should* target. I think it is > reasonable to also have a jumbo/desktop build, but using an entire x86 > machine doesn't seem to match OpenWRT's main theme. I personally know of companies running virtualized instances of AMD64 on m4.large or m5.large Amazon EC2 instances. I have three AMD64 firewalls... Two PC Engines APU6's (AMD GX-412TC "Jaguar" SoC based) running as a hot tandem pair for fail-over at the home office, and a dogfooding instance running on a KVM server that sandboxes my teenage kids and keeps them off the main household networks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 6/9] kernel/x86: enable x32 support for amd64
My own experience disagrees. I spent 17 months bringing up a Xeon-D based traffic shaper for 40Gb/s of traffic in a radio base station. And yes, when collected crunched traffic statistics, it did use more than 4GB of address space to do so. > On Mar 30, 2023, at 5:30 PM, Elliott Mitchell wrote: > > Full amd64 support isn't really appropriate for most situations > OpenWRT is deployed. Whereas x86-x32 seems extremely appropriate for > these situations. As such enable x86-x32 support. > > CONFIG_ARCH_MMAP_RND_COMPAT_BITS is required to follow along, > otherwise the kernel build breaks. > > Signed-off-by: Elliott Mitchell > --- > I suggest OpenWRT should be placing quite a bit of effort towards > x86-x32. x86-x32 seems a rather superior generic target for OpenWRT. > Only issue is it could be valuable to have at least minimal amd64 > userland support alongside the x86-x32 version. > --- > target/linux/x86/64/config-5.10 | 1 - > target/linux/x86/64/config-5.15 | 1 - > target/linux/x86/config-5.10| 2 ++ > target/linux/x86/config-5.15| 2 ++ > 4 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/target/linux/x86/64/config-5.10 b/target/linux/x86/64/config-5.10 > index 1515f90932..de93495fb1 100644 > --- a/target/linux/x86/64/config-5.10 > +++ b/target/linux/x86/64/config-5.10 > @@ -470,7 +470,6 @@ CONFIG_X86_PM_TIMER=y > # CONFIG_X86_POWERNOW_K8 is not set > # CONFIG_X86_VSYSCALL_EMULATION is not set > CONFIG_X86_X2APIC=y > -# CONFIG_X86_X32 is not set > CONFIG_XEN=y > CONFIG_XENFS=y > CONFIG_XEN_512GB=y > diff --git a/target/linux/x86/64/config-5.15 b/target/linux/x86/64/config-5.15 > index a20891ea55..39e5064e53 100644 > --- a/target/linux/x86/64/config-5.15 > +++ b/target/linux/x86/64/config-5.15 > @@ -493,7 +493,6 @@ CONFIG_X86_PM_TIMER=y > # CONFIG_X86_POWERNOW_K8 is not set > # CONFIG_X86_VSYSCALL_EMULATION is not set > CONFIG_X86_X2APIC=y > -# CONFIG_X86_X32 is not set > CONFIG_XEN=y > CONFIG_XENFS=y > CONFIG_XEN_512GB=y > diff --git a/target/linux/x86/config-5.10 b/target/linux/x86/config-5.10 > index afb7adc63a..8be829d549 100644 > --- a/target/linux/x86/config-5.10 > +++ b/target/linux/x86/config-5.10 > @@ -12,6 +12,7 @@ CONFIG_ARCH_HIBERNATION_POSSIBLE=y > CONFIG_ARCH_MAY_HAVE_PC_FDC=y > CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y > CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y > +CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8 > CONFIG_ARCH_RANDOM=y > CONFIG_ARCH_SELECT_MEMORY_MODEL=y > CONFIG_ARCH_SPARSEMEM_ENABLE=y > @@ -423,6 +424,7 @@ CONFIG_X86_UP_IOAPIC=y > CONFIG_X86_USE_PPRO_CHECKSUM=y > CONFIG_X86_VERBOSE_BOOTUP=y > CONFIG_X86_VMX_FEATURE_NAMES=y > +CONFIG_X86_X32=y > CONFIG_XZ_DEC_BCJ=y > CONFIG_XZ_DEC_X86=y > CONFIG_ZLIB_INFLATE=y > diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 > index b59e809127..afe66b27b1 100644 > --- a/target/linux/x86/config-5.15 > +++ b/target/linux/x86/config-5.15 > @@ -13,6 +13,7 @@ CONFIG_ARCH_MAY_HAVE_PC_FDC=y > CONFIG_ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE=y > CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y > CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y > +CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8 > CONFIG_ARCH_NR_GPIO=512 > CONFIG_ARCH_RANDOM=y > CONFIG_ARCH_SELECT_MEMORY_MODEL=y > @@ -428,6 +429,7 @@ CONFIG_X86_UP_IOAPIC=y > CONFIG_X86_USE_PPRO_CHECKSUM=y > CONFIG_X86_VERBOSE_BOOTUP=y > CONFIG_X86_VMX_FEATURE_NAMES=y > +CONFIG_X86_X32=y > CONFIG_XZ_DEC_BCJ=y > CONFIG_XZ_DEC_X86=y > CONFIG_ZLIB_INFLATE=y > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+open...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/9] (mostly) x86 kernel configuration adjustments
> On Apr 26, 2023, at 2:11 PM, Elliott Mitchell wrote: > > Now we come to the item I've mentioned. The X32 ABI. This is running an > amd64 processor in amd64 mode, but truncating all pointers to 32 bits > (ILP32 mode). This shrinks the runtime size of programs in exchange for > limiting them to a maximum of 4GB of memory. The result is often a > significant speed increase over both i386 and amd64 modes, largely due to > reducing memory use. > > For rather a lot of programs, 4GB of memory is plenty. Have you ever > observed `ls` or a shell use anywhere near that much? The fact most > devices running OpenWRT don't have that much *total* memory says the > limitation is worthwhile. Personally I don't want to relive thunking hell. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 8/9] kernel/x86: remove support for AGP
Reviewed-by: Philip Prindeville > On Apr 12, 2023, at 11:47 PM, Elliott Mitchell wrote: > > OpenWRT is not a graphics-oriented Linux distribution. There is no > need for AGP support in any standard OpenWRT kernel. > > Signed-off-by: Elliott Mitchell > --- > target/linux/x86/64/config-5.10 | 5 - > target/linux/x86/64/config-5.15 | 5 - > target/linux/x86/generic/config-5.10 | 11 --- > target/linux/x86/generic/config-5.15 | 11 --- > target/linux/x86/legacy/config-5.10 | 11 --- > target/linux/x86/legacy/config-5.15 | 11 --- > 6 files changed, 54 deletions(-) > > diff --git a/target/linux/x86/64/config-5.10 b/target/linux/x86/64/config-5.10 > index de93495fb1..b226b347bd 100644 > --- a/target/linux/x86/64/config-5.10 > +++ b/target/linux/x86/64/config-5.10 > @@ -33,11 +33,6 @@ CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ACRN_GUEST is not set > -CONFIG_AGP=y > -# CONFIG_AGP_AMD64 is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_VIA is not set > CONFIG_AMD_IOMMU=y > # CONFIG_AMD_IOMMU_V2 is not set > CONFIG_ARCH_CPUIDLE_HALTPOLL=y > diff --git a/target/linux/x86/64/config-5.15 b/target/linux/x86/64/config-5.15 > index 39e5064e53..7f5b80e54a 100644 > --- a/target/linux/x86/64/config-5.15 > +++ b/target/linux/x86/64/config-5.15 > @@ -36,11 +36,6 @@ CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ACRN_GUEST is not set > # CONFIG_ADV_SWBUTTON is not set > -CONFIG_AGP=y > -# CONFIG_AGP_AMD64 is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_VIA is not set > CONFIG_AMD_IOMMU=y > # CONFIG_AMD_IOMMU_V2 is not set > # CONFIG_AMD_PMC is not set > diff --git a/target/linux/x86/generic/config-5.10 > b/target/linux/x86/generic/config-5.10 > index e5359b..6da10e3776 100644 > --- a/target/linux/x86/generic/config-5.10 > +++ b/target/linux/x86/generic/config-5.10 > @@ -30,17 +30,6 @@ CONFIG_ACPI_TAD=y > CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -# CONFIG_AGP_VIA is not set > # CONFIG_APM is not set > CONFIG_ARCH_CPUIDLE_HALTPOLL=y > CONFIG_ARCH_DMA_ADDR_T_64BIT=y > diff --git a/target/linux/x86/generic/config-5.15 > b/target/linux/x86/generic/config-5.15 > index 5dbd432ce5..491e9737f5 100644 > --- a/target/linux/x86/generic/config-5.15 > +++ b/target/linux/x86/generic/config-5.15 > @@ -31,17 +31,6 @@ CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ADV_SWBUTTON is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -# CONFIG_AGP_VIA is not set > # CONFIG_AMD_PMC is not set > # CONFIG_APM is not set > CONFIG_ARCH_CPUIDLE_HALTPOLL=y > diff --git a/target/linux/x86/legacy/config-5.10 > b/target/linux/x86/legacy/config-5.10 > index 3a44ab45d6..e5284822a5 100644 > --- a/target/linux/x86/legacy/config-5.10 > +++ b/target/linux/x86/legacy/config-5.10 > @@ -27,17 +27,6 @@ CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y > CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -# CONFIG_AGP_VIA is not set > CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y > CONFIG_BACKLIGHT_CLASS_DEVICE=y > CONFIG_BLK_DEV_SR=y > diff --git a/target/linux/x86/legacy/config-5.15 > b/target/linux/x86/legacy/config-5.15 > index 74edf85abd..7e943138d4 100644 > --- a/target/linux/x86/legacy/config-5.15 > +++ b/target/linux/x86/legacy/config-5.15 > @@ -28,17 +28,6 @@ CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ADV_SWBUTTON is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTE
Re: [PATCH 8/9] kernel/x86: remove support for AGP
Reviewed-by: Philip Prindeville > On Apr 12, 2023, at 11:47 PM, Elliott Mitchell wrote: > > OpenWRT is not a graphics-oriented Linux distribution. There is no > need for AGP support in any standard OpenWRT kernel. > > Signed-off-by: Elliott Mitchell > --- > target/linux/x86/64/config-5.10 | 5 - > target/linux/x86/64/config-5.15 | 5 - > target/linux/x86/generic/config-5.10 | 11 --- > target/linux/x86/generic/config-5.15 | 11 --- > target/linux/x86/legacy/config-5.10 | 11 --- > target/linux/x86/legacy/config-5.15 | 11 --- > 6 files changed, 54 deletions(-) > > diff --git a/target/linux/x86/64/config-5.10 b/target/linux/x86/64/config-5.10 > index de93495fb1..b226b347bd 100644 > --- a/target/linux/x86/64/config-5.10 > +++ b/target/linux/x86/64/config-5.10 > @@ -33,11 +33,6 @@ CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ACRN_GUEST is not set > -CONFIG_AGP=y > -# CONFIG_AGP_AMD64 is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_VIA is not set > CONFIG_AMD_IOMMU=y > # CONFIG_AMD_IOMMU_V2 is not set > CONFIG_ARCH_CPUIDLE_HALTPOLL=y > diff --git a/target/linux/x86/64/config-5.15 b/target/linux/x86/64/config-5.15 > index 39e5064e53..7f5b80e54a 100644 > --- a/target/linux/x86/64/config-5.15 > +++ b/target/linux/x86/64/config-5.15 > @@ -36,11 +36,6 @@ CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ACRN_GUEST is not set > # CONFIG_ADV_SWBUTTON is not set > -CONFIG_AGP=y > -# CONFIG_AGP_AMD64 is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_VIA is not set > CONFIG_AMD_IOMMU=y > # CONFIG_AMD_IOMMU_V2 is not set > # CONFIG_AMD_PMC is not set > diff --git a/target/linux/x86/generic/config-5.10 > b/target/linux/x86/generic/config-5.10 > index e5359b..6da10e3776 100644 > --- a/target/linux/x86/generic/config-5.10 > +++ b/target/linux/x86/generic/config-5.10 > @@ -30,17 +30,6 @@ CONFIG_ACPI_TAD=y > CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -# CONFIG_AGP_VIA is not set > # CONFIG_APM is not set > CONFIG_ARCH_CPUIDLE_HALTPOLL=y > CONFIG_ARCH_DMA_ADDR_T_64BIT=y > diff --git a/target/linux/x86/generic/config-5.15 > b/target/linux/x86/generic/config-5.15 > index 5dbd432ce5..491e9737f5 100644 > --- a/target/linux/x86/generic/config-5.15 > +++ b/target/linux/x86/generic/config-5.15 > @@ -31,17 +31,6 @@ CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ADV_SWBUTTON is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -# CONFIG_AGP_VIA is not set > # CONFIG_AMD_PMC is not set > # CONFIG_APM is not set > CONFIG_ARCH_CPUIDLE_HALTPOLL=y > diff --git a/target/linux/x86/legacy/config-5.10 > b/target/linux/x86/legacy/config-5.10 > index 3a44ab45d6..e5284822a5 100644 > --- a/target/linux/x86/legacy/config-5.10 > +++ b/target/linux/x86/legacy/config-5.10 > @@ -27,17 +27,6 @@ CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y > CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -# CONFIG_AGP_VIA is not set > CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y > CONFIG_BACKLIGHT_CLASS_DEVICE=y > CONFIG_BLK_DEV_SR=y > diff --git a/target/linux/x86/legacy/config-5.15 > b/target/linux/x86/legacy/config-5.15 > index 74edf85abd..7e943138d4 100644 > --- a/target/linux/x86/legacy/config-5.15 > +++ b/target/linux/x86/legacy/config-5.15 > @@ -28,17 +28,6 @@ CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ADV_SWBUTTON is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL
Re: [PATCH 7/9] kernel/x86: remove all ISA support from non-legacy
Reviewed-by: Philip Prindeville > On Apr 13, 2023, at 9:58 PM, Elliott Mitchell wrote: > > While some older PCI motherboard might emulate some functions via > ISA, actual ISA is absent from anything non-legacy. Move ISA DMA > enabling to Geode and Legacy. > > Signed-off-by: Elliott Mitchell > --- > Question here is how far to go with removing ISA support? Certainly it > is appropriate to keep for the legacy build, but what of slightly more > recent hardware? Some i686 motherboards might have actual slots, but it > was quickly vestigial. > --- > target/linux/x86/config-5.10| 5 ++--- > target/linux/x86/config-5.15| 5 ++--- > target/linux/x86/geode/config-5.10 | 2 ++ > target/linux/x86/geode/config-5.15 | 2 ++ > target/linux/x86/legacy/config-5.10 | 2 ++ > target/linux/x86/legacy/config-5.15 | 2 ++ > 6 files changed, 12 insertions(+), 6 deletions(-) > > diff --git a/target/linux/x86/config-5.10 b/target/linux/x86/config-5.10 > index 8be829d549..98e0372247 100644 > --- a/target/linux/x86/config-5.10 > +++ b/target/linux/x86/config-5.10 > @@ -132,7 +132,6 @@ CONFIG_GENERIC_IOMAP=y > CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y > CONFIG_GENERIC_IRQ_RESERVATION_MODE=y > CONFIG_GENERIC_IRQ_SHOW=y > -CONFIG_GENERIC_ISA_DMA=y > CONFIG_GENERIC_MSI_IRQ=y > CONFIG_GENERIC_MSI_IRQ_DOMAIN=y > CONFIG_GENERIC_PCI_IOMAP=y > @@ -185,8 +184,8 @@ CONFIG_IRQ_DOMAIN=y > CONFIG_IRQ_DOMAIN_HIERARCHY=y > CONFIG_IRQ_FORCED_THREADING=y > CONFIG_IRQ_WORK=y > -# CONFIG_ISA is not set > -CONFIG_ISA_DMA_API=y > +CONFIG_ISA=n > +CONFIG_ISA_DMA_API=n > # CONFIG_IT8712F_WDT is not set > # CONFIG_IT87_WDT is not set > # CONFIG_ITCO_WDT is not set > diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 > index afe66b27b1..3805820416 100644 > --- a/target/linux/x86/config-5.15 > +++ b/target/linux/x86/config-5.15 > @@ -133,7 +133,6 @@ CONFIG_GENERIC_IOMAP=y > CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y > CONFIG_GENERIC_IRQ_RESERVATION_MODE=y > CONFIG_GENERIC_IRQ_SHOW=y > -CONFIG_GENERIC_ISA_DMA=y > CONFIG_GENERIC_MSI_IRQ=y > CONFIG_GENERIC_MSI_IRQ_DOMAIN=y > CONFIG_GENERIC_PCI_IOMAP=y > @@ -187,8 +186,8 @@ CONFIG_IRQ_DOMAIN=y > CONFIG_IRQ_DOMAIN_HIERARCHY=y > CONFIG_IRQ_FORCED_THREADING=y > CONFIG_IRQ_WORK=y > -# CONFIG_ISA is not set > -CONFIG_ISA_DMA_API=y > +CONFIG_ISA=n > +CONFIG_ISA_DMA_API=n > # CONFIG_IT8712F_WDT is not set > # CONFIG_IT87_WDT is not set > # CONFIG_ITCO_WDT is not set > diff --git a/target/linux/x86/geode/config-5.10 > b/target/linux/x86/geode/config-5.10 > index 30b358b050..632e1fb7b7 100644 > --- a/target/linux/x86/geode/config-5.10 > +++ b/target/linux/x86/geode/config-5.10 > @@ -42,6 +42,7 @@ CONFIG_CS5535_MFGPT=y > CONFIG_CS5535_MFGPT_DEFAULT_IRQ=7 > CONFIG_DMA_ACPI=y > # CONFIG_EL3 is not set > +CONFIG_GENERIC_ISA_DMA=y > CONFIG_GEODE_WDT=y > CONFIG_GEOS=y > CONFIG_GPIO_ACPI=y > @@ -67,6 +68,7 @@ CONFIG_IOSF_MBI=y > CONFIG_ISA=y > # CONFIG_ISAPNP is not set > CONFIG_ISA_BUS_API=y > +CONFIG_ISA_DMA_API=y > # CONFIG_ISCSI_IBFT is not set > # CONFIG_LANCE is not set > CONFIG_LEDS_GPIO=y > diff --git a/target/linux/x86/geode/config-5.15 > b/target/linux/x86/geode/config-5.15 > index 0c54cdaf9e..deaf2123d4 100644 > --- a/target/linux/x86/geode/config-5.15 > +++ b/target/linux/x86/geode/config-5.15 > @@ -45,6 +45,7 @@ CONFIG_CS5535_MFGPT_DEFAULT_IRQ=7 > # CONFIG_CS89x0_ISA is not set > CONFIG_DMA_ACPI=y > # CONFIG_EL3 is not set > +CONFIG_GENERIC_ISA_DMA=y > CONFIG_GEODE_WDT=y > CONFIG_GEOS=y > CONFIG_GPIO_ACPI=y > @@ -74,6 +75,7 @@ CONFIG_IOSF_MBI=y > CONFIG_ISA=y > # CONFIG_ISAPNP is not set > CONFIG_ISA_BUS_API=y > +CONFIG_ISA_DMA_API=y > # CONFIG_ISCSI_IBFT is not set > # CONFIG_LANCE is not set > CONFIG_LEDS_GPIO=y > diff --git a/target/linux/x86/legacy/config-5.10 > b/target/linux/x86/legacy/config-5.10 > index a11eca8fc2..3a44ab45d6 100644 > --- a/target/linux/x86/legacy/config-5.10 > +++ b/target/linux/x86/legacy/config-5.10 > @@ -106,6 +106,7 @@ CONFIG_FONT_SUPPORT=y > CONFIG_FRAMEBUFFER_CONSOLE=y > CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y > # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set > +CONFIG_GENERIC_ISA_DMA=y > CONFIG_HDMI=y > CONFIG_HID_BATTERY_STRENGTH=y > # CONFIG_HIGHMEM4G is not set > @@ -136,6 +137,7 @@ CONFIG_IOSF_MBI=y > CONFIG_ISA=y > CONFIG_ISAPNP=y > CONFIG_ISA_BUS_API=y > +CONFIG_ISA_DMA_API=y > # CONFIG_ISCSI_IBFT is not set > CONFIG_ISO9660_FS=y > # CONFIG_JOLIET is not set > diff --git a/target/linux/x86/legacy/config-5.15 > b/target/linux/x86/legacy/config-5.15 > index b424147073..74edf85abd 100644 > --- a/target/linux/x86/legacy/config
Re: [PATCH 5/9] kernel/x86: remove CONFIG_M686 from common configuration
Reviewed-by: Philip Prindeville > On Apr 17, 2023, at 9:21 AM, Elliott Mitchell wrote: > > All of the sublevels choose their own values, so there is no point > in the common file having anything. This also removes a warning from > the kernel build process. > > Signed-off-by: Elliott Mitchell > --- > target/linux/x86/config-5.10 | 2 +- > target/linux/x86/config-5.15 | 2 +- > target/linux/x86/generic/config-5.10 | 1 - > target/linux/x86/generic/config-5.15 | 1 - > target/linux/x86/geode/config-5.10 | 1 - > target/linux/x86/geode/config-5.15 | 1 - > target/linux/x86/legacy/config-5.10 | 1 - > target/linux/x86/legacy/config-5.15 | 1 - > 8 files changed, 2 insertions(+), 8 deletions(-) > > diff --git a/target/linux/x86/config-5.10 b/target/linux/x86/config-5.10 > index f6c5400e73..afb7adc63a 100644 > --- a/target/linux/x86/config-5.10 > +++ b/target/linux/x86/config-5.10 > @@ -201,7 +201,7 @@ CONFIG_LOCK_DEBUGGING_SUPPORT=y > # CONFIG_M586 is not set > # CONFIG_M586MMX is not set > # CONFIG_M586TSC is not set > -CONFIG_M686=y > +# CONFIG_M686 is not set > # CONFIG_MACHZ_WDT is not set > # CONFIG_MATOM is not set > # CONFIG_MCORE2 is not set > diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 > index f572a62e85..b59e809127 100644 > --- a/target/linux/x86/config-5.15 > +++ b/target/linux/x86/config-5.15 > @@ -204,7 +204,7 @@ CONFIG_LOCK_DEBUGGING_SUPPORT=y > # CONFIG_M586 is not set > # CONFIG_M586MMX is not set > # CONFIG_M586TSC is not set > -CONFIG_M686=y > +# CONFIG_M686 is not set > # CONFIG_MACHZ_WDT is not set > # CONFIG_MATOM is not set > # CONFIG_MCORE2 is not set > diff --git a/target/linux/x86/generic/config-5.10 > b/target/linux/x86/generic/config-5.10 > index b683720bf8..e5359b 100644 > --- a/target/linux/x86/generic/config-5.10 > +++ b/target/linux/x86/generic/config-5.10 > @@ -235,7 +235,6 @@ CONFIG_KVM_XFER_TO_GUEST_WORK=y > # CONFIG_LANCE is not set > CONFIG_LIBNVDIMM=y > CONFIG_LOCK_SPIN_ON_OWNER=y > -# CONFIG_M686 is not set > # CONFIG_MDA_CONSOLE is not set > CONFIG_MEMORY_BALLOON=y > CONFIG_MEMREGION=y > diff --git a/target/linux/x86/generic/config-5.15 > b/target/linux/x86/generic/config-5.15 > index 1da6ad555d..5dbd432ce5 100644 > --- a/target/linux/x86/generic/config-5.15 > +++ b/target/linux/x86/generic/config-5.15 > @@ -242,7 +242,6 @@ CONFIG_KVM_XFER_TO_GUEST_WORK=y > # CONFIG_LANCE is not set > CONFIG_LIBNVDIMM=y > CONFIG_LOCK_SPIN_ON_OWNER=y > -# CONFIG_M686 is not set > # CONFIG_MDA_CONSOLE is not set > CONFIG_MEMORY_BALLOON=y > CONFIG_MEMREGION=y > diff --git a/target/linux/x86/geode/config-5.10 > b/target/linux/x86/geode/config-5.10 > index 4c661cdf19..30b358b050 100644 > --- a/target/linux/x86/geode/config-5.10 > +++ b/target/linux/x86/geode/config-5.10 > @@ -70,7 +70,6 @@ CONFIG_ISA_BUS_API=y > # CONFIG_ISCSI_IBFT is not set > # CONFIG_LANCE is not set > CONFIG_LEDS_GPIO=y > -# CONFIG_M686 is not set > # CONFIG_MDA_CONSOLE is not set > CONFIG_MFD_CORE=y > CONFIG_MFD_CS5535=y > diff --git a/target/linux/x86/geode/config-5.15 > b/target/linux/x86/geode/config-5.15 > index ca4e0abc28..0c54cdaf9e 100644 > --- a/target/linux/x86/geode/config-5.15 > +++ b/target/linux/x86/geode/config-5.15 > @@ -77,7 +77,6 @@ CONFIG_ISA_BUS_API=y > # CONFIG_ISCSI_IBFT is not set > # CONFIG_LANCE is not set > CONFIG_LEDS_GPIO=y > -# CONFIG_M686 is not set > # CONFIG_MDA_CONSOLE is not set > CONFIG_MFD_CORE=y > CONFIG_MFD_CS5535=y > diff --git a/target/linux/x86/legacy/config-5.10 > b/target/linux/x86/legacy/config-5.10 > index 12330ba92f..a11eca8fc2 100644 > --- a/target/linux/x86/legacy/config-5.10 > +++ b/target/linux/x86/legacy/config-5.10 > @@ -142,7 +142,6 @@ CONFIG_ISO9660_FS=y > CONFIG_KCMP=y > # CONFIG_LANCE is not set > CONFIG_M586MMX=y > -# CONFIG_M686 is not set > # CONFIG_MDA_CONSOLE is not set > CONFIG_MFD_CORE=y > CONFIG_MFD_INTEL_LPSS=y > diff --git a/target/linux/x86/legacy/config-5.15 > b/target/linux/x86/legacy/config-5.15 > index a75ce40ab4..b424147073 100644 > --- a/target/linux/x86/legacy/config-5.15 > +++ b/target/linux/x86/legacy/config-5.15 > @@ -148,7 +148,6 @@ CONFIG_ISO9660_FS=y > CONFIG_KCMP=y > # CONFIG_LANCE is not set > CONFIG_M586MMX=y > -# CONFIG_M686 is not set > # CONFIG_MDA_CONSOLE is not set > CONFIG_MFD_CORE=y > CONFIG_MFD_INTEL_LPSS=y > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+open...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 4/9] kernel/x86: move SCx200 support from generic to geode
Reviewed-by: Philip Prindeville > On Apr 13, 2023, at 6:07 PM, Elliott Mitchell wrote: > > The SCx200 is part of the Geode platform. As such generic x86 > doesn't need the driver, but Geode does. > > Signed-off-by: Elliott Mitchell > --- > target/linux/x86/config-5.10 | 5 + > target/linux/x86/config-5.15 | 5 + > target/linux/x86/geode/config-5.10 | 3 +++ > target/linux/x86/geode/config-5.15 | 3 +++ > 4 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/target/linux/x86/config-5.10 b/target/linux/x86/config-5.10 > index cfd580b282..f6c5400e73 100644 > --- a/target/linux/x86/config-5.10 > +++ b/target/linux/x86/config-5.10 > @@ -305,10 +305,7 @@ CONFIG_SATA_HOST=y > # CONFIG_SC1200_WDT is not set > CONFIG_SCSI=y > CONFIG_SCSI_SPI_ATTRS=y > -CONFIG_SCx200=y > -CONFIG_SCx200HR_TIMER=y > -# CONFIG_SCx200_GPIO is not set > -# CONFIG_SCx200_WDT is not set > +# CONFIG_SCx200 is not set > CONFIG_SERIAL_8250_PCI=y > # CONFIG_SERIAL_LANTIQ is not set > CONFIG_SERIO=y > diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 > index acfaa0e4b7..f572a62e85 100644 > --- a/target/linux/x86/config-5.15 > +++ b/target/linux/x86/config-5.15 > @@ -309,10 +309,7 @@ CONFIG_SATA_HOST=y > CONFIG_SCSI=y > CONFIG_SCSI_COMMON=y > CONFIG_SCSI_SPI_ATTRS=y > -CONFIG_SCx200=y > -CONFIG_SCx200HR_TIMER=y > -# CONFIG_SCx200_GPIO is not set > -# CONFIG_SCx200_WDT is not set > +# CONFIG_SCx200 is not set > CONFIG_SERIAL_8250_PCI=y > # CONFIG_SERIAL_LANTIQ is not set > CONFIG_SERIO=y > diff --git a/target/linux/x86/geode/config-5.10 > b/target/linux/x86/geode/config-5.10 > index dc2ac4454b..4c661cdf19 100644 > --- a/target/linux/x86/geode/config-5.10 > +++ b/target/linux/x86/geode/config-5.10 > @@ -112,7 +112,10 @@ CONFIG_RTC_I2C_AND_SPI=y > # CONFIG_SAMSUNG_Q10 is not set > CONFIG_SC1200_WDT=y > # CONFIG_SCSI_FDOMAIN_ISA is not set > +CONFIG_SCx200=y > +CONFIG_SCx200HR_TIMER=y > CONFIG_SCx200_ACB=y > +# CONFIG_SCx200_GPIO is not set > CONFIG_SCx200_WDT=y > # CONFIG_SENSORS_AMD_ENERGY is not set > CONFIG_SENSORS_LM90=y > diff --git a/target/linux/x86/geode/config-5.15 > b/target/linux/x86/geode/config-5.15 > index 2a8db278b3..ca4e0abc28 100644 > --- a/target/linux/x86/geode/config-5.15 > +++ b/target/linux/x86/geode/config-5.15 > @@ -122,7 +122,10 @@ CONFIG_RTC_I2C_AND_SPI=y > # CONFIG_SAMSUNG_Q10 is not set > CONFIG_SC1200_WDT=y > # CONFIG_SCSI_FDOMAIN_ISA is not set > +CONFIG_SCx200=y > +CONFIG_SCx200HR_TIMER=y > CONFIG_SCx200_ACB=y > +# CONFIG_SCx200_GPIO is not set > CONFIG_SCx200_WDT=y > CONFIG_SENSORS_LM90=y > CONFIG_SERIAL_8250_PNP=y > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+open...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/9] kernel/x86: move Geode HW random from generic to geode
Reviewed-by: Philip Prindeville > On Apr 19, 2023, at 3:07 PM, Elliott Mitchell wrote: > > Quite reasonable to have support for the Geode HW random number > generator. On the Geode kernel. > > Support for the VIA HWRNG has been enabled in common. Pull that > from the Geode kernel. > > Signed-off-by: Elliott Mitchell > --- > target/linux/x86/config-5.10 | 1 - > target/linux/x86/config-5.15 | 1 - > target/linux/x86/geode/config-5.10 | 2 ++ > target/linux/x86/geode/config-5.15 | 2 ++ > 4 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/target/linux/x86/config-5.10 b/target/linux/x86/config-5.10 > index 1a2f0d653a..cfd580b282 100644 > --- a/target/linux/x86/config-5.10 > +++ b/target/linux/x86/config-5.10 > @@ -156,7 +156,6 @@ CONFIG_HPET_EMULATE_RTC=y > CONFIG_HPET_TIMER=y > # CONFIG_HP_WATCHDOG is not set > CONFIG_HW_CONSOLE=y > -CONFIG_HW_RANDOM_GEODE=y > CONFIG_HW_RANDOM_VIA=y > # CONFIG_HYPERVISOR_GUEST is not set > CONFIG_HZ_PERIODIC=y > diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 > index 715090977b..acfaa0e4b7 100644 > --- a/target/linux/x86/config-5.15 > +++ b/target/linux/x86/config-5.15 > @@ -157,7 +157,6 @@ CONFIG_HPET_EMULATE_RTC=y > CONFIG_HPET_TIMER=y > # CONFIG_HP_WATCHDOG is not set > CONFIG_HW_CONSOLE=y > -CONFIG_HW_RANDOM_GEODE=y > CONFIG_HW_RANDOM_VIA=y > # CONFIG_HYPERVISOR_GUEST is not set > CONFIG_HZ_PERIODIC=y > diff --git a/target/linux/x86/geode/config-5.10 > b/target/linux/x86/geode/config-5.10 > index 579f316914..dc2ac4454b 100644 > --- a/target/linux/x86/geode/config-5.10 > +++ b/target/linux/x86/geode/config-5.10 > @@ -49,6 +49,8 @@ CONFIG_GPIO_CS5535=y > # CONFIG_HPET is not set > # CONFIG_HP_ACCEL is not set > CONFIG_HWMON=y > +CONFIG_HW_RANDOM_GEODE=y > +CONFIG_HW_RANDOM_VIA=n > CONFIG_I2C=y > CONFIG_I2C_ALGOBIT=y > CONFIG_I2C_ALGOPCA=y > diff --git a/target/linux/x86/geode/config-5.15 > b/target/linux/x86/geode/config-5.15 > index 2ede23ea5e..2a8db278b3 100644 > --- a/target/linux/x86/geode/config-5.15 > +++ b/target/linux/x86/geode/config-5.15 > @@ -53,6 +53,8 @@ CONFIG_GPIO_CS5535=y > # CONFIG_HPET is not set > # CONFIG_HP_ACCEL is not set > CONFIG_HWMON=y > +CONFIG_HW_RANDOM_GEODE=y > +CONFIG_HW_RANDOM_VIA=n > CONFIG_I2C=y > CONFIG_I2C_ALGOBIT=y > CONFIG_I2C_ALGOPCA=y > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+open...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/9] kernel: change CONFIG_HW_RANDOM default to y
Why isn't this migrating upwards into target/linux/generic/config-5.15 and target/linux/generic/config-5.10 in that case? And for the platforms where it was turned off, like target/linux/armvirt/32/config-5.15, why isn't that staying unchanged? > On Apr 22, 2023, at 11:46 AM, Elliott Mitchell wrote: > > Many devices do not have hardware random number generators. Yet > more do than don't, and they are becoming more common. > > Signed-off-by: Elliott Mitchell > --- > target/linux/airoha/config-5.15 | 1 - > target/linux/apm821xx/config-5.10 | 1 - > target/linux/apm821xx/config-5.15 | 1 - > target/linux/archs38/config-5.10| 1 + > target/linux/archs38/config-5.15| 1 + > target/linux/armvirt/32/config-5.10 | 1 + > target/linux/armvirt/32/config-5.15 | 1 + > target/linux/armvirt/64/config-5.10 | 1 - > target/linux/armvirt/64/config-5.15 | 1 - > target/linux/ath25/config-5.10 | 1 - > target/linux/ath79/config-5.10 | 1 + > target/linux/ath79/config-5.15 | 1 + > target/linux/bcm47xx/config-5.10| 1 - > target/linux/bcm47xx/config-5.15| 1 - > target/linux/bcm4908/config-5.10| 1 + > target/linux/bcm4908/config-5.15| 1 + > target/linux/bcm53xx/config-5.10| 1 - > target/linux/bcm53xx/config-5.15| 1 - > target/linux/bcm63xx/config-5.15| 1 - > target/linux/gemini/config-5.10 | 1 + > target/linux/gemini/config-5.15 | 1 - > target/linux/generic/config-5.10| 2 +- > target/linux/generic/config-5.15| 2 +- > target/linux/imx/config-5.15| 1 - > target/linux/ipq40xx/config-5.15| 1 - > target/linux/ipq806x/config-5.10| 1 - > target/linux/ipq806x/config-5.15| 1 - > target/linux/ipq807x/config-5.15| 1 + > target/linux/kirkwood/config-5.10 | 1 - > target/linux/kirkwood/config-5.15 | 1 - > target/linux/lantiq/ase/config-5.10 | 1 - > target/linux/lantiq/ase/config-5.15 | 1 - > target/linux/lantiq/falcon/config-5.10 | 1 + > target/linux/lantiq/falcon/config-5.15 | 1 + > target/linux/lantiq/xrx200/config-5.10 | 1 - > target/linux/lantiq/xrx200/config-5.15 | 1 - > target/linux/lantiq/xway/config-5.10| 1 - > target/linux/lantiq/xway/config-5.15| 1 - > target/linux/lantiq/xway_legacy/config-5.10 | 1 + > target/linux/lantiq/xway_legacy/config-5.15 | 1 + > target/linux/malta/config-5.10 | 1 + > target/linux/malta/config-5.15 | 1 + > target/linux/mpc85xx/config-5.10| 1 - > target/linux/mpc85xx/config-5.15| 1 - > target/linux/mvebu/config-5.10 | 1 - > target/linux/mvebu/config-5.15 | 1 - > target/linux/mxs/config-5.15| 1 + > target/linux/octeon/config-5.10 | 1 - > target/linux/octeon/config-5.15 | 1 - > target/linux/octeontx/config-5.15 | 1 - > target/linux/omap/config-5.10 | 1 - > target/linux/omap/config-5.15 | 1 - > target/linux/oxnas/config-5.15 | 1 + > target/linux/pistachio/config-5.10 | 1 + > target/linux/pistachio/config-5.15 | 1 + > target/linux/qoriq/config-5.15 | 1 - > target/linux/sunxi/config-5.15 | 1 - > target/linux/tegra/config-5.10 | 1 + > target/linux/tegra/config-5.15 | 1 + > target/linux/uml/config-5.10| 1 - > target/linux/uml/config-5.15| 1 - > target/linux/x86/config-5.10| 1 - > target/linux/x86/config-5.15| 1 - > target/linux/zynq/config-5.15 | 1 + > 64 files changed, 25 insertions(+), 41 deletions(-) > > diff --git a/target/linux/airoha/config-5.15 b/target/linux/airoha/config-5.15 > index adc8cdfb9b..cdee4b2d51 100644 > --- a/target/linux/airoha/config-5.15 > +++ b/target/linux/airoha/config-5.15 > @@ -128,7 +128,6 @@ CONFIG_HAS_IOMEM=y > CONFIG_HAS_IOPORT_MAP=y > CONFIG_HAVE_SMP=y > CONFIG_HOTPLUG_CPU=y > -CONFIG_HW_RANDOM=y > CONFIG_HZ_FIXED=0 > CONFIG_INITRAMFS_SOURCE="" > # CONFIG_IOMMU_DEBUGFS is not set > diff --git a/target/linux/apm821xx/config-5.10 > b/target/linux/apm821xx/config-5.10 > index 89d72e2641..6fcb9e4803 100644 > --- a/target/linux/apm821xx/config-5.10 > +++ b/target/linux/apm821xx/config-5.10 > @@ -97,7 +97,6 @@ CONFIG_GPIO_GENERIC_PLATFORM=y > CONFIG_HAS_DMA=y > CONFIG_HAS_IOMEM=y > CONFIG_HAS_IOPORT_MAP=y > -CONFIG_HW_RANDOM=y > CONFIG_HW_RANDOM_PPC4XX=y > CONFIG_I2C=y > CONFIG_I2C_BOARDINFO=y > diff --git a/target/linux/apm821xx/config-5.15 > b/target/linux/apm821xx/config-5.15 > index 2af8110553..fddf0cd4e2 100644 > --- a/target/linux/apm821xx/config-5.15 > +++ b/target/linux/apm821xx/config-5.15 > @@ -96,7 +96,6 @@ CONFIG_GPIO_GENERIC_PLATFORM=y > CONFIG_HAS_DMA=y > CONFIG_HAS_IOMEM=y
Re: [PATCH 2/8] kernel/x86: move SCx200 support from generic to geode
Reviewed-by: Philip Prindeville > On Apr 13, 2023, at 6:07 PM, Elliott Mitchell wrote: > > The SCx200 is part of the Geode platform. As such generic x86 > doesn't need the driver, but Geode does. > > Signed-off-by: Elliott Mitchell > --- > target/linux/x86/config-5.10 | 5 + > target/linux/x86/config-5.15 | 5 + > target/linux/x86/geode/config-5.10 | 3 +++ > target/linux/x86/geode/config-5.15 | 3 +++ > 4 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/target/linux/x86/config-5.10 b/target/linux/x86/config-5.10 > index d7eb89bd6e..cdf636d05f 100644 > --- a/target/linux/x86/config-5.10 > +++ b/target/linux/x86/config-5.10 > @@ -307,10 +307,7 @@ CONFIG_SATA_HOST=y > # CONFIG_SC1200_WDT is not set > CONFIG_SCSI=y > CONFIG_SCSI_SPI_ATTRS=y > -CONFIG_SCx200=y > -CONFIG_SCx200HR_TIMER=y > -# CONFIG_SCx200_GPIO is not set > -# CONFIG_SCx200_WDT is not set > +CONFIG_SCx200=n > CONFIG_SERIAL_8250_PCI=y > # CONFIG_SERIAL_LANTIQ is not set > CONFIG_SERIO=y > diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 > index bf1c7bf8d5..b738358216 100644 > --- a/target/linux/x86/config-5.15 > +++ b/target/linux/x86/config-5.15 > @@ -311,10 +311,7 @@ CONFIG_SATA_HOST=y > CONFIG_SCSI=y > CONFIG_SCSI_COMMON=y > CONFIG_SCSI_SPI_ATTRS=y > -CONFIG_SCx200=y > -CONFIG_SCx200HR_TIMER=y > -# CONFIG_SCx200_GPIO is not set > -# CONFIG_SCx200_WDT is not set > +CONFIG_SCx200=n > CONFIG_SERIAL_8250_PCI=y > # CONFIG_SERIAL_LANTIQ is not set > CONFIG_SERIO=y > diff --git a/target/linux/x86/geode/config-5.10 > b/target/linux/x86/geode/config-5.10 > index 579f316914..9ef5101c14 100644 > --- a/target/linux/x86/geode/config-5.10 > +++ b/target/linux/x86/geode/config-5.10 > @@ -110,7 +110,10 @@ CONFIG_RTC_I2C_AND_SPI=y > # CONFIG_SAMSUNG_Q10 is not set > CONFIG_SC1200_WDT=y > # CONFIG_SCSI_FDOMAIN_ISA is not set > +CONFIG_SCx200=y > +CONFIG_SCx200HR_TIMER=y > CONFIG_SCx200_ACB=y > +# CONFIG_SCx200_GPIO is not set > CONFIG_SCx200_WDT=y > # CONFIG_SENSORS_AMD_ENERGY is not set > CONFIG_SENSORS_LM90=y > diff --git a/target/linux/x86/geode/config-5.15 > b/target/linux/x86/geode/config-5.15 > index 2ede23ea5e..d39c305811 100644 > --- a/target/linux/x86/geode/config-5.15 > +++ b/target/linux/x86/geode/config-5.15 > @@ -120,7 +120,10 @@ CONFIG_RTC_I2C_AND_SPI=y > # CONFIG_SAMSUNG_Q10 is not set > CONFIG_SC1200_WDT=y > # CONFIG_SCSI_FDOMAIN_ISA is not set > +CONFIG_SCx200=y > +CONFIG_SCx200HR_TIMER=y > CONFIG_SCx200_ACB=y > +# CONFIG_SCx200_GPIO is not set > CONFIG_SCx200_WDT=y > CONFIG_SENSORS_LM90=y > CONFIG_SERIAL_8250_PNP=y > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+open...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] netifd: add support of GRE tunnel ignore-df option
I'm not sure you want it to be unconditional.
When I wrote the option for netlink and iproute2, it was for some very
specialized scenarios.
> On Apr 24, 2023, at 3:14 AM, Stefan Hellermann wrote:
>
> I have an easier patch in my private repo, maybe it's enough without a new
> configuration option? I'm using it in production for a gretap link which is
> bridged on both sides to MTU 1500 ethernet links.
>
> See https://bugzilla.kernel.org/show_bug.cgi?id=14837, which seems to say you
> always have to use both options: ignore-df nopmtudisc
>
> Signed-off-by: Stefan Hellermann
>
> --- a/system-linux.c
> +++ b/system-linux.c
> @@ -3496,6 +3496,7 @@ static int system_add_gre_tunnel(const c
> ttl = 64;
>
> nla_put_u8(nlm, IFLA_GRE_PMTUDISC, set_df ? 1 : 0);
> +nla_put_u8(nlm, IFLA_GRE_IGNORE_DF, set_df ? 0 : 1);
>
> nla_put_u8(nlm, IFLA_GRE_TOS, tos);
> }
>
> Am 17.04.23 um 11:29 schrieb Denis Kalashnikov:
>> This is useful for GRE TAP tunnel when tunnel is added to a br-lan bridge.
>> In this case you need to create it with "nopmtudisc ignore-df". Otherwise
>> large IP-packets with DF=1 (TCP-data, large pings) will be silently dropped
>> (since DF=1 but stack failed to send ICMP "need fragmentation" back). But
>> with
>> "ignore-df" packets with DF=1 will be fragmented.
>>
>> Signed-off-by: Denis Kalashnikov
>> ---
>> system-linux.c | 5 +
>> system.c | 1 +
>> system.h | 1 +
>> 3 files changed, 7 insertions(+)
>>
>> diff --git a/system-linux.c b/system-linux.c
>> index e4041fb..4397460 100644
>> --- a/system-linux.c
>> +++ b/system-linux.c
>> @@ -3500,6 +3500,11 @@ static int system_add_gre_tunnel(const char *name,
>> const char *kind,
>> nla_put_u8(nlm, IFLA_GRE_PMTUDISC, set_df ? 1 : 0);
>> + if ((cur = tb[TUNNEL_ATTR_IGNORE_DF])) {
>> + nla_put_u8(nlm, IFLA_GRE_IGNORE_DF,
>> + blobmsg_get_bool(cur));
>> + }
>> +
>> nla_put_u8(nlm, IFLA_GRE_TOS, tos);
>> }
>> diff --git a/system.c b/system.c
>> index 32597c1..e773245 100644
>> --- a/system.c
>> +++ b/system.c
>> @@ -21,6 +21,7 @@ static const struct blobmsg_policy
>> tunnel_attrs[__TUNNEL_ATTR_MAX] = {
>> [TUNNEL_ATTR_REMOTE] = { .name = "remote", .type = BLOBMSG_TYPE_STRING },
>> [TUNNEL_ATTR_MTU] = { .name = "mtu", .type = BLOBMSG_TYPE_INT32 },
>> [TUNNEL_ATTR_DF] = { .name = "df", .type = BLOBMSG_TYPE_BOOL },
>> + [TUNNEL_ATTR_IGNORE_DF] = { .name = "ignore-df", .type = BLOBMSG_TYPE_BOOL
>> },
>> [TUNNEL_ATTR_TTL] = { .name = "ttl", .type = BLOBMSG_TYPE_INT32 },
>> [TUNNEL_ATTR_TOS] = { .name = "tos", .type = BLOBMSG_TYPE_STRING },
>> [TUNNEL_ATTR_LINK] = { .name = "link", .type = BLOBMSG_TYPE_STRING },
>> diff --git a/system.h b/system.h
>> index 1f7037d..a7a713d 100644
>> --- a/system.h
>> +++ b/system.h
>> @@ -29,6 +29,7 @@ enum tunnel_param {
>> TUNNEL_ATTR_LOCAL,
>> TUNNEL_ATTR_MTU,
>> TUNNEL_ATTR_DF,
>> + TUNNEL_ATTR_IGNORE_DF,
>> TUNNEL_ATTR_TTL,
>> TUNNEL_ATTR_TOS,
>> TUNNEL_ATTR_LINK,
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Virtualization issues w/ recent images
Hi, I built an image today for x86_64/generic with a recent sync to master on openwrt and packages. I dd'd the image (squashfs-combined) to the raw disk, zero padded the disk to grow it, and booted. The VM comes up with the following devices: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ip6tnl0@NONE: mtu 1452 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/tunnel6 :: brd :: permaddr 6efb:55c3:e992:: 3: tunl0@NONE: mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/ipip 0.0.0.0 brd 0.0.0.0 4: sit0@NONE: mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/sit 0.0.0.0 brd 0.0.0.0 5: dummy0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/ether 96:e1:89:d6:a2:3e brd ff:ff:ff:ff:ff:ff 6: eth0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000\link/ether 52:54:00:e0:53:8c brd ff:ff:ff:ff:ff:ff 7: eth1: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/ether 52:54:00:b0:7f:fa brd ff:ff:ff:ff:ff:ff 8: gre0@NONE: mtu 1476 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/gre 0.0.0.0 brd 0.0.0.0 9: gretap0@NONE: mtu 1462 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 10: erspan0@NONE: mtu 1450 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 11: ip6gre0@NONE: mtu 1448 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/gre6 :: brd :: permaddr e61c:48fa:cb53:: 12: teql0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 100\link/void But looking at the console: [4.063546] igbvf: Intel(R) Gigabit Virtual Function Network Driver [4.065506] igbvf: Copyright (c) 2009 - 2012 Intel Corporation. [4.075553] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver [4.077456] ixgbe: Copyright (c) 1999-2016 Intel Corporation. [4.081776] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver [4.084057] ixgbevf: Copyright (c) 2009 - 2018 Intel Corporation. [4.101502] ixgbevf :00:03.0: 52:54:00:e0:53:8c [4.103049] ixgbevf :00:03.0: MAC: 4 [4.104268] ixgbevf :00:03.0: Intel(R) 82599 Virtual Function [4.121116] ixgbevf :00:04.0: 52:54:00:b0:7f:fa [4.122630] ixgbevf :00:04.0: MAC: 4 [4.123839] ixgbevf :00:04.0: Intel(R) 82599 Virtual Function ... [6.538991] 8021q: adding VLAN 0 to HW filter on device eth0 [6.541444] ixgbevf :00:03.0: NIC Link is Up 10 Gbps [6.542867] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready It seems like "eth0" is only ever getting tickled, not "eth1". Is there a way to debug this and figure out what's going on? I can bring up the interface just fine manually: root@OpenWrt-bios2:~# ip addr add 24.116.100.91/255.255.255.248 broadcast 24.116.100.95 dev eth1 root@OpenWrt-bios2:~# ip link set up dev eth1 root@OpenWrt-bios2:~# ip route add 0/0 via 24.116.100.89 dev eth1 proto static root@OpenWrt-bios2:~# ping -c5 24.116.100.89 PING 24.116.100.89 (24.116.100.89): 56 data bytes 64 bytes from 24.116.100.89: seq=0 ttl=64 time=1.160 ms 64 bytes from 24.116.100.89: seq=1 ttl=64 time=1.475 ms 64 bytes from 24.116.100.89: seq=2 ttl=64 time=1.809 ms 64 bytes from 24.116.100.89: seq=3 ttl=64 time=1.610 ms 64 bytes from 24.116.100.89: seq=4 ttl=64 time=0.731 ms --- 24.116.100.89 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.731/1.357/1.809 ms root@OpenWrt-bios2:~# What am I missing? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Build problems with packages which are using openssl
I don't know if it's related, but syslog-ng-3.38.1 and now -4.1.1 keep crashing in libssl.so. [ 7263.710130] syslog-ng[6648]: segfault at 180 ip 7fe55725dd43 sp 7de33ed8 error 6 in libssl.so.3[7fe557252000+45000] [ 7263.715174] Code: e8 03 00 ff 15 8e dc 05 00 31 d2 31 c0 be 11 01 00 00 bf 14 00 00 00 ff 15 f2 d8 05 00 31 c0 5a c3 89 d1 48 8d 87 88 01 00 00 <48> 89 8f 80 01 00 00 48 39 f0 73 09 48 8d 14 08 48 39 d6 eb 0c 48 [ 7296.292439] syslog-ng[6767]: segfault at 180 ip 7fa446859d43 sp 7ffcb4e2dac8 error 6 in libssl.so.3[7fa44684e000+45000] [ 7296.297398] Code: e8 03 00 ff 15 8e dc 05 00 31 d2 31 c0 be 11 01 00 00 bf 14 00 00 00 ff 15 f2 d8 05 00 31 c0 5a c3 89 d1 48 8d 87 88 01 00 00 <48> 89 8f 80 01 00 00 48 39 f0 73 09 48 8d 14 08 48 39 d6 eb 0c 48 [ 7313.742858] syslog-ng[6832]: segfault at 180 ip 7f81280f0d43 sp 7fffcebbf898 error 6 in libssl.so.3[7f81280e5000+45000] [ 7313.747486] Code: e8 03 00 ff 15 8e dc 05 00 31 d2 31 c0 be 11 01 00 00 bf 14 00 00 00 ff 15 f2 d8 05 00 31 c0 5a c3 89 d1 48 8d 87 88 01 00 00 <48> 89 8f 80 01 00 00 48 39 f0 73 09 48 8d 14 08 48 39 d6 eb 0c 48 [ 7378.425765] syslog-ng[6916]: segfault at 180 ip 7f3c036a7d43 sp 7ffc825fd898 error 6 in libssl.so.3[7f3c0369c000+45000] [ 7378.430827] Code: e8 03 00 ff 15 8e dc 05 00 31 d2 31 c0 be 11 01 00 00 bf 14 00 00 00 ff 15 f2 d8 05 00 31 c0 5a c3 89 d1 48 8d 87 88 01 00 00 <48> 89 8f 80 01 00 00 48 39 f0 73 09 48 8d 14 08 48 39 d6 eb 0c 48 I'm having to switch over to rsyslog until we get this figured out. > On Apr 23, 2023, at 3:56 PM, e9hack wrote: > > Hi, > > in the past, it was possible to build packages, which are using crypto > libraries like openssl, wolfssl or mbedtls, in parallel. One was build for > the image, selected as , the others were build as module selected as . > > This doesn't work any more, if a package is selected for usage of openssl > with and any other crypto library is selected with . > > Compiling is successful, but installation complains about to install a binary > twice from two different packages. > > I'm not sure, since when this does occur, but I assume, it was introduced > with the openssl update to 3.0.x. > > Regards, > Hartmut > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: fix green LED for D-Link DAP-X1860
Reviewed-by: Philip Prindeville
> On Apr 23, 2023, at 7:40 AM, Sebastian Schaper
> wrote:
>
> It was found this device uses a single tri-color power/status LED
> rather than individual red/orange LEDs, which also supports green.
>
> Add GPIO for green color and use with `boot` and `running` aliases.
>
> Signed-off-by: Sebastian Schaper
> ---
> .../linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
> b/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
> index 1aa3f7c91b..818d2d8c41 100644
> --- a/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
> +++ b/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
> @@ -15,9 +15,9 @@
>
> aliases {
> label-mac-device = &gmac0;
> - led-boot = &led_power_orange;
> + led-boot = &led_power_green;
> led-failsafe = &led_power_red;
> - led-running = &led_power_orange;
> + led-running = &led_power_green;
> led-upgrade = &led_power_red;
> };
>
> @@ -40,15 +40,20 @@
> leds {
> compatible = "gpio-leds";
>
> + led_power_green: power_green {
> + label = "green:power";
> + gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
> + default-state = "on";
> + };
> +
> led_power_red: power_red {
> label = "red:power";
> gpios = <&gpio 7 GPIO_ACTIVE_LOW>;
> };
>
> - led_power_orange: power_orange {
> + power_orange {
> label = "orange:power";
> gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
> - default-state = "on";
> };
>
> rssihigh {
> --
> 2.34.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Packaging keep.d/ files and include/package-ipkg.mk
Hi,
This question is for Jo-Philipp or whomever else wants to take a stab at it.
I'm looking at this commit:
https://github.com/openwrt/openwrt/commit/f3a5085903f770bf0b569d3b94ca1cc4d7bab53f#diff-327b383b4b87cd4627eea84a61ada9688b7438baf11536eb74951e4479adb84dR116-R129
And specifically this part:
keepfiles=""; \
for x in $$(KEEP_$(1)); do \
[ -f "$$(IDIR_$(1))/x" ] ||
keepfiles="{keepfiles:+keepfiles }x"; \
done; \
Which seems to me to say "add the lines from KEEP_$(1) only if the line is a
directory or names a non-existent file" (i.e. anything other than an existent
file).
Whereas the comment says:
package-ipkg.mk: build sysupgrade keepfile hints out of conffiles not yet
present in the package. This applies to config directories or files that do not
exist but may be created by the user after package installation.
And I'm wondering... why not just add the lines regardless?
If you look at:
https://github.com/openwrt/openwrt/blob/master/package/base-files/Makefile#L48-L71
And:
https://github.com/openwrt/openwrt/blob/master/package/base-files/files/lib/upgrade/keep.d/base-files-essential
You'll see a fair amount of duplication. But if we just used the contents of
$(Package/base-files/conffiles) as-is, then
package/base-files/files/lib/upgrade/keep.d/base-files-essential could just go
away.
What am I missing here?
Thanks.
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/2] Small improvements to jshn.c and jshn.sh
From: Philip Prindeville Minor improvements in efficiency and portability to libubox's jshn and its wrapper. Philip Prindeville (2): jshn.sh: Add pretty-printing to json_dump blobmsg: Don't do at run-time what can be done at compile-time blobmsg_json.c | 6 +++--- sh/jshn.sh | 12 +++- 2 files changed, 14 insertions(+), 4 deletions(-) -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] jshn.sh: Add pretty-printing to json_dump
From: Philip Prindeville
If a JSON file might be read by a human, say for debugging, it
could be useful to pretty-print it. We do this in places by
calling "json_dump -i" but it shouldn't be necessary to know the
arguments to "jshn" (and indeed, that's not portable if we retool
the underlying implementation). Conversely output that's ephemeral
doesn't need to be pretty (say being piped as input to another
command).
Signed-off-by: Philip Prindeville
---
sh/jshn.sh | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/sh/jshn.sh b/sh/jshn.sh
index
c97369230a93d144fbba06b5a8fa79c9acc41238..1d3055711820e5a21ea59cae49e7bf3f56b626d8
100644
--- a/sh/jshn.sh
+++ b/sh/jshn.sh
@@ -199,6 +199,16 @@ json_add_fields() {
# functions read access to json variables
+json_compact() {
+ JSON_NONEWLINE=1
+ JSON_INDENT=
+}
+
+json_pretty() {
+ JSON_NONEWLINE=
+ JSON_INDENT=1
+}
+
json_load() {
eval "`jshn -r "$1"`"
}
@@ -208,7 +218,7 @@ json_load_file() {
}
json_dump() {
- jshn "$@" ${JSON_PREFIX:+-p "$JSON_PREFIX"} -w
+ jshn "$@" ${JSON_PREFIX:+-p "$JSON_PREFIX"} ${JSON_NONEWLINE:+-n}
${JSON_INDENT:+-i} -w
}
json_get_type() {
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] blobmsg: Don't do at run-time what can be done at compile-time
From: Philip Prindeville
Repeatedly calling a run-time function like strlen() on an
invariant value is inefficient, especially if that value can be
computed once (at initialization) or better yet, computed at
compile-time.
Signed-off-by: Philip Prindeville
---
blobmsg_json.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/blobmsg_json.c b/blobmsg_json.c
index
dce81e991ef7b83ac4906bca6f875369d3057f36..ec8b482c30c96a355aca58651632bc509a16bedf
100644
--- a/blobmsg_json.c
+++ b/blobmsg_json.c
@@ -151,15 +151,15 @@ static bool blobmsg_puts(struct strbuf *s, const char *c,
int len)
static void add_separator(struct strbuf *s)
{
- const char *indent_chars = "\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t";
+ const char indent_chars[] = "\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t";
size_t len;
if (!s->indent)
return;
len = s->indent_level + 1;
- if (len > strlen(indent_chars))
- len = strlen(indent_chars);
+ if (len > sizeof(indent_chars) - 1)
+ len = sizeof(indent_chars) - 1;
blobmsg_puts(s, indent_chars, len);
}
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Best practices for meta packages with variants
Hi, Hoping to get a little guidance from my peers. I'm trying to create a meta-package that can be selected and it will include all of the subordinate/dependent packages, but in this case one of the subordinate packages comes in two variants (IPv4-only or IPv4/v6): https://github.com/openwrt/packages/pull/20731 What's the best way to handle this? Are there any good examples already in the codebase of how to express this? Specifically this part: https://github.com/openwrt/packages/pull/20731/files#diff-00606439ee2b214f1dbac09d66df596b3cc63d3b98e49aab0fa05e0fa127250aR138 Should the meta package also have IPv4/IPv6 variants? That seems clumsy... Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
X86 partition tables
Hi, Couple of questions about partition tables on x86 hardware. Do most x86 machines (an APUv6 w/ Coreboot in my case, and a Qemu/KVM VM with Bochs as well) support GPT in BIOS (CGM or whatever)? And what are the steps on a live system to (1) convert the MBR partition table to MBR, and (2) reinstall grub? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel/x86: fix type
Looks good to me. > On Jan 13, 2023, at 7:30 AM, Florian Eckert wrote: > > Fix typo for KernelPackage w83627hf-wdt. > > Signed-off-by: Florian Eckert > --- > target/linux/x86/modules.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/x86/modules.mk b/target/linux/x86/modules.mk > index 3173cf9e84..e0c3b4174f 100644 > --- a/target/linux/x86/modules.mk > +++ b/target/linux/x86/modules.mk > @@ -184,7 +184,7 @@ define KernelPackage/w83627hf-wdt > DEPENDS:=@TARGET_x86 > KCONFIG:=\ > CONFIG_W83627HF_WDT \ > - ONFIG_WATCHDOG_CORE=y > + CONFIG_WATCHDOG_CORE=y > FILES:=$(LINUX_DIR)/drivers/watchdog/w83627hf_wdt.ko > AUTOLOAD:=$(call AutoLoad,50,w83627hf-wdt,1) > endef > -- > 2.30.2 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: RFC: Add initrd generation to load SSDT tables via ACPI
Hi Florian. What is it you're asking for from me? Does apica-unix need to be bumped? > On Jan 13, 2023, at 5:41 AM, Florian Eckert wrote: > > Hello, > > I have an APU3. This has an I2C bus (SMBUS) to which additional devices can > be connected. On my APU3 board, an IO expander mcp23s08 [1] is connected > there. > This IO expander provides additional GPIOs. This additional GPIOs are > connected to LEDs. The whole thing worked until kernel version 5.4 of > OpenWrt. But after updating to OpenWrt kernel version 5.10 (openwrt-22.03). I > have made the additional LEDs known to the system via a platform driver, > which then integrates these LEDs. The support for reading out the platform > driver data for the driver mcp23s08 has been removed in the kernel with the > commit [2]. I was unable to compile my platform device driver against kernel > 5.10, because of the removed platform data support of the mcp23s08. I > contacted the kernel developer Andy Shevchenko [3] who made this change. His > suggestion was, that the data should be made known to the system via an > additional SSDT table via ACPI [4]. Then everything should work like a system > that supports device-tree. I have now played around with SSDT a bit and > finally managed to get the driver responsible again for this device. I had to > create a new SSDT file and com pile it with a program from the acpica-unix package [5]. The file must be moved into an initrd, so this could be read by the kernel during boot. > > Now to my question: > In order to load this new SSDT file, it must be made available to the kernel > via an initrd. > However, initrd handling is currently not supported by OpenWrt. Manually, it > is no problem for me to load the GRUB initrd. > But I would like to have a solution that is generally valid in OpenWrt during > image generation. I have already prepared a pullrequest for openwrt [6] on my > fork with the changes that are needed. But I am not sure if this is the right > solution. > Additional the acpica-unix package from the package feed [7] must also be > build for the host, to compile the acpi asl source file into acpi aml files. > > > Kind regards > > Florian > > [1] https://github.com/torvalds/linux/blob/master/drivers/pinctrl/Kconfig#L305 > [2] > https://github.com/torvalds/linux/commit/6aba6ed879b3471903c8ada28ba968a268df6143 > [3] https://github.com/andy-shev > [4] https://lore.kernel.org/all/290741faab199d3e43b6255bf2282...@dev.tdt.de/ > [5] https://www.acpica.org/documentation > [6] https://github.com/TDT-AG/openwrt/tree/pr/20230110-config-kernel > [7] https://github.com/openwrt/packages/blob/master/utils/acpica-unix/Makefile ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/1] apu2: add definitions for apu4/6
New versions of the patches have been sent upstream: https://www.spinics.net/lists/platform-driver-x86/msg36198.html https://www.spinics.net/lists/linux-x86_64/msg00629.html And rather than review via email on this list, I've moved the work to a PR: https://github.com/openwrt/openwrt/pull/11651 Please follow-up there with any suggestions. Thanks > On Dec 28, 2022, at 12:45 AM, Philip Prindeville > wrote: > > From: Philip Prindeville > > Signed-off-by: Philip Prindeville > --- > target/linux/x86/base-files/etc/board.d/01_leds| 2 +- > target/linux/x86/base-files/etc/board.d/02_network | 3 +++ > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/target/linux/x86/base-files/etc/board.d/01_leds > b/target/linux/x86/base-files/etc/board.d/01_leds > index > 74ad2d59fe135e57f0c5455e9ab67c62df7e03d9..b42f73f63282d5ebfe5a792347c151882c6fe459 > 100644 > --- a/target/linux/x86/base-files/etc/board.d/01_leds > +++ b/target/linux/x86/base-files/etc/board.d/01_leds > @@ -11,7 +11,7 @@ cisco-mx100-hw) > ucidef_set_led_usbport "usb" "USB" "mx100:green:usb" "1-1-port2" > ucidef_set_led_default "diag" "DIAG" "mx100:green:tricolor" "1" > ;; > -pc-engines-apu1|pc-engines-apu2|pc-engines-apu3) > +pc-engines-apu1|pc-engines-apu2|pc-engines-apu3|pc-engines-apu4|pc-engines-apu6) > ucidef_set_led_netdev "wan" "WAN" "apu:green:3" "eth0" > ucidef_set_led_netdev "lan" "LAN" "apu:green:2" "br-lan" > ucidef_set_led_default "diag" "DIAG" "apu:green:1" "1" > diff --git a/target/linux/x86/base-files/etc/board.d/02_network > b/target/linux/x86/base-files/etc/board.d/02_network > index > 9335e297ba22bba9a86219e1dac6d17c3d9d889d..3b661353e5f36c40ad13fe8fe4ff20b5d6957efb > 100644 > --- a/target/linux/x86/base-files/etc/board.d/02_network > +++ b/target/linux/x86/base-files/etc/board.d/02_network > @@ -26,6 +26,9 @@ cisco-mx100-hw) > pc-engines-apu1|pc-engines-apu2|pc-engines-apu3) > ucidef_set_interfaces_lan_wan "eth1 eth2" "eth0" > ;; > +pc-engines-apu4|pc-engines-apu6) > + ucidef_set_interfaces_lan_wan "eth1 eth2 eth3" "eth0" > + ;; > roqos-roqos-core-rc10) > ucidef_set_interfaces_lan_wan "eth1" "eth0" > ;; > -- > 2.34.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Bind (bind-server) users please upgrade
If you are using Bind9 then you should upgrade to the latest (9.18.10-1) package. No, it's not a CVE. It's a glitch where, if Bind comes up before your WAN port has stabilized, then you'll end up with bogus SOA and NS records for your root server keys because of a problem in how the journaled managed-keys get corrupted. Details are here if you're interested: https://gitlab.isc.org/isc-projects/bind9/-/issues/2895 If you're on an older version, the fix is this: rm -f /tmp/managed-keys.bind.jnl rndc managed-keys refresh rndc managed-keys sync ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Updating env/kernel-config after rebasing/kernel version bump
> On Dec 28, 2022, at 1:14 PM, Robert Marko wrote:
>
> On Wed, 28 Dec 2022 at 01:01, Philip Prindeville
> wrote:
>>
>>
>>
>>> On Dec 27, 2022, at 4:50 PM, Robert Marko wrote:
>>>
>>> On Wed, 28 Dec 2022 at 00:48, Philip Prindeville
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I originally set up my env/kernel-config a long time ago (like 2018) by
>>>> hand, and since then the kernel has gone through several bumps. How do I
>>>> easily refresh it to pick up new stuff from
>>>> target/linux/x86/64/config-${KVER} (where KVER=5.15 currently)? Is there
>>>> a handy script or make target to do this?
>>>
>>> There is make kernel_menuconfig that will essentially give you the
>>> kernel menuconfig and refresh the config after saving.
>>
>>
>> Right, but what does that involve? Will it pick up new symbols from the new
>> kernel target? If there's a new default in 5.15 that wasn't in 5.10, how
>> does it find its way into my config?
>>
>> I tried diffing target/linux/x86/64/config-5.15 and env/kernel-config and
>> there's a whole lot of changes.
>>
>> Or is env/kernel-config the delta from the defaults for any given kernel
>> version in config-${KVER}?
>
> I have to admit that I have not used the env script so far, so I dont
> know how it works.
>
> Regards,
> Robert
I'd like to see something like scripts/diffconfig.sh done for the kernel-config
...
How are the files in target/linux/ combined to generate default state in the
absence of kernel-config, anyway?
Thanks
>>
>>
>>>
>>> Regards,
>>> Robert
>>>>
>>>> Thanks,
>>>>
>>>> -Philip
>>>>
>>>>
>>>> ___
>>>> openwrt-devel mailing list
>>>> openwrt-devel@lists.openwrt.org
>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 1/1] apu2: add definitions for apu4/6
From: Philip Prindeville Signed-off-by: Philip Prindeville --- target/linux/x86/base-files/etc/board.d/01_leds| 2 +- target/linux/x86/base-files/etc/board.d/02_network | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/target/linux/x86/base-files/etc/board.d/01_leds b/target/linux/x86/base-files/etc/board.d/01_leds index 74ad2d59fe135e57f0c5455e9ab67c62df7e03d9..b42f73f63282d5ebfe5a792347c151882c6fe459 100644 --- a/target/linux/x86/base-files/etc/board.d/01_leds +++ b/target/linux/x86/base-files/etc/board.d/01_leds @@ -11,7 +11,7 @@ cisco-mx100-hw) ucidef_set_led_usbport "usb" "USB" "mx100:green:usb" "1-1-port2" ucidef_set_led_default "diag" "DIAG" "mx100:green:tricolor" "1" ;; -pc-engines-apu1|pc-engines-apu2|pc-engines-apu3) +pc-engines-apu1|pc-engines-apu2|pc-engines-apu3|pc-engines-apu4|pc-engines-apu6) ucidef_set_led_netdev "wan" "WAN" "apu:green:3" "eth0" ucidef_set_led_netdev "lan" "LAN" "apu:green:2" "br-lan" ucidef_set_led_default "diag" "DIAG" "apu:green:1" "1" diff --git a/target/linux/x86/base-files/etc/board.d/02_network b/target/linux/x86/base-files/etc/board.d/02_network index 9335e297ba22bba9a86219e1dac6d17c3d9d889d..3b661353e5f36c40ad13fe8fe4ff20b5d6957efb 100644 --- a/target/linux/x86/base-files/etc/board.d/02_network +++ b/target/linux/x86/base-files/etc/board.d/02_network @@ -26,6 +26,9 @@ cisco-mx100-hw) pc-engines-apu1|pc-engines-apu2|pc-engines-apu3) ucidef_set_interfaces_lan_wan "eth1 eth2" "eth0" ;; +pc-engines-apu4|pc-engines-apu6) + ucidef_set_interfaces_lan_wan "eth1 eth2 eth3" "eth0" + ;; roqos-roqos-core-rc10) ucidef_set_interfaces_lan_wan "eth1" "eth0" ;; -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/1] apu2: add definitions for apu4/6
From: Philip Prindeville Signed-off-by: Philip Prindeville --- target/linux/x86/base-files/etc/board.d/02_network | 3 +++ 1 file changed, 3 insertions(+) diff --git a/target/linux/x86/base-files/etc/board.d/02_network b/target/linux/x86/base-files/etc/board.d/02_network index 9335e297ba22bba9a86219e1dac6d17c3d9d889d..3b661353e5f36c40ad13fe8fe4ff20b5d6957efb 100644 --- a/target/linux/x86/base-files/etc/board.d/02_network +++ b/target/linux/x86/base-files/etc/board.d/02_network @@ -26,6 +26,9 @@ cisco-mx100-hw) pc-engines-apu1|pc-engines-apu2|pc-engines-apu3) ucidef_set_interfaces_lan_wan "eth1 eth2" "eth0" ;; +pc-engines-apu4|pc-engines-apu6) + ucidef_set_interfaces_lan_wan "eth1 eth2 eth3" "eth0" + ;; roqos-roqos-core-rc10) ucidef_set_interfaces_lan_wan "eth1" "eth0" ;; -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Updating env/kernel-config after rebasing/kernel version bump
> On Dec 27, 2022, at 4:50 PM, Robert Marko wrote:
>
> On Wed, 28 Dec 2022 at 00:48, Philip Prindeville
> wrote:
>>
>> Hi,
>>
>> I originally set up my env/kernel-config a long time ago (like 2018) by
>> hand, and since then the kernel has gone through several bumps. How do I
>> easily refresh it to pick up new stuff from
>> target/linux/x86/64/config-${KVER} (where KVER=5.15 currently)? Is there a
>> handy script or make target to do this?
>
> There is make kernel_menuconfig that will essentially give you the
> kernel menuconfig and refresh the config after saving.
Right, but what does that involve? Will it pick up new symbols from the new
kernel target? If there's a new default in 5.15 that wasn't in 5.10, how does
it find its way into my config?
I tried diffing target/linux/x86/64/config-5.15 and env/kernel-config and
there's a whole lot of changes.
Or is env/kernel-config the delta from the defaults for any given kernel
version in config-${KVER}?
>
> Regards,
> Robert
>>
>> Thanks,
>>
>> -Philip
>>
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Updating env/kernel-config after rebasing/kernel version bump
Hi,
I originally set up my env/kernel-config a long time ago (like 2018) by hand,
and since then the kernel has gone through several bumps. How do I easily
refresh it to pick up new stuff from target/linux/x86/64/config-${KVER} (where
KVER=5.15 currently)? Is there a handy script or make target to do this?
Thanks,
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Detecting presence (or absence) of IPv6 on WAN interfaces
Hi all, Is there some state available in init.d scripts for detecting if we have IPv6 on the publicly facing Internet? Or do I have to read the network config, look for wan* interfaces, and see if any of them have IPv6 addresses configured, etc? Was hoping that this was already neatly done with a ribbon on it... "Why?" might you ask? Because some services (Bind in particular) generates a slew of logging noise when you try to query an AAA record, but it only has IPv4 connectivity to the internet. It really doesn't like that, so detecting the absence of IPv6 and starting it with "-4" really seems to quiet it down a lot. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Looking for co-contributor on UCI enhancements for various packages
Hi, I'm the maintainer for a few packages, and I could use a little help from someone who has time to do some shell scripting and UCI integration for some of these packages. For instance, I'd like to add remote dynamic DNS updates when using isc-dhcpd on remote sites but having a single internal isc-bind server doing split horizon. I know what needs to be done, I just haven't the time to do it all myself. But if you're looking to collaborate and have cycles to spare, reach out to me. Thanks! -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Firewall questions
Hi, A couple of firewall questions. I'll start with something easy. If I'm ssh'd into my router and I restart the firewall (I'm using firewall3 and iptables), then on one router I get dropped from my shell after a timeout... but on another router, I stay connected. In both cases, I'll be doing this on adjacent hosts (i.e. on the same subnet), and inside the firewall. What would cause the firewall to not persist my connection state when restarting? 2nd question: how do I trace a packet flowing through my firewall? I have two firewalls, in to different locations, connected by an IPsec tunnel. Location A has the public IP address of my site. Location B has a dynamic (but routable) address on a different ISP. Unfortunately, my servers are on a sandbox at Location B and therefore can't egress via this address (the local firewall's WAN address), so I do policy routing over the IPsec tunnel (via xfrm tunnels) to have their traffic egress (and ingress, via redirects) via Location A. Things mostly work: HTTP, HTTPS, SMTP, IMAPS, Submission all work fine. But port forwarding Ssh to my servers doesn't. I've used tcpdump to see the ssh traffic arriving on the xfrm0 tunnel interface, but it then gets silently dropped and never appears on the terminal ethernet interface. No idea why. And no log messages get generated about it being DROPped or REJECTed. So I need to trace it through the rules to see if it's implicitly hitting a chain with a DROP or REJECT policy. I tried something like: iptables -t raw -D PREROUTING -s 72.104.76.181/32 -d 192.168.8.0/24 -p tcp -m tcp --dport 22 -j TRACE And get traces like: Sep 6 22:25:07 OpenWrt3 kernel: [526070.718061] TRACE: raw:PREROUTING:rule:3 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.739550] TRACE: raw:PREROUTING:rule:7 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.761691] TRACE: raw:zone_vpn_helper:rule:12 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.783690] TRACE: raw:PREROUTING:rule:8 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.805671] TRACE: nat:PREROUTING:rule:1 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.827115] TRACE: nat:prerouting_rule:rule:1 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.848978] TRACE: nat:PREROUTING:rule:6 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.870409] TRACE: nat:zone_vpn_prerouting:rule:1 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.892639] TRACE: nat:prerouting_vpn_rule:rule:1 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.915444] TRACE: nat:zone_vpn_prerouting:rule:2 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.937704] TRACE: nat:PREROUTING:rule:7 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) But then nothing more. What am I missing? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/list
Re: Reaching out to Greg KH for 6 year LTS kernel versions
> On Aug 12, 2022, at 11:54 AM, Florian Fainelli wrote: > > One aspect I could see is take for instance a device that is widely popular > amongst our user base as was TI's ar7 for instance a while back, and for > which we might have done a Linux 5.4, or 5.10 version at the time but we do > not wish to continue to maintain. Per my previous email, that seems like something that the SoC manufacturer should be doing... Why is this our burden? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Reaching out to Greg KH for 6 year LTS kernel versions
> On Aug 12, 2022, at 11:53 AM, Florian Fainelli wrote: > > OK, the 3-4 years time frame is not something that we currently have with > Linux kernels, it is either 2 years or 6 years, since 6 > 4, it sounds like > we still have some interest in having 6 LTS kernels, but maybe not have every > single LTS release be 6 years, right? Is this the REAL problem? That we need LTS releases? Or that SoC's like the MT76xx aren't able to keep up with new kernel releases? Would we need to have LTS support if chips like the AR7 and the MT7623 had ongoing kernel support from the manufacturers? Isn't this latter point the true root cause? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Reaching out to Greg KH for 6 year LTS kernel versions
> On Aug 12, 2022, at 2:28 PM, Robert Marko wrote: > > On Fri, 12 Aug 2022 at 21:45, Florian Fainelli wrote: >> >> On 8/12/22 11:09, Robert Marko wrote: >>> On Fri, 12 Aug 2022 at 19:54, Florian Fainelli wrote: >>>> >>>> On 8/10/22 13:32, Robert Marko wrote: >>>>> On Wed, 10 Aug 2022 at 22:30, Philip Prindeville >>>>> wrote: >>>>>> >>>>>> Not to play the devil's advocate but... do we want old kernels hanging >>>>>> out that long? >>>>>> >>>>>> Besides not encouraging people to update to new releases that mitigate >>>>>> discovered CVE's, we'd also not pick up David Taht's excellent >>>>>> improvements in Buffer Bloat. >>>>> >>>>> I have to agree with this. >>>>> What would be the benefit for OpenWrt with having LTS kernels >>>>> supported for 6 years? >>>> >>>> One aspect I could see is take for instance a device that is widely >>>> popular amongst our user base as was TI's ar7 for instance a while back, >>>> and for which we might have done a Linux 5.4, or 5.10 version at the >>>> time but we do not wish to continue to maintain. >>> >>> I dont see how this is related to LTS kernel support. >> >> OK maybe I need to spell out my example more clearly. Let us say that we >> have a release in 2019 of OpenWrt that supported TI AR7 based upon the >> Linux 5.4 kernel. >> >> Fast forward to 2022, we decide to abandon TI AR7 in master and we stop >> supporting it entirely for future releases. A very bad Linux security >> problem show up, and because we care about our users, we keep updating >> the LTS kernel that was used in the 2019.x release up until, say the >> said kernel stops being supported. If that support time frame was 6 >> years, then we would really be helping our users. >> >> Maybe the wider discussion to be had, is: >> >> - when and how do we decide to deprecate a given Linux port, I assume it >> is when no more users show up or maybe more realistically when OpenWrt >> developers just cannot keep up with updating those devices because they >> no longer use those themselves >> >> - how long do we want to keep supporting past OpenWrt releases with >> kernel updates, 2 years, 3/4 years, 6 years to match the kernel >> lifecycle they are based upon? > > As an idea, I understand this, it would basically be an "LTS" OpenWrt > release that > would receive security-only updates. > > However, we had a long discussion on the IRC today and the resources are > spread > rather thin even currently with 2 or 3 releases being supported. > > If its gonna be a volunteer kind of no guarantees release, then maybe > but I dont see > how we can manage that as well. Chiming in as a software security developer... I think we're approaching this problem wrong. We need to make regular software updates easier, which we've not focused on in the past. Periodically "sysupgrade" gets damaged, and manages to brick devices. This should never happen. Ideally we should be moving towards unattended updates. Would this [kernel support] be as much of a burden if we worked harder at getting our patches upstreamed? And a 800lb gorilla is that companies like Netgear and D-Link don't arm-twist Mediatek to keep their SoC-specific patches upstreamed and their SoC's running more recent kernels. How much of this problem would go away if MediaTek supported 5.10 or 5.15 on all of their current SoC's and SoC's released in the last 5-7 years? >>>> >>>> Being able to continue to deliver stable kernel updates in a stable >>>> OpenWrt branch could be a good way for users to pick up their next xDSL >>>> router since there are not so many out there that can actually run >>>> OpenWrt compared to pure Wired/Wi-Fi for instance. >>> >>> I can agree with this. >>> >>>> >>>>> Backporting stuff is already hard with only 2 LTS versions supported in >>>>> OpenWrt. >>>> >>>> That argument I am sympathetic with, and the sheer amount of out of tree >>>> patches we have in OpenWrt is not helping, in fact it definitively makes >>>> it harder to regularly test, but still somehow we managed to do it. >>>> >>>> Since we will merge stable updates eventually, the point would be that >>>> instead of testing those that are already
Re: Best VSDL modem-router to target?
> On Aug 10, 2022, at 5:46 PM, Mathew McBride wrote: > > (resend as plain text) > > Hi Philip, > > On Sat, Jul 30, 2022, at 5:24 AM, Philip Prindeville wrote: >> [snip] >> >> What was the conclusion about VDSL2 PCIe cards? I'm looking for a VDSL/2 >> card that does bonding/vectoring for use with CenturyLink DSLAM's... > > Unfortunately our (Traverse) card is "on ice" at the moment. We need a big > enough order to be able to build the PCIe version. I can't say with certainty > if/when that would happen though there is more than enough ADSL/VDSL2 still > out there to make it a possibility. > > Due to the component shortages it would likely need a design revision as well > to replace some hard to get parts. > >> Looking for something to work with regular size PCIe, not mini-PCIe. > I'm told the Draytek one (132) is now EOL, at least that is what I've heard > from someone who has a few of them and tried to get more. >> Thanks, >> >> -Philip >> > Cheers, > Matt > (Been on vacation so sorry for the late reply) Understood. Thanks for the update. Hope it was a good vacay. What about Traverse doing a DOCSIS 3.1 card? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Reaching out to Greg KH for 6 year LTS kernel versions
Not to play the devil's advocate but... do we want old kernels hanging out that long? Besides not encouraging people to update to new releases that mitigate discovered CVE's, we'd also not pick up David Taht's excellent improvements in Buffer Bloat. > On Aug 8, 2022, at 5:15 PM, Florian Fainelli wrote: > > Hi, > > Greg KH has communicated a few times before on his blog [1] that he is > seeking the help of individuals and company to help him maintain the LTS > kernels and allow them to be made 6 years instead of just the usual 2 years. > > 5.10 is a 6 year LTS, but 5.15 is not listed as such, although it certainly > would make sense for it to be since we use 5.15 in OpenWrt. > > It would be good for the project to have a designated contact who can > communicate the kernel version plan ahead of time, or once a LTS is picked > up, we could sign up people to do regular testing of the stable release > candidates? > > Thoughts? > > [1]: > http://kroah.com/log/blog/2021/02/03/helping-out-with-lts-kernel-releases/ > -- > Florian > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Persistent /var
Hi all (and Daniel and Stijn especially), How do I build a system (or an image to install on a system) that's x86_64 and has an SSD, which I want to have a squashfs image and a 2nd partition with an ext4 filesystem for /var. I'd like the first boot to resize the 2nd partition to use all available remaining space on the disk after that partition. How do I do this? I'd also like to preconfigure /etc/config/fstab to mount the partition, of course. Am I forgetting any steps? How to go about this? Is there a FAQ to follow? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Draytek VDSL2 card
Anyone have any luck getting one of these running with OpenWRT? https://www.draytek.co.uk/download/VigorNIC132_Datasheet.pdf I emailed them but haven't heard back... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Best VSDL modem-router to target?
> On Jan 9, 2022, at 5:46 PM, David Woodhouse wrote: > > On Mon, 2022-01-10 at 10:41 +1100, Mathew McBride wrote: >> On Mon, Jan 10, 2022, at 10:14 AM, David Woodhouse wrote: >>> On Wed, 2022-01-05 at 18:05 -0700, Philip Prindeville wrote: >>>> Have you looked at the Traverse Geos2? >>> >>> That's kind of dated now (ADSL2+ only) but Traverse seem to >>> have a >>> new toy now: >>> >>> https://traverse.com.au/products/ten64-networking-platform/ >>> And it has an external VDSL board: >>> https://traverse.com.au/hardware-4.html >>> >>> Looks like the VDSL is a standalone device much like the Solos card >>> which they integrated into the Geos. >> >> Indeed, the Geos has been out of production for several years now. >> >> We don't have a dual DSL product anymore as most of the use cases for >> dual-DSL have shifted to DSL+5G or even dual-5G instead. >> >> Our VDSL card is just a Lantiq/MaxLinear GRX gateway with an Ethernet >> uplink to host. > > Is that a GRX300, with VRX318? > > Wonder what it would take to get OpenWrt running directly on it :) > >> It's not possible to construct a something that functions like the >> Solos/Geos with modern DSL chipsets. > > Is it not possible to have a VRX518 transceiver alone on a PCIe card? > Is it that you can't *get* them as discrete PCIe devices, or that they > wouldn't work like that? > >> (Except maybe if you can get the VRX PCIe phys working on plain >> OpenWrt. I believe others have tried and not succeeded yet) > > We do have native VRX200 support, and there's progress on VRX518 too, > which looks like it's working for many users although it isn't merged > yet. > > While we dream about that, though, having the VDSL bridged to Ethernet > by an internal "black box" PCIe device instead of having to use an > external modem is still a big win. > > Are your VDSL cards available for purchase? I'm tempted to go buy a > Ten64 right now and see if I can help with upstreaming the OpenWrt > support, if I can get a VDSL card too. What was the conclusion about VDSL2 PCIe cards? I'm looking for a VDSL/2 card that does bonding/vectoring for use with CenturyLink DSLAM's... Looking for something to work with regular size PCIe, not mini-PCIe. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Upstream PR's to build Asterisk w/o Openssl deprecated API
Hi all, I've got a series of reviews upstream in Asterisk to build against Openssl 1.1.x and 3.x without OPENSSL_SUPPRESS_DEPRECATED being required, if anyone is curious or wants to track that: https://gerrit.asterisk.org/c/asterisk/+/18533 https://gerrit.asterisk.org/c/asterisk/+/18525 https://gerrit.asterisk.org/c/asterisk/+/18526 https://gerrit.asterisk.org/c/asterisk/+/18532 https://gerrit.asterisk.org/c/asterisk/+/18534 The review process for non-core developers of Asterisk is a bit slow, so I can't say when they'll get around to merging this... and since it's slated for "master", it will likely only appear in 19.x. A backport to 18.x and 16.x seems unlikely. I did need to add test infrastructure to it to allow running external commands to generate reference test vectors to validate the changes I was making, since certain functionality like OAEP padding in RSA is non-deterministic (there's a random portion of the padding to make asymmetric key encryption be more resistant to pre-imaging attacks), which means that every time you encrypt text, the cipher text will be different (hopefully), and therefore you can't do a bitwise compare against canned strings. This was necessary to ensure that the rewrite from the 1.0.x API (i.e. using SHA1(), RSA_encrypt(), AES_encrypt(), etc.) to instead using the EVP_PKEY and EVP_MD API didn't introduce any regressions. As a result, if we generate RSA encrypted text internally, we validate it by calling "openssl pkeyutl -d ..." to decrypt it, etc. The entire cryptographic suite of Asterisk is a train wreck, from a Best Practices point of view... The use 128-bit AES keys, and ECB, both of which are deprecated... The RSA keys are fixed at 1024 bit, which is also deprecated... and they use RSA for bulk-data encryption, which is never supposed to happen (it's meant for signing or key-exchange, not stream ciphers). I have a proposal for deprecating the current res_crypto resource and replacing it with a redux: https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=49153311 I welcome any comments. Highlights of the proposal are: * supporting stronger AES and RSA key sizes; * deprecating weak block ciphers (like ECB, CBC, etc.) in favor of GCM; * deprecating stream operations with RSA; * adding EC support with NIST curves; * more explicit API's with better sanity checking (e.g. passing input and output buffer lengths); * provider support for keystores like TPM and HSM's; * more test coverage; No idea when I'll get around to doing it... I don't want to sink a lot of time into the effort for naught, if the above relatively simply PR's are going to languish, since this will be a much larger effort and likely more work to get it across the finish line. External enthusiasm for getting this in might speed things along... maybe. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Drop CONFIG_IPV6 ?
Er, *haven't started* > On Mar 13, 2022, at 9:54 PM, Philip Prindeville > wrote: > > Yeah, I disable CONFIG_IPV6, since most American ISP's have started rolling > out residential IPv6. My local pop & pop ILEC hasn't deployed it. There's > not even an announced date for it on their roadmap. > > I suspect that if everyone had an IPv6 address, which would be both routable > and non-dynamic, then people could more easily run servers on their > networks... which might be anethema to the ISP's. > > > >> On Mar 13, 2022, at 5:31 PM, Etienne Champetier >> wrote: >> >> Hi All, >> >> We currently have some circular dependencies caused by the usage of >> PROVIDES and @IPV6 >> https://github.com/openwrt/openwrt/issues/9407 >> >> One radical way to fix, suggested by Jow, is to completely remove >> CONFIG_IPV6 from OpenWrt. >> This would also allow to simplify packaging of some core components. >> >> Is anyone disabling CONFIG_IPV6 ? >> Do people agree we can drop CONFIG_IPV6 ? >> Should we do this before we branch 22.x ? >> >> Best >> Etienne > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Drop CONFIG_IPV6 ?
Yeah, I disable CONFIG_IPV6, since most American ISP's have started rolling out residential IPv6. My local pop & pop ILEC hasn't deployed it. There's not even an announced date for it on their roadmap. I suspect that if everyone had an IPv6 address, which would be both routable and non-dynamic, then people could more easily run servers on their networks... which might be anethema to the ISP's. > On Mar 13, 2022, at 5:31 PM, Etienne Champetier > wrote: > > Hi All, > > We currently have some circular dependencies caused by the usage of > PROVIDES and @IPV6 > https://github.com/openwrt/openwrt/issues/9407 > > One radical way to fix, suggested by Jow, is to completely remove > CONFIG_IPV6 from OpenWrt. > This would also allow to simplify packaging of some core components. > > Is anyone disabling CONFIG_IPV6 ? > Do people agree we can drop CONFIG_IPV6 ? > Should we do this before we branch 22.x ? > > Best > Etienne ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
WiFi-6 certified location services
Hi, Anyone have an idea what's involved in adding support for WiFi-6 certified location services to OpenWRT? And where would it fit in? In the radio driver, or in hostapd? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Status of source-only targets
> On Jan 12, 2022, at 10:53 AM, Daniel Golle wrote: > > On Wed, Jan 12, 2022 at 10:50:41AM -0700, Philip Prindeville wrote: >> >> >>> On Jan 11, 2022, at 11:56 AM, Daniel Golle wrote: >>> >>> Sadly the falcon didn't really make it to fly with OpenWrt (yet). >>> It's used in a couple of GPON SFP modules, so would sure be an >>> interesting target... >> >> >> G.PON SFP modules? Tell me about those!!! > > See for example these threads in the forum: > > https://forum.openwrt.org/t/support-zisa-op151s-gpon-onu-lantiq-sfp-module/24102/7 > https://forum.openwrt.org/t/will-gpon-nokia-g-010s-a-change-sn/69602/2 Thanks. How portable are G.PON sticks to different OLT's? Or are ONT's married to a particular OLT of the same vendor? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
