Messages in this thread Patch in this message | | | Date | Thu, 18 Aug 2016 14:06:10 -0400 | From | Jessica Yu <> | Subject | Re: Documentation: livepatch: add section about arch-specific code |
| |
+++ Petr Mladek [18/08/16 11:57 +0200]: >On Wed 2016-08-17 20:58:30, Jessica Yu wrote: >> Document usage of arch-specific elf sections in livepatch as well >> as implementation of arch-specific code. >> >> Signed-off-by: Jessica Yu <jeyu@redhat.com> >> --- >> Documentation/livepatch/module-elf-format.txt | 20 ++++++++++++++++---- >> 1 file changed, 16 insertions(+), 4 deletions(-) >> >> diff --git a/Documentation/livepatch/module-elf-format.txt b/Documentation/livepatch/module-elf-format.txt >> index eedbdcf..02bfafa 100644 >> --- a/Documentation/livepatch/module-elf-format.txt >> +++ b/Documentation/livepatch/module-elf-format.txt >> @@ -25,7 +25,8 @@ Table of Contents >> 3.3.2 Required name format >> 3.3.3 Example livepatch symbol names >> 3.3.4 Example `readelf --symbols` output >> -4. Symbol table and Elf section access >> +4. Architecture-specific sections >> +5. Symbol table and Elf section access >> >> ---------------------------- >> 0. Background and motivation >> @@ -46,7 +47,7 @@ architecture. >> >> Since apply_relocate_add() requires access to a module's section header >> table, symbol table, and relocation section indices, Elf information is >> -preserved for livepatch modules (see section 4). Livepatch manages its own >> +preserved for livepatch modules (see section 5). Livepatch manages its own >> relocation sections and symbols, which are described in this document. The >> Elf constants used to mark livepatch symbols and relocation sections were >> selected from OS-specific ranges according to the definitions from glibc. >> @@ -117,7 +118,7 @@ also possible for a livepatch module to have no livepatch relocation >> sections, as in the case of the sample livepatch module (see >> samples/livepatch). >> >> -Since Elf information is preserved for livepatch modules (see Section 4), a >> +Since Elf information is preserved for livepatch modules (see Section 5), a >> livepatch relocation section can be applied simply by passing in the >> appropriate section index to apply_relocate_add(), which then uses it to >> access the relocation section and apply the relocations. >> @@ -292,8 +293,19 @@ Symbol table '.symtab' contains 127 entries: >> [*] Note that the 'Ndx' (Section index) for these symbols is SHN_LIVEPATCH (0xff20). >> "OS" means OS-specific. >> >> +--------------------------------- >> +4. Architecture-specific sections >> +--------------------------------- >> +Architectures may override arch_klp_init_object_loaded() to perform >> +additional arch-specific tasks when a target module loads, such as applying >> +arch-specific sections. On x86 for example, we must apply per-object >> +.altinstructions and .parainstructions sections when a target module loads. >> +These sections can be prefixed with ".klp.arch.$objname." so that they can > ^^^ > >I would personally use "must" instead of "can". Or replace "can be prefixed" >with "are prefixed".
Agreed, poor word choice there. Let's just swap "can" with "must."
Jessica
| |