Re: close_range?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 30 Mar 2025 19:56:42 -0400 (EDT)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <202503302356.TAA23923%Stone.Rodents-Montreal.ORG@localhost>

  | > [...] (I'll ignore `unshare' for now which does not really have
  | > first-class semantics in NetBSD anyway.) [...]
  |
  | What _are_ its semantics?  Based on the name, my reaction would be to
  | expect that either (a) it's got something to do with threading and/or
  | Linuxish clone(CLONE_FILES),

That is what I believe it is - two processes (or threads) can actually
share fds (close in one and it closes in the other, CLOEXEC on or off in
one and affects the other(s) as well).   I find it hard to even imagine
a situation where this is a sane programming model, and would prefer to
keep it out of NetBSD (though I think we might have some of it as part of
what we have to suffer for the linux emulation stuff).

FWIW Christos' implementation of this part in the patch he made available
looked broken to me.   But I don't really follow how any of that is intended
to work, and could easily be wrong.   I'm concerned with the way that the
process and thread's fd pointers are updated, after a new fd table is cloned
from the old (shared) one, nothing seems to be done with any other threads'
pointers, but perhaps that's correct?

  | I don't like the close_range() name, because it sometimes has nothing
  | to do with closing (the unshare option).

It always does the closing, except with the CLOEXEC option, the "unshare"
option really just means "my fds only, not anyone elses" - though the only
way to achieve that is to uncouple the fd tables completely.

  | I also see no need for burning another syscall number; I'd prefer to make
  | those fcntl() operations,

I was going to say that as well, these are obvious fcntl() operations, 3
different ones - one to unshare (assuming we want to bother with that concept
in native NetBSD at all), one to be just like F_CLOSEM except with an additional
parameter to set the upper limit on what gets closed, and a third to be a
variant of F_SETFD with an additional arg to specify a range of FDs to alter,
and the semantic that it only ever sets the bits set in the arg, and perhaps
another variant which only clears the bits set - that variation wouldn't be
needed if there was only FD_CLOEXEC, but:.

Both F_SETFD and any new one(s), need to implement FD_CLOFORK (along with an
implementation of O_CLOFORK) as well.   That's in POSIX now.   I'm not sure
if we should be versioning F_GETFD though so the old one only ever returns
0/1 (never FD_CLOFORK) as I suspect there's quite a lot of code that simply
assumes that any non-zero return value means close-on-exec is set.

  | either with more than three arguments or with the third arg
  | being a pointer to a struct.

Definitely the former, fcntl() is a varargs function.   But I don't think
we would need anything with more than 3 args, using fcntl() there's no need
to have more than 3 args for any of these operations.

kre