<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Petr,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 16, 2020 at 9:17 PM Petr Vorel <<a href="mailto:pvorel@suse.cz" target="_blank">pvorel@suse.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail_default" style="font-size:small">...</span><br>
> >  include/lapi/syscalls/<a href="http://powerpc64.in" rel="noreferrer" target="_blank">powerpc64.in</a>            |  4 +<br>
> Is there any reason why only add syscall num for ppc64?<br>
The other numbers are already there:<br>
01e4dc222 lapi/syscalls: Add MIPS support<br>
c2f27f6e9 Add syscall numbers for new file-system related syscalls<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">Good to know this.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Not sure if we should add a note in the commit message to prevent confusion<br>
later (probably not needed).<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">Or just mentionion that commit(c2f27f6e9 Add syscall numbers ...) message.</div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> BTW, I like the way Viresh Kumar gives in his fsmount.h, it looks more tidy<br>
> and clean.<br>
> <a href="http://lists.linux.it/pipermail/ltp/2020-February/015413.html" rel="noreferrer" target="_blank">http://lists.linux.it/pipermail/ltp/2020-February/015413.html</a><br>
Hm, competing implementations.<br>
Both tries to handle preventing redefinitions (e.g. FSOPEN_CLOEXEC) once<br>
the API hits libc headers (at least in musl it might be soon).<br>
Zorro tries to bind them to function check (e.g. #ifndef HAVE_FSMOUNT, #ifndef<br>
HAVE_MOVE_MOUNT), Viresh just use single check #ifndef OPEN_TREE_CLONE.<br>
I slightly prefer Viresh way (it's unlikely that libc headers would include just<br></blockquote><div><span class="gmail_default" style="font-size:small">+1 Viresh way.</span></div><div><span class="gmail_default" style="font-size:small"></span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
part of the new mount API definitions, although obviously the most safest way<br>
would be to either guard with #ifndef each definition or just give up on testing<br>
header and copy whole include/uapi/linux/mount.h (+ avoid using sys/mount.h;<br>
that's the way used for include/lapi/bpf.h).<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">@Cyril, @Jan, any else suggestion?</div><div class="gmail_default" style="font-size:small"></div><div> </div></div><div class="gmail_default" style="font-size:small">Btw, we have to include "lapi/fcntl.h" in the test to get rid of build error from old(RHEL5.11) distro:</div><div class="gmail_default" style="font-size:small"><br></div>fsmount01.c:71: error: ‘AT_FDCWD’ undeclared (first use in this function)<br>fsmount01.c:71: error: (Each undeclared identifier is reported only once<br>fsmount01.c:71: error: for each function it appears in.)<div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>