Sergey Bugaev, le dim. 07 nov. 2021 18:18:27 +0300, a ecrit:
> On Sun, Nov 7, 2021 at 6:00 PM Samuel Thibault <samuel.thiba...@gnu.org>
> wrote:
> > > That doesn't seem to work: it uses support_descriptors_* () which
> > > walks over /proc/self/fd/ which procfs doesn't implement — though I
> > > guess it could, via msg_get_dtable () & msg_get_fd () and even
> > > FS_RETRY_MAGICAL.
> >
> > It'd probably not that simple, because self/ is actually just a
> > magic retry on the pid variable, so in the end you'd be just opening
> > /proc/<callerpid>/fd. Exposing fd there with a magic retry would expose
> > the fd of the _caller_ in all /proc/*/, which is not what we want: we
> > want the fd/ there to be per-pid.
>
> What I meant is if we see a dir_lookup ("self/fd/42"), we might just
> tell you to retry with your own fd 42, without having to actually
> resolve what "self" means in terms of PIDs.
libnetfs does not this way, see libnetfs/dir-lookup.c, it'll first look
for self/, then for the rest, directory by directory.
> GLIBC_2.35 and not GLIBC_2.34? I also don't think I quite understand
> what __libc_close_range would be useful for (over __close_range) and
> so whether it's needed,
Ah, I had assumed you had copied it over from the linux close_range.
The libc_ variants are usually only needed when libc needs a non-posix
behavior for its internal uses. If nothing calls it it's not useful.
Sometimes there are unused remnants from the past.
> Also maybe you happen to know: why are the argument names in the
> header prefixed with double underscores (__first, __last, __flags)? I
> mimicked what I saw elsewhere, but I'm wondering about the purpose of
> this.
It's to avoid somebody doing
#define first bla bla
#include <unistd.h>
Samuel
