Re: [PATCH v3 3/3] Documentation: livepatch: add section about arch-specific code

[Petr Mladek <pmladek@suse.com>]

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".

Otherwise, it looks fine.

Reviewed-by: Petr Mladek <pmladek@suse.com>

Best Regards,
Petr