[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 12 Nov 2019 23:01:51 +0100
From: Petr Vorel <petr.vorel@...il.com>
To: musl@...ts.openwall.com, Rich Felker <dalias@...ifal.cx>,
Szabolcs Nagy <nsz@...t70.net>
Subject: Re: [RFC] fanotify_event_info_fid incompatibility
Hi,
> > [1] https://github.com/linux-test-project/ltp/tree/master/testcases/kernel/syscalls/fanotify
> this test code has internal apis like
> static inline void fanotify_get_fid(const char *path, __kernel_fsid_t *fsid,
> struct file_handle *handle)
> which will not work if fsid has any other type than __kernel_fsid_t,
> so matching the field name is not enough, you need the linux type here.
Yep, that's exactly the problem. But I didn't ask to find a solution for LTP
(that's not difficult), I wanted to raise the problem for musl developers to
reconsider that incompatibility. The only thing I'm not sure, if any other
application will want to access fsid member (searching on sources.debian.org and
github.com I found only fatrace [2], but it don't touch val/__val, so probably not).
> mixing linux and libc types have lot of problems, so i'd suggest to
> just use linux headers instead of libc ones to test this api.
> there are other solutions (like replicating the struct definitions
> with different names and memcpy the api struct to that before access),
> but it can't be completely clean, because there is a fundamental
> conflict. (unfortunately that conflict is documented: the linux man
> pages document the linux types as public api even though they don't
> mix well with libc types)
Yep, known problem [3].
Kind regards,
Petr
[2] https://sources.debian.org/src/fatrace/0.15-1/fatrace.c/?hl=149#L149
[3] https://sourceware.org/glibc/wiki/Synchronizing_Headers
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
