Re: [PATCH v2 01/19] tools: Add gendwarfksyms

2024-09-10 Thread Masahiro Yamada
On Fri, Sep 6, 2024 at 5:53 AM Sami Tolvanen wrote: > > Hi, > > On Thu, Sep 5, 2024 at 2:30 AM Masahiro Yamada wrote: > > > > On Fri, Aug 16, 2024 at 2:39 AM Sami Tolvanen > > wrote: > > > > > > +++ b/scripts/gendwarfksyms/gendwarfksyms

Re: [PATCH 04/15] kbuild: add generic support for built-in boot DTBs

2024-09-10 Thread Masahiro Yamada
On Thu, Sep 5, 2024 at 11:17 PM Rob Herring wrote: > > On Thu, Sep 05, 2024 at 08:47:40AM +0900, Masahiro Yamada wrote: > > Some architectures embed boot DTBs in vmlinux. A potential issue for > > these architectures is a race condition during parallel builds because > > K

Re: [PATCH 04/15] kbuild: add generic support for built-in boot DTBs

2024-09-05 Thread Masahiro Yamada
On Thu, Sep 5, 2024 at 11:17 PM Rob Herring wrote: > > On Thu, Sep 05, 2024 at 08:47:40AM +0900, Masahiro Yamada wrote: > > Some architectures embed boot DTBs in vmlinux. A potential issue for > > these architectures is a race condition during parallel builds because > > K

Re: [PATCH 14/15] kbuild: rename CONFIG_GENERIC_BUILTIN_DTB to CONFIG_BUILTIN_DTB

2024-09-05 Thread Masahiro Yamada
On Thu, Sep 5, 2024 at 11:38 PM Rob Herring wrote: > > On Thu, Sep 05, 2024 at 08:47:50AM +0900, Masahiro Yamada wrote: > > Now that all architectures have migrated to the generic built-in > > DTB support, the GENERIC_ prefix is no longer necessary. > > > >

Re: [PATCH v2 01/19] tools: Add gendwarfksyms

2024-09-04 Thread Masahiro Yamada
+ if (dwfl_getmodules(dwfl, &process_modules, NULL, 0)) { > + error("dwfl_getmodules failed for '%s'", > + object_files[n]); > + return -1; > + } > + > + dwfl_end(dwfl); > + close(fd); > + } > + > + return 0; > +} > diff --git a/scripts/gendwarfksyms/gendwarfksyms.h > b/scripts/gendwarfksyms/gendwarfksyms.h > new file mode 100644 > index ..5ab7ce7d4efb > --- /dev/null > +++ b/scripts/gendwarfksyms/gendwarfksyms.h > @@ -0,0 +1,78 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > +/* > + * Copyright (C) 2024 Google LLC > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include Could you include external headers first, then in-tree headers? (and one blank line in-between). Also, please consider using scripts/include/hashtable.h How about this? #include #include #include #include #include #include #include If necessary, you can use this patch too: https://lore.kernel.org/linux-kbuild/20240904235500.700432-1-masahi...@kernel.org/T/#u -- Best Regards Masahiro Yamada

[PATCH 15/15] kbuild: use .init.rodata section unconditionally for cmd_wrap_S_dtb

2024-09-04 Thread Masahiro Yamada
Boot DTBs are now wrapped and compiled in scripts/Makefile.vmlinux. The cmd_wrap_S_dtb rule in scripts/Makefile.dtbs is now only used for generic purposes, so the .init.rodata section should be used unconditionally. Signed-off-by: Masahiro Yamada --- scripts/Makefile.dtbs | 4 +--- 1 file

[PATCH 14/15] kbuild: rename CONFIG_GENERIC_BUILTIN_DTB to CONFIG_BUILTIN_DTB

2024-09-04 Thread Masahiro Yamada
Now that all architectures have migrated to the generic built-in DTB support, the GENERIC_ prefix is no longer necessary. Signed-off-by: Masahiro Yamada --- Makefile | 2 +- arch/arc/Kconfig | 2 +- arch/loongarch/Kconfig | 1

[PATCH 13/15] microblaze: migrate to the generic rule for built-in DTB

2024-09-04 Thread Masahiro Yamada
by include/asm-generic/vmlinux.lds.h. For safety, arch/microblaze/boot/dts/system.dtb is still placed in the __fdt_blob section, but removing the MicroBlaze-specific section should be considered. Signed-off-by: Masahiro Yamada --- arch/microblaze/Kbuild| 1 - arch/microblaze

[PATCH 12/15] sh: migrate to the generic rule for built-in DTB

2024-09-04 Thread Masahiro Yamada
Select GENERIC_BUILTIN_DTB when built-in DTB support is enabled. To keep consistency across architectures, this commit also renames CONFIG_USE_BUILTIN_DTB to CONFIG_BUILTIN_DTB, and CONFIG_BUILTIN_DTB_SOURCE to CONFIG_BUILTIN_DTB_NAME. Signed-off-by: Masahiro Yamada --- arch/sh/Kbuild

[PATCH 11/15] nios2: migrate to the generic rule for built-in DTB

2024-09-04 Thread Masahiro Yamada
Select GENERIC_BUILTIN_DTB when built-in DTB support is enabled. To keep consistency across architectures, this commit also renames CONFIG_NIOS2_DTB_SOURCE_BOOL to CONFIG_BUILTIN_DTB, and CONFIG_NIOS2_DTB_SOURCE to CONFIG_BUILTIN_DTB_NAME. Signed-off-by: Masahiro Yamada --- arch/nios2/Kbuild

[PATCH 10/15] xtensa: migrate to the generic rule for built-in DTB

2024-09-04 Thread Masahiro Yamada
Select GENERIC_BUILTIN_DTB to use the generic rule to support built-in DTB. To keep consistency across architectures, this commit also renames CONFIG_BUILTIN_DTB_SOURCE to CONFIG_BUILTIN_DTB_NAME. Signed-off-by: Masahiro Yamada --- arch/xtensa/Kbuild | 2 +- arch

[PATCH 09/15] openrisc: migrate to the generic rule for built-in DTB

2024-09-04 Thread Masahiro Yamada
Select GENERIC_BUILTIN_DTB to use the generic rule to support built-in DTB. To keep consistency across architectures, this commit also renames CONFIG_OPENRISC_BUILTIN_DTB_NAME to CONFIG_BUILTIN_DTB_NAME. Signed-off-by: Masahiro Yamada --- arch/openrisc/Kbuild | 1 - arch

[PATCH 08/15] ARC: migrate to the generic rule for built-in DTB

2024-09-04 Thread Masahiro Yamada
Select GENERIC_BUILTIN_DTB to use the generic rule to support built-in DTB. To keep consistency across architectures, this commit also renames CONFIG_ARC_BUILTIN_DTB_NAME to CONFIG_BUILTIN_DTB_NAME. Signed-off-by: Masahiro Yamada --- arch/arc/Kconfig | 7

[PATCH 07/15] LoongArch: migrate to the generic rule for built-in DTB

2024-09-04 Thread Masahiro Yamada
Select GENERIC_BUILTIN_DTB when built-in DTB support is enabled. Signed-off-by: Masahiro Yamada --- arch/loongarch/Kbuild| 1 - arch/loongarch/Kconfig | 1 + arch/loongarch/boot/dts/Makefile | 2 -- 3 files changed, 1 insertion(+), 3 deletions(-) diff --git a/arch

[PATCH 06/15] riscv: migrate to the generic rule for built-in DTB

2024-09-04 Thread Masahiro Yamada
Select GENERIC_BUILTIN_DTB when built-in DTB support is enabled. To keep consistency across architectures, this commit also renames CONFIG_BUILTIN_DTB_SOURCE to CONFIG_BUILTIN_DTB_NAME. Signed-off-by: Masahiro Yamada --- arch/riscv/Kbuild | 1 - arch/riscv/Kconfig

[PATCH 05/15] MIPS: migrate to generic rule for built-in DTBs

2024-09-04 Thread Masahiro Yamada
Select GENERIC_BUILTIN_DTB and BUILTIN_DTB_ALL when built-in DTB support is enabled. DTBs compiled under arch/mips/boot/dts/ will be wrapped and compiled in scripts/Makefile.vmlinux. Signed-off-by: Masahiro Yamada --- arch/mips/Kconfig | 2 ++ arch/mips/Makefile

[PATCH 04/15] kbuild: add generic support for built-in boot DTBs

2024-09-04 Thread Masahiro Yamada
e to arch/*/boot/dts/) - CONFIG_BUILTIN_DTB_ALL If this is enabled, all DTB files compiled under arch/*/boot/dts/ are embedded into vmlinux. Only used by MIPS. Signed-off-by: Masahiro Yamada --- Makefile | 7 ++- drivers/of/Kconfig | 6 ++ scripts/M

[PATCH 03/15] kbuild: move non-boot builtin DTBs to .init.rodata section

2024-09-04 Thread Masahiro Yamada
odata under the arch/ directory, and .init.rodata section otherwise. This will be refactored later. Signed-off-by: Masahiro Yamada --- drivers/of/unittest.c | 2 +- scripts/Makefile.dtbs | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/of/unittest.c b/drivers

[PATCH 02/15] kbuild: split device tree build rules into scripts/Makefile.dtbs

2024-09-04 Thread Masahiro Yamada
scripts/Makefile.lib is included not only from scripts/Makefile.build but also from scripts/Makefile.{modfinal,package,vmlinux,vmlinux_o}, where DT build rules are not required. Split the DT build rules out to scripts/Makefile.dtbs, and include it only when necessary. Signed-off-by: Masahiro

[PATCH 01/15] kbuild: add intermediate targets for Flex/Bison in scripts/Makefile.host

2024-09-04 Thread Masahiro Yamada
Flex and Bison are used only for host programs. Move their intermediate target processing from scripts/Makefile.build to scripts/Makefile.host. Signed-off-by: Masahiro Yamada --- scripts/Makefile.build | 35 --- scripts/Makefile.host | 5 + 2 files changed

[PATCH 00/15] kbuild: refactor DTB build rules, introduce a generic built-in boot DTB support

2024-09-04 Thread Masahiro Yamada
01 and 02 are kbuild cleanups. 03 and 04 parepare to wrap boot DTBs in scripts/Makefile.vmlinux. My plan is to 05-13 to each arch ML in the next cycle, but they are included in this patch set so that reviewers can understand what will happen in the future. Masahiro Yamada (15): kbuild: add

Re: [PATCH v2] modpost: compile constant module information only once

2024-09-03 Thread Masahiro Yamada
.c > new file mode 100644 > index ..12fbc6d3aae8 > --- /dev/null > +++ b/scripts/module-common.c > @@ -0,0 +1,25 @@ > +// SPDX-License-Identifier: GPL-2.0 > + > +#include > +/* > + * Include build-salt.h after module.h in order to > + * inherit the definitions. > + */ > +#define INCLUDE_VERMAGIC > +#include > +#include > +#include > + > +#ifdef CONFIG_UNWINDER_ORC > +#include > +ORC_HEADER; > +#endif > + > +BUILD_SALT; > +BUILD_LTO_INFO; > + > +MODULE_INFO(vermagic, VERMAGIC_STRING); > + > +#ifdef CONFIG_MITIGATION_RETPOLINE > +MODULE_INFO(retpoline, "Y"); > +#endif > > --- > base-commit: 9f18baf3dd656e7ca166038d51e0b54a892d87db > change-id: 20240824-modinfo-const-6f0d67e2b301 > > Best regards, > -- > Thomas Weißschuh > -- Best Regards Masahiro Yamada

Re: [PATCH v2 03/19] gendwarfksyms: Add address matching

2024-09-01 Thread Masahiro Yamada
n == SHN_UNDEF) { > + sym->addr.section = addr->section; > + sym->addr.address = addr->address; These two lines can be replaced with sym->addr = *addr; -- Best Regards Masahiro Yamada

Re: [PATCH v2 02/19] gendwarfksyms: Add symbol list handling

2024-09-01 Thread Masahiro Yamada
think you can squash 02/19 into 01/19 because this tool does not do anything useful at this point. -- Best Regards Masahiro Yamada

Re: [PATCH v2 18/19] x86/asm-prototypes: Include

2024-09-01 Thread Masahiro Yamada
gt; index 25466c4d2134..c82e68c8b7c2 100644 > --- a/arch/x86/include/asm/asm-prototypes.h > +++ b/arch/x86/include/asm/asm-prototypes.h > @@ -1,4 +1,5 @@ > /* SPDX-License-Identifier: GPL-2.0 */ > +#include > #include > #include > #include > -- > 2.46.0.184.g6999bdac58-goog > -- Best Regards Masahiro Yamada

Re: [PATCH v2 03/19] gendwarfksyms: Add address matching

2024-08-28 Thread Masahiro Yamada
ar *name, symbol_callback_t > func, void *data) > > static bool is_exported(const char *name) > { > - return checkp(for_each(name, NULL, NULL)) > 0; > + return checkp(for_each(name, true, NULL, NULL)) > 0; > } > > int symbol_read_exports(FILE *file) > @@ -57,13 +93,14 @@ int symbol_read_exports(FILE *file) > if (is_exported(name)) > continue; /* Ignore duplicates */ > > - sym = malloc(sizeof(struct symbol)); > + sym = calloc(1, sizeof(struct symbol)); I am tired of noise changes when reviewing this patch set. 2/19 added malloc(), which is immediately replaced with calloc() by 3/19. -- Best Regards Masahiro Yamada

Re: [PATCH v2 02/19] gendwarfksyms: Add symbol list handling

2024-08-28 Thread Masahiro Yamada
+ > + if (is_exported(name)) > + continue; /* Ignore duplicates */ > + > + sym = malloc(sizeof(struct symbol)); > + if (!sym) { > + error("malloc failed"); > + return -1; > + } > + > + sym->name = name; > + name = NULL; Is this necessary? > + > + hash_add(symbol_names, &sym->name_hash, name_hash(sym->name)); > + ++nsym; > + > + debug("%s", sym->name); > + } > + > + if (line) > + free(line); > + > + debug("%d exported symbols", nsym); > + return 0; > +} > + > +static int get_symbol(struct symbol *sym, void *arg) > +{ > + struct symbol **res = arg; > + > + *res = sym; > + return 0; > +} > + > +struct symbol *symbol_get(const char *name) > +{ > + struct symbol *sym = NULL; > + > + for_each(name, get_symbol, &sym); > + return sym; > +} > -- > 2.46.0.184.g6999bdac58-goog > -- Best Regards Masahiro Yamada

Re: [PATCH v2 06/19] gendwarfksyms: Add a cache for processed DIEs

2024-08-28 Thread Masahiro Yamada
truct die *cd, struct die_fragment **res) > +{ > + struct die_fragment *prev; > + struct die_fragment *df; > + > + df = malloc(sizeof(struct die_fragment)); > + if (!df) { > + error("malloc failed"); > + return -1; > + } > + > + df->type = EMPTY; > + df->next = NULL; > + > + prev = cd->list; > + while (prev && prev->next) > + prev = prev->next; So, this entirely traverses the singly-linked list every time a new item is appended to the tail. In my analysis, this while loop iterates for thousands of times in total for emitting each export symbol. Why isn't this list_add_tail()? -- Best Regards Masahiro Yamada

Re: [PATCH v2 01/19] tools: Add gendwarfksyms

2024-08-28 Thread Masahiro Yamada
gt; + > +#define warn(format, ...) __println("warning: ", format, ##__VA_ARGS__) > +#define error(format, ...) __println("error: ", format, ##__VA_ARGS__) > + > +/* > + * Error handling helpers > + */ > +#define __check(expr, test, rv) \ > + ({ \ > + int __res = expr; \ > + if (test) { \ > + error("`%s` failed: %d", #expr, __res); \ > + return rv; \ > + } \ > + __res; \ > + }) > + > +/* Error == non-zero values */ > +#define check(expr) __check(expr, __res, -1) > +/* Error == negative values */ > +#define checkp(expr) __check(expr, __res < 0, __res) > + > +/* > + * dwarf.c > + */ > + > +struct state { > + Dwfl_Module *mod; > + Dwarf *dbg; > +}; > + > +typedef int (*die_callback_t)(struct state *state, Dwarf_Die *die); > +typedef bool (*die_match_callback_t)(Dwarf_Die *die); > +extern bool match_all(Dwarf_Die *die); > + > +extern int process_die_container(struct state *state, Dwarf_Die *die, > +die_callback_t func, > +die_match_callback_t match); > + > +extern int process_module(Dwfl_Module *mod, Dwarf *dbg, Dwarf_Die *cudie); No 'extern' for function declarations. > + > +#endif /* __GENDWARFKSYMS_H */ > -- > 2.46.0.184.g6999bdac58-goog > -- Best Regards Masahiro Yamada

Re: [PATCH v2 04/19] gendwarfksyms: Add support for type pointers

2024-08-28 Thread Masahiro Yamada
On Wed, Aug 28, 2024 at 3:50 PM Masahiro Yamada wrote: > > On Fri, Aug 16, 2024 at 2:39 AM Sami Tolvanen wrote: > > > > The compiler may choose not to emit type information in DWARF for > > external symbols. Clang, for example, does this for symbols not > > defined

Re: [PATCH v2 00/19] Implement DWARF modversions

2024-08-28 Thread Masahiro Yamada
Expand type modifiers and typedefs > gendwarfksyms: Expand subroutine_type > gendwarfksyms: Expand array_type > gendwarfksyms: Expand structure types > gendwarfksyms: Limit structure expansion > gendwarfksyms: Add die_map debugging > gendwarfksyms: Add symtypes output > gendwarfksyms: Add symbol versioning > gendwarfksyms: Add support for declaration-only data structures > gendwarfksyms: Add support for reserved structure fields > export: Add __gendwarfksyms_ptr_ references to exported symbols > x86/asm-prototypes: Include > kbuild: Add gendwarfksyms as an alternative to genksyms > -- Best Regards Masahiro Yamada

Re: [PATCH v2 04/19] gendwarfksyms: Add support for type pointers

2024-08-27 Thread Masahiro Yamada
strncmp(name, SYMBOL_PTR_PREFIX, > SYMBOL_PTR_PREFIX_LEN); > +} > + > static int for_each(const char *name, bool name_only, symbol_callback_t func, > void *data) > { > @@ -49,6 +63,8 @@ static int for_each(const char *name, bool name_only, > symbol_callback_t func, > > if (!name || !*name) > return 0; > + if (is_symbol_ptr(name)) > + name += SYMBOL_PTR_PREFIX_LEN; > > hash_for_each_possible_safe(symbol_names, match, tmp, name_hash, > name_hash(name)) { > -- > 2.46.0.184.g6999bdac58-goog > -- Best Regards Masahiro Yamada

Re: [RFC PATCH v4 12/17] powerpc64/ftrace: Move ftrace sequence out of line

2024-08-27 Thread Masahiro Yamada
e.init,"aw" > +SYM_DATA(ftrace_ool_stub_inittext_count, .long ${num_ool_stubs_inittext}) > + > +SYM_CODE_START(ftrace_ool_stub_inittext) > + .space ${num_ool_stubs_inittext} * FTRACE_OOL_STUB_SIZE > +SYM_CODE_END(ftrace_ool_stub_inittext) > +.popsection > +EOF > + > +${CC} ${NOSTDINC_FLAGS} ${LINUXINCLUDE} ${KBUILD_CPPFLAGS} \ > + ${KBUILD_AFLAGS} ${KBUILD_AFLAGS_KERNEL} \ > + -c -o ${arch_vmlinux_o} ${arch_vmlinux_S} Please do not compile this within a shell script. scripts/Makefile.build provides rule_as_o_S to do this. [1] vmlinux.o --> arch/powerpc/tools/vmlinux.S [2] arch/powerpc/tools/vmlinux.S --> arch/powerpc/tools/vmlinux.o Please split these in separate build rules. > -- > 2.45.2 > -- Best Regards Masahiro Yamada

Re: [PATCH v8 1/4] kbuild: add mod(name,file)_flags to assembler flags for module objects

2024-08-23 Thread Masahiro Yamada
ust_flags = $(_rust_flags) $(modkern_rustflags) > @$(objtree)/include/generated/rustc_cfg > > a_flags= -Wp,-MMD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \ > -$(_a_flags) $(modkern_aflags) > +$(_a_flags) $(modkern_aflags) $(modname_flags) > >

Re: [PATCH 0/2] kmod /usr support

2024-08-23 Thread Masahiro Yamada
On Thu, Aug 22, 2024 at 5:36 PM Michal Suchánek wrote: > > Hello, > > On Thu, Aug 22, 2024 at 01:05:11AM -0500, Lucas De Marchi wrote: > > On Tue, Dec 19, 2023 at 05:37:31PM GMT, Masahiro Yamada wrote: > > > On Thu, Dec 7, 2023 at 3:37 AM Lucas De Marchi > > >

Re: [PATCH v7 3/4] scripts: add verifier script for builtin module range data

2024-08-22 Thread Masahiro Yamada
ore). We check the associated module file name, and if > + # they do not match, the object is not part of a module. > + if (mod !~ / /) { > + if (!(mod in mods)) > + mod = ""; > + } > + > + gsub(/([^/ ]*\/)+/, "", mod); > + gsub(/-/, "_", mod); > + > + # At this point, mod is a single (valid) module name, or a list of > + # module names (that do not need validation). > + omod[obj] = mod; > + close(fn); Same as 2/4. -- Best Regards Masahiro Yamada

Re: [PATCH v7 2/4] kbuild: generate offset range data for builtin modules

2024-08-22 Thread Masahiro Yamada
'"]+[^'"]+/) > 0) { > + mod = substr(s, RSTART + 16, RLENGTH - 16); > + gsub(/['"]/, "", mod); > + } > + } > + close(fn); > + > + # A single module (common case) also reflects objects that are not > part > + # of a module. Some of those objects have names that are also a > module > + # name (e.g. core). We check the associated module file name, and if > + # they do not match, the object is not part of a module. > + if (mod !~ / /) { > + if (!(mod in mods)) > + mod = ""; > + } > + > + gsub(/([^/ ]*\/)+/, "", mod); > + gsub(/-/, "_", mod); > + > + # At this point, mod is a single (valid) module name, or a list of > + # module names (that do not need validation). > + omod[obj] = mod; > + close(fn); I still see the second close(fn). -- Best Regards Masahiro Yamada

Re: [PATCH v6 3/4] scripts: add verifier script for builtin module range data

2024-08-17 Thread Masahiro Yamada
> + omod[obj] = mod; > + close(fn); > + > + return mod; > +} > This code is copy-paste from scripts/generate_builtin_ranges.awk So, my comments in 2/4 can apply to this patch, too. Instead of adding a separate script, we could add a "verify mode" option. scripts/generate_builtin_ranges.awk --verify ... But, I do not know how much cleaner it will become. I am not good at reviewing AWK code, but this is how you go. If this script were written in Python, it would be easy and readable to split logically-related code chunks into functions, as follows: def parse_module_builtin(): ... def parse_vmlinux_map_lld(): ... def parse_vmlinux_map_bfd(): ... def parse_vmlinux_o_map(): ... -- Best Regards Masahiro Yamada

Re: [PATCH v6 2/4] kbuild, kconfig: generate offset range data for builtin modules

2024-08-17 Thread Masahiro Yamada
} > + close(fn); > + > + # A single module (common case) also reflects objects that are not > part > + # of a module. Some of those objects have names that are also a > module > + # name (e.g. core). We check the associated module file

Re: [PATCH 1/2] module: Split modules_install compression and in-kernel decompression

2024-07-28 Thread Masahiro Yamada
On Thu, Jul 25, 2024 at 9:59 PM Petr Pavlu wrote: > > On 7/22/24 12:23, Masahiro Yamada wrote: > > On Mon, Jul 22, 2024 at 6:07 PM Petr Pavlu wrote: > >> > >> The kernel configuration allows specifying a module compression mode. If > >> one is selected

Re: [PATCH 1/2] module: Split modules_install compression and in-kernel decompression

2024-07-22 Thread Masahiro Yamada
self > instead of relying on userspace to perform this task. Useful when > load pinning security policy is enabled. > diff --git a/scripts/Makefile.modinst b/scripts/Makefile.modinst > index 0afd75472679..bce4a9adb893 100644 > --- a/scripts/Makefile.modinst > +++ b/scripts/Makefile.modinst > @@ -51,9 +51,11 @@ $(foreach x, % :, $(if $(findstring $x, $(dst)), \ > $(error module installation path cannot contain '$x'))) > > suffix-y := > +ifdef CONFIG_MODULE_COMPRESS_ALL > suffix-$(CONFIG_MODULE_COMPRESS_GZIP) := .gz > suffix-$(CONFIG_MODULE_COMPRESS_XZ):= .xz > suffix-$(CONFIG_MODULE_COMPRESS_ZSTD) := .zst > +endif > > modules := $(patsubst $(extmod_prefix)%.o, $(dst)/%.ko$(suffix-y), > $(modules)) > install-$(CONFIG_MODULES) += $(modules) > -- > 2.35.3 > -- Best Regards Masahiro Yamada

Re: [PATCH 2/6] kallsyms: Emit symbol at the holes in the text

2024-07-20 Thread Masahiro Yamada
On Thu, Jul 18, 2024 at 12:45 PM Zheng Yejian wrote: > > On 2024/7/16 16:33, Masahiro Yamada wrote: > > On Thu, Jun 13, 2024 at 10:36 PM Zheng Yejian > > wrote: > >> > >> When a weak type function is overridden, its symbol will be removed > >> fr

Re: [PATCH 2/6] kallsyms: Emit symbol at the holes in the text

2024-07-16 Thread Masahiro Yamada
> if (base_relative) > record_relative_base(); > optimize_token_table(); > diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh > index 518c70b8db50..8e1373902bfe 100755 > --- a/scripts/link-vmlinux.sh > +++ b/scripts/link-vmlinux.s

Re: [PATCH 1/6] kallsyms: Optimize multiple times of realloc() to one time of malloc()

2024-07-15 Thread Masahiro Yamada
; Signed-off-by: Zheng Yejian I do not think this is worthwhile. realloc() is simple. If this is a problem, you can increase the "+= 1" to "+= 65536" or something. -- Best Regards Masahiro Yamada

Re: [PATCH 00/15] Implement MODVERSIONS for Rust

2024-06-18 Thread Masahiro Yamada
On Wed, Jun 19, 2024 at 2:18 AM Greg Kroah-Hartman wrote: > > On Wed, Jun 19, 2024 at 01:50:36AM +0900, Masahiro Yamada wrote: > > On Wed, Jun 19, 2024 at 1:44 AM Greg Kroah-Hartman > > wrote: > > > > > > On Mon, Jun 17, 2024 at 05:58:19PM +, S

Re: [PATCH 00/15] Implement MODVERSIONS for Rust

2024-06-18 Thread Masahiro Yamada
> (e.g., objtool). > > That's cool, can the C code be switched to also use this? That way we > only have one path/code for all of this? As the description says, it requires CONFIG_DEBUG_INFO. We can strip the debug info from the final vmlinux, but I guess the build speed will be even slower than the current genksyms. -- Best Regards Masahiro Yamada

Re: [PATCH 13/15] modpost: Add support for hashing long symbol names

2024-06-18 Thread Masahiro Yamada
-0,0 +1,327 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * symhash.c > + * > + * Symbol name hashing using a SHA-256 implementation adapted from the > + * Cryptographic API. > + */ > +#include > +#include "modpost.h" > + > +#if HOST_ELFD

Re: [PATCH 00/15] Implement MODVERSIONS for Rust

2024-06-18 Thread Masahiro Yamada
pts to add another variant of genksyms. I am also surprised at the tool being added under the tools/ directory. At least, we can avoid the latter misfortune, though. A patch attached (on top of your patch set). Such a tool can be compiled in scripts/, or even better in rust/Makefile if it is on

Re: [PATCH v3 4/6] module: script to generate offset ranges for builtin modules

2024-05-20 Thread Masahiro Yamada
p; /^ \./ && NF == 4 && $3 != "0x0" { > + type = $1; > + if (!(type in sect_addend)) > + next; This assumes sections are 1:1 mapping between vmlinux.o and vmlinux. How far does this assumption work? CONFIG_LD_DEAD_CODE_DATA_ELIMINATION will not work at least. As I said in the previous review, gawk is not documented in Documentation/process/changes.rst Please add it if you go with gawk. > + > + sub(addr_prefix, "0x", $2); > + addr = strtonum($2) + sect_addend[type]; > + > + mod = get_module_info($4); > +# printf "[%s, %08x] %s [%s] %08x\n", mod_name, mod_start, $4, mod, addr; > + if (mod == mod_name) > + next; > + > + if (mod_name) { > + idx = mod_start + sect_base[type] + sect_addend[type]; > + entries[idx] = sprintf("%s %08x-%08x %s", type, mod_start, > addr, mod_name); > + count[type]++; > + } > +# if (mod == "") > +# printf "ENTRY WITHOUT MOD - MODULE MAY END AT %08x\n", addr > + > + mod_name = mod; > + mod_start = addr; > +} > + > +END { > + for (type in count) { > + if (type in sect_anchor) > + entries[sect_base[type]] = sect_anchor[type]; > + } > + > + n = asorti(entries, indices); > + for (i = 1; i <= n; i++) > + print entries[indices[i]]; > +} > -- > 2.43.0 > -- Best Regards Masahiro Yamada

Re: [PATCH v3 2/6] trace: add CONFIG_BUILTIN_MODULE_RANGES option

2024-05-20 Thread Masahiro Yamada
_MAP' to 'depends on VMLINUX_MAP'. BTW, do you need to put this inside 'if FTRACE'? FTRACE is not required to generate the ranges file. -- Best Regards Masahiro Yamada

Re: [PATCH v3 2/6] trace: add CONFIG_BUILTIN_MODULE_RANGES option

2024-05-20 Thread Masahiro Yamada
of > the > + section. > + > + It is fully compatible with CONFIG_RANDOMIZE_BASE and similar late- > + address-modification options. > + > config BOOTTIME_TRACING > bool "Boot-time Tracing support" > depends on TRACING > -- > 2.43.0 > -- Best Regards Masahiro Yamada

Re: [PATCH v3 6/6] module: add install target for modules.builtin.ranges

2024-05-20 Thread Masahiro Yamada
ltin modules.builtin.modinfo > modules.builtin.ranges): $(MODLIB)/%: % FORCE > $(call cmd,install) > > endif > -- > 2.43.0 > -- Best Regards Masahiro Yamada

Re: [PATCH v2 0/6] Generate address range data for built-in modules

2024-05-15 Thread Masahiro Yamada
On Thu, May 16, 2024 at 1:50 AM Kris Van Hees wrote: > > On Mon, May 13, 2024 at 01:43:15PM +0900, Masahiro Yamada wrote: > > On Sun, May 12, 2024 at 7:42???AM Kris Van Hees > > wrote: > > > > > > Especially for tracing applications, it is convenient to be a

Re: [PATCH] modules: Drop the .export_symbol section from the final modules

2024-05-13 Thread Masahiro Yamada
le.lds.S > > +++ b/scripts/module.lds.S > > @@ -13,6 +13,7 @@ SECTIONS { > > /DISCARD/ : { > > *(.discard) > > *(.discard.*) > > + *(.export_symbol) > > } > > > > __ksymtab 0 : { *(SORT(___ksymtab+*)) } > > -- > > 2.27.0 > > -- Best Regards Masahiro Yamada

Re: [PATCH v2 6/6] module: add install target for modules.builtin.ranges

2024-05-13 Thread Masahiro Yamada
On Mon, May 13, 2024 at 2:22 PM Masahiro Yamada wrote: > > On Sun, May 12, 2024 at 7:59 AM Kris Van Hees > wrote: > > > > When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges > > file should be installed in the module install location. > >

Re: [PATCH v2 6/6] module: add install target for modules.builtin.ranges

2024-05-12 Thread Masahiro Yamada
$(call cmd,install) > > +install-$(CONFIG_BUILTIN_MODULE_RANGES) += $(MODLIB)/modules.builtin.ranges > + > +$(MODLIB)/modules.builtin.ranges: modules.builtin.ranges FORCE > + $(call cmd,install) > + Why add this to $(addprefix ...) part? > endif > > modules := $(call read-file, $(MODORDER)) > -- > 2.43.0 > > -- Best Regards Masahiro Yamada

Re: [PATCH v2 5/6] kbuild: generate modules.builtin.ranges when linking the kernel

2024-05-12 Thread Masahiro Yamada
> +targets += modules.builtin.ranges > +modules.builtin.ranges: modules.builtin.objs vmlinux.map vmlinux.o.map FORCE > + $(call if_changed,modules_builtin_ranges) > +endif > + > # Add FORCE to the prequisites of a target to force it to be always rebuilt. > # ------- > > -- > 2.43.0 > > -- Best Regards Masahiro Yamada

Re: [PATCH v2 0/6] Generate address range data for built-in modules

2024-05-12 Thread Masahiro Yamada
/Kconfig| 17 > scripts/Makefile.lib| 5 +- > scripts/Makefile.modinst| 11 ++- > scripts/Makefile.vmlinux| 17 > scripts/Makefile.vmlinux_o | 18 - > scripts/generate_builtin_ranges.awk | 149 > > 11 files changed, 228 insertions(+), 10 deletions(-) > create mode 100755 scripts/generate_builtin_ranges.awk > > > base-commit: dd5a440a31fae6e459c0d627162825505361 > -- > 2.42.0 > > -- Best Regards Masahiro Yamada

Re: [PATCH RFC 0/4] Introduce uts_release

2024-02-21 Thread Masahiro Yamada
On Wed, Feb 21, 2024 at 6:01 PM John Garry wrote: > > On 08/02/2024 10:08, John Garry wrote: > > On 05/02/2024 23:10, Masahiro Yamada wrote: > >>>> I think what you can contribute are: > >>>> > >>>>- Explore the UTS_RELEASE users,

[PATCH] kbuild: remove EXPERT and !COMPILE_TEST guarding from TRIM_UNUSED_KSYMS

2024-02-15 Thread Masahiro Yamada
;) solved the build time issue. Signed-off-by: Masahiro Yamada --- kernel/module/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig index 0ea1b2970a23..c3ced519e14b 100644 --- a/kernel/module/Kconfig +++ b/kernel/module/Kcon

Re: [PATCH RFC 0/4] Introduce uts_release

2024-02-05 Thread Masahiro Yamada
On Mon, Feb 5, 2024 at 5:25 PM John Garry wrote: > > On 02/02/2024 15:01, Masahiro Yamada wrote: > >> -- > >> 2.35.3 > > > > As you see, several drivers store UTS_RELEASE in their driver data, > > and even print it in debug print. > > > >

Re: [PATCH v2 0/3] modules: few of alignment fixes

2024-02-02 Thread Masahiro Yamada
d that the alignment must be added to individual asm code, not to the linker script. I am surprised that you came back to this. -- Best Regards Masahiro Yamada

Re: [PATCH RFC 0/4] Introduce uts_release

2024-02-02 Thread Masahiro Yamada
init_uts_ns.name.release So, is your uts_release a shorthand of init_uts_ns.name.release? I think what you can contribute are: - Explore the UTS_RELEASE users, and check if you can get rid of it. - Where UTS_RELEASE is useful, consider if it is possible to replace it with init_uts_ns.name.release -- Best Regards Masahiro Yamada

Re: [PATCH v7] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms

2024-01-02 Thread Masahiro Yamada
On Mon, Jan 1, 2024 at 8:11 PM Alessandro Carminati wrote: > > Hello, > > > > Il giorno dom 31 dic 2023 alle ore 06:35 Masahiro Yamada > ha scritto: > > > > On Tue, Dec 5, 2023 at 6:48 AM Alessandro Carminati (Red Hat) > > wrote: > > > > &

Re: [PATCH v7] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms

2023-12-30 Thread Masahiro Yamada
linux_nm_lines) > + > +debug_print(config, DebugLevel.INFO.value,"Process nm data for > modules") > +# Process nm data for modules > +debug_print(config,

Re: [PATCH 1/4] linux/export: Fix alignment for 64-bit ksymtab entries

2023-12-23 Thread Masahiro Yamada
On Sat, Dec 23, 2023 at 5:11 AM Luis Chamberlain wrote: > > On Fri, Dec 22, 2023 at 04:01:30PM +0900, Masahiro Yamada wrote: > > On Fri, Dec 22, 2023 at 3:08 PM Luis Chamberlain wrote: > > > > > > On Thu, Dec 21, 2023 at 10:07:13PM -0800, Luis Chamberlain wrote: &g

Re: [PATCH 3/4] vmlinux.lds.h: Fix alignment for __ksymtab*, __kcrctab_* and .pci_fixup sections

2023-12-22 Thread Masahiro Yamada
On Fri, Dec 22, 2023 at 6:02 PM Helge Deller wrote: > > On 12/21/23 14:07, Masahiro Yamada wrote: > > On Thu, Nov 23, 2023 at 7:18 AM wrote: > >> > >> From: Helge Deller > >> > >> On 64-bit architectures without CONFIG_HAVE_ARCH_PREL32_RELO

Re: [PATCH 0/4] Section alignment issues?

2023-12-22 Thread Masahiro Yamada
On Fri, Dec 22, 2023 at 5:23 PM Helge Deller wrote: > > On 12/21/23 16:42, Masahiro Yamada wrote: > > On Thu, Dec 21, 2023 at 10:40 PM Masahiro Yamada > > wrote: > >> > >> On Thu, Nov 23, 2023 at 7:18 AM wrote: > >>> > >>> From:

Re: [PATCH 1/4] linux/export: Fix alignment for 64-bit ksymtab entries

2023-12-21 Thread Masahiro Yamada
using inline assembler, but it hard-codes ".balign 4". -- Best Regards Masahiro Yamada

Re: [PATCH 1/4] linux/export: Fix alignment for 64-bit ksymtab entries

2023-12-21 Thread Masahiro Yamada
On Thu, Dec 21, 2023 at 7:22 PM Masahiro Yamada wrote: > > On Thu, Nov 23, 2023 at 7:18 AM wrote: > > > > From: Helge Deller > > > > An alignment of 4 bytes is wrong for 64-bit platforms which don't define > > CONFIG_HAVE_ARCH_PREL32_RELOCATIONS (which t

Re: [PATCH 0/4] Section alignment issues?

2023-12-21 Thread Masahiro Yamada
On Thu, Dec 21, 2023 at 10:40 PM Masahiro Yamada wrote: > > On Thu, Nov 23, 2023 at 7:18 AM wrote: > > > > From: Helge Deller > > > > While working on the 64-bit parisc kernel, I noticed that the __ksymtab[] > > table was not correctly 64-bit aligned in man

Re: [PATCH 0/4] Section alignment issues?

2023-12-21 Thread Masahiro Yamada
else if (strstr(sec, "text")) /* assume text segments to be > 4-byte aligned */ > - should_shalign = 4; > else if (match(sec, byte_sec_list)) /* any alignment is OK. */ > continue; > + else if (strstr(sec, "text")) /* assume text segments to be > 4-byte aligned */ > + should_shalign = 4; > else { > /* search in list with special alignment */ > - k = 0; > - while (special_list[k].align && strstarts(sec, > special_list[k].name)) { > - should_shalign = special_list[k].align; > - break; > + for (k = 0; special_list[k].align; k++) { > + if (strstarts(sec, special_list[k].name)) { > + should_shalign = > special_list[k].align; > + break; > + } > } > } > > Helge Deller (4): > linux/export: Fix alignment for 64-bit ksymtab entries > modules: Ensure 64-bit alignment on __ksymtab_* sections > vmlinux.lds.h: Fix alignment for __ksymtab*, __kcrctab_* and > .pci_fixup sections > modules: Add missing entry for __ex_table > > include/asm-generic/vmlinux.lds.h | 5 + > include/linux/export-internal.h | 5 - > scripts/module.lds.S | 9 + > 3 files changed, 14 insertions(+), 5 deletions(-) > > -- > 2.41.0 > -- Best Regards Masahiro Yamada

Re: [PATCH 3/4] vmlinux.lds.h: Fix alignment for __ksymtab*, __kcrctab_* and .pci_fixup sections

2023-12-21 Thread Masahiro Yamada
\ > __kcrctab_gpl : AT(ADDR(__kcrctab_gpl) - LOAD_OFFSET) { \ > __start___kcrctab_gpl = .; \ > KEEP(*(SORT(___kcrctab_gpl+*))) \ > -- > 2.41.0 > -- Best Regards Masahiro Yamada

Re: [PATCH 1/4] linux/export: Fix alignment for 64-bit ksymtab entries

2023-12-21 Thread Masahiro Yamada
f-by: Helge Deller This is correct. Acked-by: Masahiro Yamada Please add Fixes: ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost") > --- > include/linux/export-internal.h | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/

Re: [PATCH 0/2] kmod /usr support

2023-12-19 Thread Masahiro Yamada
-moduledir) at least for depmod. (Perhaps modinfo too, as it also supports --basedir) Then, we can change scripts/depmod.sh so that Kbuild can propagate KERNEL_MODULE_DIRECTORY to depmod. if ; then set -- "$@" --moduledir "${KERNEL_MODULE_DIRECTORY}" fi Does it make sense? -- Best Regards Masahiro Yamada

Re: [PATCH v6 2/2] kbuild: rpm-pkg: Fix build with non-default MODLIB

2023-12-18 Thread Masahiro Yamada
On Tue, Dec 12, 2023 at 10:12 PM Michal Suchánek wrote: > > On Mon, Dec 11, 2023 at 01:33:23PM +0900, Masahiro Yamada wrote: > > On Mon, Dec 11, 2023 at 6:09 AM Michal Suchánek wrote: > > > > > > On Mon, Dec 11, 2023 at 03:44:35AM +0900, Masahiro Yamada wrote: &g

Re: [PATCH v6 1/2] depmod: Handle installing modules under a different directory

2023-12-18 Thread Masahiro Yamada
On Tue, Dec 12, 2023 at 10:03 PM Michal Suchánek wrote: > > On Mon, Dec 11, 2023 at 01:29:15PM +0900, Masahiro Yamada wrote: > > On Mon, Dec 11, 2023 at 6:07 AM Michal Suchánek wrote: > > > > > > Hello! > > > > > > On Mon, Dec 11, 2023 at 03:43:4

Re: Building signed debs

2023-12-11 Thread Masahiro Yamada
On Mon, Dec 11, 2023 at 7:19 PM Tom Cook wrote: > > On Sat, Dec 9, 2023 at 6:18 PM Masahiro Yamada wrote: > > On Fri, Dec 8, 2023 at 8:14 PM Tom Cook wrote: > > > > > > I'm trying to build a signed .deb kernel package of > > > https://githu

Re: [PATCH v6 2/2] kbuild: rpm-pkg: Fix build with non-default MODLIB

2023-12-10 Thread Masahiro Yamada
On Mon, Dec 11, 2023 at 6:09 AM Michal Suchánek wrote: > > On Mon, Dec 11, 2023 at 03:44:35AM +0900, Masahiro Yamada wrote: > > On Thu, Dec 7, 2023 at 4:48 AM Michal Suchanek wrote: > > > > > > The default MODLIB value is composed of three variables > >

Re: [PATCH v6 1/2] depmod: Handle installing modules under a different directory

2023-12-10 Thread Masahiro Yamada
On Mon, Dec 11, 2023 at 6:07 AM Michal Suchánek wrote: > > Hello! > > On Mon, Dec 11, 2023 at 03:43:44AM +0900, Masahiro Yamada wrote: > > On Thu, Dec 7, 2023 at 4:48 AM Michal Suchanek wrote: > > > > > > Some distributions aim at shipping all files in /u

Re: [PATCH v6 2/2] kbuild: rpm-pkg: Fix build with non-default MODLIB

2023-12-10 Thread Masahiro Yamada
/mkspec > +++ b/scripts/package/mkspec > @@ -24,6 +24,7 @@ fi > cat< %define ARCH ${ARCH} > %define KERNELRELEASE ${KERNELRELEASE} > +%define KERNEL_MODULE_DIRECTORY ${KERNEL_MODULE_DIRECTORY} > %define pkg_release $("${srctree}/init/build-version") > EOF > > -- > 2.42.0 > > -- Best Regards Masahiro Yamada

Re: [PATCH v6 1/2] depmod: Handle installing modules under a different directory

2023-12-10 Thread Masahiro Yamada
gument can be passed to make if needed. > # > > -MODLIB = $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE) > +export KERNEL_MODULE_DIRECTORY ?= $(or $(shell pkg-config > --variable=module_directory kmod 2>/dev/null),/lib/modules) > + > +MODLIB = $(INSTALL_MOD_PATH)$(KERNEL_MODULE_DIRECTORY)/$(KERNELRELEASE) > export MODLIB > > PHONY += prepare0 > -- > 2.42.0 > > -- Best Regards Masahiro Yamada

Re: [PATCH] init: move THIS_MODULE from to

2023-12-09 Thread Masahiro Yamada
On Tue, Dec 5, 2023 at 2:54 PM Luis Chamberlain wrote: > > On Sun, Nov 26, 2023 at 04:19:14PM +0900, Masahiro Yamada wrote: > > Commit f50169324df4 ("module.h: split out the EXPORT_SYMBOL into > > export.h") appropriately separated EXPORT_SYMBOL into > > bec

Re: Building signed debs

2023-12-09 Thread Masahiro Yamada
: *** [debian/rules:17: binary-arch] Error 2 > dpkg-buildpackage: error: make -f debian/rules binary subprocess > returned exit status 2 > make[2]: *** [scripts/Makefile.package:146: bindeb-pkg] Error 2 > make[1]: *** [/home/tkcook/git/linux/v6.6/Makefile:1538: bindeb-pkg] Error 2 > make: *** [Makefile:234: __sub-make] Error 2 -- Best Regards Masahiro Yamada

Re: [PATCH] init: move THIS_MODULE from to

2023-12-03 Thread Masahiro Yamada
On Sun, Nov 26, 2023 at 4:19 PM Masahiro Yamada wrote: > > Commit f50169324df4 ("module.h: split out the EXPORT_SYMBOL into > export.h") appropriately separated EXPORT_SYMBOL into > because modules and EXPORT_SYMBOL are orthogonal; modules are symbol > consumers, while

[PATCH] init: move THIS_MODULE from to

2023-11-25 Thread Masahiro Yamada
The reason for choosing is to make self-contained without relying on incorrectly including . With this adjustment, the role of becomes clearer as it only defines EXPORT_SYMBOL. Signed-off-by: Masahiro Yamada --- include/linux/export.h | 18 -- include/linux/init.h | 7

Re: [PATCH v2 0/5] MODVERSIONS + RUST Redux

2023-11-23 Thread Masahiro Yamada
Would setting up Rust symbols so that they have a crc built out of .rmeta be > > sufficient for you to consider this useful? If not, can you help me > > understand > > what level of precision would be required? > > What exactly does .rmeta have to do with the function signature? That's > all you care about here. rmeta is generated per crate. CRC is computed per symbol. They have different granularity. It is weird to refuse a module for incompatibility of a symbol that it is not using at all. > thanks, > > greg k-h -- Best Regards Masahiro Yamada

Re: [PATCH v2 0/5] MODVERSIONS + RUST Redux

2023-11-22 Thread Masahiro Yamada
y considered to be a potential userspace break > because kmod tools inspect this kernel module metadata. Masahiro Yamada > suggested [2] that this could instead be done with a section per-field. > This gives us the ability to be more flexible with this format in the > future, as a new fi

Re: [PATCH rebased] kbuild: rpm-pkg: Fix build with non-default MODLIB

2023-10-17 Thread Masahiro Yamada
On Tue, Oct 17, 2023 at 9:27 PM Michal Suchánek wrote: > > On Tue, Oct 17, 2023 at 09:05:29PM +0900, Masahiro Yamada wrote: > > On Tue, Oct 17, 2023 at 7:44 PM Michal Suchánek wrote: > > > > > > On Tue, Oct 17, 2023 at 07:15:50PM +0900, Masahiro Yamada wrote: >

Re: [PATCH rebased] kbuild: rpm-pkg: Fix build with non-default MODLIB

2023-10-17 Thread Masahiro Yamada
On Tue, Oct 17, 2023 at 7:44 PM Michal Suchánek wrote: > > On Tue, Oct 17, 2023 at 07:15:50PM +0900, Masahiro Yamada wrote: > > > > > > > > Let me add more context to my question. > > > > > > > > > > > > I am interested in

Re: [PATCH rebased] kbuild: rpm-pkg: Fix build with non-default MODLIB

2023-10-17 Thread Masahiro Yamada
ave such a crazy distro that installs modules under /opt/ directory. I could not understand why you inserted "--print-variables kmod 2>/dev/null | grep '^module_directory$$' >/dev/null" but I guess the reason is the same. "pkg-config --variable=module_directory kmod" always succeeds, so "|| echo /lib/modules" is never processed. I do not know why you parsed kmod.pc instead of libkmod.pc [2] [1] https://lore.kernel.org/linux-kbuild/20230718120348.383-1-msucha...@suse.de/ [2] https://github.com/kmod-project/kmod/blob/v31/configure.ac#L295 -- Best Regards Masahiro Yamada

[PATCH v2 1/2] kbuild: unify vdso_install rules

2023-10-14 Thread Masahiro Yamada
rom arch/arm64/Makefile. vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so This will rename vdso.so.dbg to vdso32.so during installation. If such architectures change their implementation so that the base names match, this workaround will go away. Signed-off-by:

[PATCH v2 2/2] kbuild: unify no-compiler-targets and no-sync-config-targets

2023-10-14 Thread Masahiro Yamada
Now that vdso_install does not depend on any in-tree build artifact, it no longer needs a compiler, making no-compiler-targets the same as no-sync-config-targets. Signed-off-by: Masahiro Yamada --- Changes in v2: - Revive need-compiler flag Makefile | 13 ++--- 1 file changed, 2

Re: [PATCH 1/5] csky: remove unused cmd_vdso_install

2023-10-14 Thread Masahiro Yamada
On Tue, Oct 10, 2023 at 12:16 AM Guo Ren wrote: > > On Mon, Oct 9, 2023 at 8:42 PM Masahiro Yamada wrote: > > > > You cannot run this code because arch/csky/Makefile does not define the > > vdso_install target. > > > > It appears that this code was blindly cop

Re: [PATCH 5/5] kbuild: unify no-compiler-targets and no-sync-config-targets

2023-10-14 Thread Masahiro Yamada
On Tue, Oct 10, 2023 at 1:44 AM Nathan Chancellor wrote: > > On Mon, Oct 09, 2023 at 09:42:10PM +0900, Masahiro Yamada wrote: > > Now that vdso_install does not depend on any in-tree build artifact, > > it no longer invokes a compiler, making no-compiler-targets the same >

Re: [PATCH 4/5] kbuild: unify vdso_install rules

2023-10-11 Thread Masahiro Yamada
On Wed, Oct 11, 2023 at 11:24 AM Guo Ren wrote: > > On Mon, Oct 9, 2023 at 8:42 PM Masahiro Yamada wrote: > > --- a/arch/riscv/Makefile > > +++ b/arch/riscv/Makefile > > @@ -131,12 +131,6 @@ endif > > libs-y += arch/riscv/lib/ > > libs-$(CONFIG_EFI_STUB

Re: [PATCH rebased] kbuild: rpm-pkg: Fix build with non-default MODLIB

2023-10-09 Thread Masahiro Yamada
On Mon, Oct 9, 2023 at 11:07 PM Michal Suchánek wrote: > > On Mon, Oct 09, 2023 at 09:34:10PM +0900, Masahiro Yamada wrote: > > On Mon, Oct 9, 2023 at 5:52 PM Michal Suchánek wrote: > > > > > > Hello, > > > > > > On Mon, Oct 09, 2023 at 05:31:0

[PATCH 5/5] kbuild: unify no-compiler-targets and no-sync-config-targets

2023-10-09 Thread Masahiro Yamada
Now that vdso_install does not depend on any in-tree build artifact, it no longer invokes a compiler, making no-compiler-targets the same as no-sync-config-targets. Signed-off-by: Masahiro Yamada --- Makefile | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a

[PATCH 4/5] kbuild: unify vdso_install rules

2023-10-09 Thread Masahiro Yamada
, this workaround will go away. Signed-off-by: Masahiro Yamada --- Makefile | 9 ++ arch/arm/Makefile | 7 +--- arch/arm/vdso/Makefile | 25 -- arch/arm64/Makefile| 9 ++ arch/arm64/ke

[PATCH 3/5] parisc: remove broken vdso_install

2023-10-09 Thread Masahiro Yamada
arisc does not define CONFIG_COMPAT_VDSO. It appears that this code was copied from another architecture without proper adaptation. Remove the broken code. Signed-off-by: Masahiro Yamada --- arch/parisc/Makefile | 7 --- 1 file changed, 7 deletions(-) diff --git a/arch/parisc/Makefile b/a

  1   2   3   4   5   6   7   8   9   10   >