[LTP] [PATCH v3 1/2] tst_memutils.c: Add tst_print_meminfo function

Li Wang liwang@redhat.com
Mon Dec 18 04:51:31 CET 2023


Li Wang <liwang@redhat.com> wrote:


>
>> > +++ b/lib/safe_macros.c
>>
>> We don't want to add anything to the legacy API (otherwise it would go to
>> lib/safe_file_ops.c), please add this to lib/tst_safe_macros.c.
>>
>> BTW I'm slightly confused, what would be the best place for this,
>> lib/tst_safe_macros.c is being used nowadays for everything. But there is
>> also
>>
>
>
>> include/tst_safe_file_ops.h, which does not have C file
>> (lib/tst_safe_file_ops.c) because it internally use lib/tst_safe_macros.c.
>>
>
> No, basically it does not use the lib/tst_safe_macros.c.
>
> From what I understand, 'tst_safe_file_ops.h' is just a header for
> collecting
> all the file operations for Linux, it doesn't touch other subcomponent ops.
>
> 'tst_safe_file_ops.h' defines macros for all functions in
> 'safe_file_ops_fn.h'
> and archived them in 'safe_file_ops.c' lib.
>
> Something like this combination:
>
> tst_safe_file_ops.h:
>     safe_file_ops_fn.h
>     safe_file_ops.c
>

The reason to split them into two headers is for backward compatibility.

Technically we should declare 'safe_file_ops_fn.h' functions in one header
'tst_safe_file_ops.h' but you know we have 'old_safe_file_ops.h'.

tst_safe_file_ops.h:
    safe_file_ops_fn.h
    safe_file_ops.c

old_safe_file_ops.h:
    safe_file_ops_fn.h
    safe_file_ops.c

In the future, the ideal cleanup direction is just to have:

tst_safe_file_ops.h
tst_safe_file_ops.c


-- 
Regards,
Li Wang


More information about the ltp mailing list