Re: proposed libc interface and man page for statmount(2)

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 15/11/23 12:08, Miklos Szeredi wrote:
> Hi,
> 
> Attaching the proposed man page for the new statmount() syscall.
> 
> It describes a libc interface that is slightly different from the raw
> kernel API.   The differences from the two API's are also described in
> the man page.
> 
> Raw:
> 
>        long syscall(SYS_statmount, const struct mnt_id_req *req,
>                     struct statmount *buf, size_t bufsize, unsigned int flags);
> 
> Libc:
> 
>        struct statmount *statmount(uint64_t mnt_id, uint64_t request_mask,
>                                    struct statmount *buf, size_t bufsize,
>                                    unsigned int flags);
> 
> I propose the libc one to allow automatically allocating the buffer if
> the buf argument is NULL, similar to getcwd(3).

The glibc getcwd implementation allocates a buffer with maximum size
of max(PATH_MAX, getpagesize()) and iff getpwd syscall fails it will 
fallback to a generic implementation that keep calling openat and realloc 
the buf if required.  So for the generic case, it would require malloc
plus realloc (to free some unused memory).

Making statmount similar to getcwd would require something alike, where 
the libc will loop to reallocate the buffer if syscall returns EOVERFLOW.
I am not sure this would be the best interface, come up the initial buffer
size and the increment might be tricky and not ideal for all usage cases.

Maybe setting the initial size depending of request_mask bits, by assuming
a reasonable size for STMT_FS_TYPE and PATH_MAX for STMT_MNT_ROOT/STMT_MNT_POINT
would be a reasonable initial size. 

It also always pull malloc, which is not ideal for the static linking case
since the interface not always return the strings.