Re: [PATCH v4 06/10] modpost: Add modinfo flag to livepatch modules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> 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



[Index of Archives]     [Linux&nblp;USB Development]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite Secrets]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux