Messages in this thread | | | Subject | Re: [PATCH v4 06/10] modpost: Add modinfo flag to livepatch modules | From | Joe Lawrence <> | Date | Mon, 19 Aug 2019 11:55:19 -0400 |
| |
On 8/18/19 11:50 PM, Masahiro Yamada wrote: > Hi Joe, > > On Sat, Aug 17, 2019 at 4:01 AM Joe Lawrence <joe.lawrence@redhat.com> wrote: >> >> >> I didn't realize that we're supposed to be able to still build external >> modules after "make clean". If that's the case, then one might want to >> build an external klp-module after doing that. > > Yes. 'make clean' must keep all the build artifacts > needed for building external modules. > > >> With that in mind, shouldn't Symbols.list to persist until mrproper? >> And I think modules-livepatch could go away during clean, what do you think? >> >> -- Joe > > > Symbols.list should be kept by the time mrproper is run. > So, please add it to MRROPER_FILES instead of CLEAN_FILES. > > modules.livepatch is a temporary file, so you can add it to > CLEAN_FILES. >
OK, I'll add those to their respective lists.
> How is this feature supposed to work for external modules? > > klp-convert receives: > "symbols from vmlinux" + "symbols from no-klp in-tree modules" > + "symbols from no-klp external modules" ?? >
I don't think that this use-case has been previously thought out (Miroslav, correct me if I'm wrong here.)
I did just run an external build of a copy of samples/livepatch/livepatch-annotated-sample.c:
- modules.livepatch is generated in external dir - klp-convert is invoked for the livepatch module - the external livepatch module successfully loads
But that was only testing external livepatch modules.
I don't know if we need/want to support general external modules supplementing Symbols.list, at least for the initial klp-convert commit. I suppose external livepatch modules would then need to specify additional Symbols.list(s) files somehow as well.
> > BTW, 'Symbols.list' sounds like a file to list out symbols > for generic purposes, but in fact, the > file format is very specific for the klp-convert tool. > Perhaps, is it better to rename it so it infers > this is for livepatching? What do you think? >
I don't know if the "Symbols.list" name and leading uppercase was based on any convention, but something like symbols.klp would be fine with me.
Thanks,
-- Joe
| |