On 4/30/25 23:40, Sami Tolvanen wrote:
> A data structure can be partially opaque to modules if its
> allocation is handled by the core kernel, and modules only need
> to access some of its members. In this situation, it's possible
> to append new members to the structure without breaking the ABI,
> as long as the layout for the original members remains unchanged.
> For example, consider the following struct:
> 
>   struct s {
>           unsigned long a;
>           void *p;
>   };
> 
> gendwarfksyms --stable --dump-dies produces the following type
> expansion:
> 
>   variable structure_type s {
>     member base_type long unsigned int byte_size(8) encoding(7) a
>       data_member_location(0) ,
>     member pointer_type {
>       base_type void
>     } byte_size(8) p data_member_location(8)
>   } byte_size(16)
> 
> To append new members, we can use the KABI_IGNORE() macro to
> hide them from gendwarfksyms --stable:
> 
>   struct s {
>           /* old members with unchanged layout */
>           unsigned long a;
>           void *p;
> 
>           /* new members not accessed by modules */
>           KABI_IGNORE(0, unsigned long n);
>   };
> 
> However, we can't hide the fact that adding new members changes
> the struct size, as seen in the updated type string:
> 
>   variable structure_type s {
>     member base_type long unsigned int byte_size(8) encoding(7) a
>       data_member_location(0) ,
>     member pointer_type {
>       base_type void
>     } byte_size(8) p data_member_location(8)
>   } byte_size(24)
> 
> In order to support this use case, add a kABI rule that makes it
> possible to override the byte_size attribute for types:
> 
>   /*
>    * struct s allocation is handled by the kernel, so
>    * appending new members without changing the original
>    * layout won't break the ABI.
>    */
>   KABI_BYTE_SIZE(s, 16);
> 
> This results in a type string that's unchanged from the original
> and therefore, won't change versions for symbols that reference
> the changed structure.
> 
> Signed-off-by: Sami Tolvanen <samitolva...@google.com>

Reviewed-by: Petr Pavlu <petr.pa...@suse.com>

-- Petr

Reply via email to