[LTP] [PATCH] syscalls/ustat: Move the syscall to lapi

Steve Muckle smuckle@google.com
Fri Feb 22 20:43:48 CET 2019

On 02/22/2019 07:00 AM, Cyril Hrubis wrote:
> Hi!
>>>>> diff --git a/include/lapi/ustat.h b/include/lapi/ustat.h
>>>>> index 12c073582..6365b2e92 100644
>>>>> --- a/include/lapi/ustat.h
>>>>> +++ b/include/lapi/ustat.h
>>>>> @@ -10,12 +10,19 @@
>>>>>   #ifdef HAVE_SYS_USTAT_H
>>>>>   # include <sys/ustat.h>
>>>> Just a thought, but this is potentially a problem if lib C implementes
>>>> ustat in user land, but the system call still exists. Which I think is
>>>> more likely with an obsolete system call.
>>> Good point. So it all depends on what we want to focus on, if we are
>>> after kernel, we should call the syscall directly, if we look at system
>>> functionality we should go after the libc one by default.
>>> I guess that ideally we should test both, not sure how to achiveve that
>>> reasonably easily...

This seems to me a great feature to have as well - it would address the 
concern that was just recently raised about having to choose between 
focusing on testing at the libc level or the kernel syscall level.
>> Possibly we could create a config option which forcibly sets (almost)
>> all the HAVE_* macros to zero. This will probably result in a lot of
>> tests being skipped as well, but it might be good enough.
> I don't think that this will actully get past linking, I suppose we
> would end up with two confilicting syscall wrappers in most of the
> cases.

Perhaps something like how the compat_16 syscalls are handled? Test libc 
wrappers by default if the host has them, and for syscalls that can 
easily be called directly, add an extra bit in the test's Makefile that 
causes a "<testname>_direct" version of the test to be built using a 
direct syscall?

More information about the ltp mailing list