Am 18.04.20 um 21:00 schrieb Miklos Szeredi: > On Sat, Apr 18, 2020 at 8:36 PM Stefan Metzmacher wrote: >> >> Hi Miklos, >> >>> POSIX defines faccessat() as having a fourth "flags" argument, while the >>> linux syscall doesn't have it. Glibc tries to emulate AT_EACCESS and >>> AT_SYMLINK_NOFOLLOW, but AT_EACCESS emulation is broken. >>> >>> Add a new faccessat(2) syscall with the added flags argument and implement >>> both flags. >>> >>> The value of AT_EACCESS is defined in glibc headers to be the same as >>> AT_REMOVEDIR. Use this value for the kernel interface as well, together >>> with the explanatory comment. >> >> It would be nice if resolv_flags would also be passed in addition to the >> at flags. >> See:https://lore.kernel.org/linux-api/CAHk-=wiaL6zznNtCHKg6+MJuCqDxO=yVfms3qR9A0czjKuSSiA@mail.gmail.com/ >> >> We should avoid expecting yet another syscall in near future. > > What is the objection against > > openat(... O_PATH) > foobarat(fd, AT_EMPTY_PATH, ...) openat2(), foobarat(), close() are 3 syscalls vs. just one. As we have the new features available, I think it would be good to expose them to userspace for all new syscalls, so that applications can avoid boiler plate stuff around each syscall and get better performance in a world where context switches are not for free. metze