[LTP] [PATCH v2 1/7] Add fallback definitions for lapi/fs.h

[Li Wang]

On Thu, Jul 25, 2024 at 12:29 AM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > diff --git a/configure.ac b/configure.ac
> > index 1f8796c87..4d466f052 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -177,6 +177,7 @@ AC_CHECK_TYPES([struct acct_v3],,,[#include
> <sys/acct.h>])
> >  AC_CHECK_TYPES([struct af_alg_iv, struct sockaddr_alg],,,[# include
> <linux/if_alg.h>])
> >  AC_CHECK_TYPES([struct fanotify_event_info_fid, struct
> fanotify_event_info_error,
> >               struct fanotify_event_info_header, struct
> fanotify_event_info_pidfd],,,[#include <sys/fanotify.h>])
> > +AC_CHECK_TYPES([struct file_clone_range],,,[#include <linux/fs.h>])
> >  AC_CHECK_TYPES([struct file_dedupe_range],,,[#include <linux/fs.h>])
> >
> >  AC_CHECK_TYPES([struct file_handle],,,[
> > diff --git a/include/lapi/fs.h b/include/lapi/fs.h
> > index 635979b02..0e8d646d8 100644
> > --- a/include/lapi/fs.h
> > +++ b/include/lapi/fs.h
> > @@ -20,6 +20,15 @@
> >  #include <limits.h>
> >  #include "lapi/abisize.h"
> >
> > +#ifndef HAVE_FILE_CLONE_RANGE
> > +struct file_clone_range {
> > +     int64_t src_fd;
> > +     uint64_t src_offset;
> > +     uint64_t src_length;
> > +     uint64_t dest_offset;
> > +};
> > +#endif
>
> Sigh, this is still horribly broken even when I fixed the macro to
> HAVE_STRUCT_FILE_CLONE_RANGE that is because:
>
> commit b857f8723f30a4b9554bf6b0ff8fa52fd07e8b60
> Author: Li Wang <liwang@redhat.com>
> Date:   Fri Aug 5 14:34:01 2022 +0800
>
>     lapi/fsmount: resolve conflict in different header files
>
>
> However the CI seems to work fine if I remove the HAVE_MOUNT_SETATTR
> check with:
>
>  #define LAPI_FS_H__
>
>  #include "config.h"
> -#ifndef HAVE_MOUNT_SETATTR
> -# ifdef HAVE_LINUX_FS_H
> -#  include <linux/fs.h>
> -# endif
> +
> +#ifdef HAVE_LINUX_FS_H
> +# include <linux/fs.h>
>  #endif
>
>  #include <sys/user.h>
>
>
> @Li do we still need that ifdef or can we get rid of it?
>

Theoretically, we can remove it because that problem is addressed in
Glibc-2.37 by:


https://github.com/kraj/glibc/commit/774058d72942249f71d74e7f2b639f77184160a6

It is essentially a glibc bug we don't need to fix that in LTP.

We ever discussed in
https://lists.linux.it/pipermail/ltp/2023-March/033138.html

However, if we want LTP could be built with all the middle glibc versions
(2.22 < glibc < 2.36)
this might be thinking over. Because we announce support the minimal
glibc-version is 2.22.


-- 
Regards,
Li Wang