| #
514fff24
|
| 21-Oct-2025 |
Ed Maste <emaste@FreeBSD.org> |
closefrom.2: Add introduction of close_range to HISTORY
Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D53240
|
| #
efadb5c2
|
| 17-May-2025 |
Ricardo Branco <rbranco@suse.de> |
Add manpages for O_CLOFORK flag and others
Reviewed by: kib MFC after: 1 month Pull Request: https://github.com/freebsd/freebsd-src/pull/1698
|
| #
8269e767
|
| 14-Nov-2023 |
Brooks Davis <brooks@FreeBSD.org> |
libsys: relocate implementations and manpages
Remove core system call implementations and documentation to lib/libsys and lib/libsys/<arch> from lib/libc/sys and lib/libc/<arch>/<sys>. Update paths
libsys: relocate implementations and manpages
Remove core system call implementations and documentation to lib/libsys and lib/libsys/<arch> from lib/libc/sys and lib/libc/<arch>/<sys>. Update paths to allow libc to find them in their new home.
Reviewed by: kib, emaste, imp Pull Request: https://github.com/freebsd/freebsd-src/pull/908
show more ...
|
| #
fa9896e0
|
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: two-line nroff pattern
Remove /^\.\\"\n\.\\"\s*\$FreeBSD\$$\n/
|
| #
f3f3e3c4
|
| 03-Mar-2022 |
Mateusz Guzik <mjg@FreeBSD.org> |
fd: add close_range(..., CLOSE_RANGE_CLOEXEC)
For compatibility with Linux.
MFC after: 3 days Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D34424
|
| #
472ced39
|
| 12-Apr-2020 |
Kyle Evans <kevans@FreeBSD.org> |
Implement a close_range(2) syscall
close_range(min, max, flags) allows for a range of descriptors to be closed. The Python folk have indicated that they would much prefer this interface to closefrom
Implement a close_range(2) syscall
close_range(min, max, flags) allows for a range of descriptors to be closed. The Python folk have indicated that they would much prefer this interface to closefrom(2), as the case may be that they/someone have special fds dup'd to higher in the range and they can't necessarily closefrom(min) because they don't want to hit the upper range, but relocating them to lower isn't necessarily feasible.
sys_closefrom has been rewritten to use kern_close_range() using ~0U to indicate closing to the end of the range. This was chosen rather than requiring callers of kern_close_range() to hold FILEDESC_SLOCK across the call to kern_close_range for simplicity.
The flags argument of close_range(2) is currently unused, so any flags set is currently EINVAL. It was added to the interface in Linux so that future flags could be added for, e.g., "halt on first error" and things of this nature.
This patch is based on a syscall of the same design that is expected to be merged into Linux.
Reviewed by: kib, markj, vangyzen (all slightly earlier revisions) Differential Revision: https://reviews.freebsd.org/D21627
show more ...
|
| #
179fa75e
|
| 23-Apr-2015 |
John Baldwin <jhb@FreeBSD.org> |
Reassign copyright statements on several files from Advanced Computing Technologies LLC to Hudson River Trading LLC.
Approved by: Hudson River Trading LLC (who owns ACT LLC) MFC after: 1 week
|
| #
c4f16b69
|
| 15-Jun-2009 |
John Baldwin <jhb@FreeBSD.org> |
Add a new 'void closefrom(int lowfd)' system call. When called, it closes any open file descriptors >= 'lowfd'. It is largely identical to the same function on other operating systems such as Solar
Add a new 'void closefrom(int lowfd)' system call. When called, it closes any open file descriptors >= 'lowfd'. It is largely identical to the same function on other operating systems such as Solaris, DFly, NetBSD, and OpenBSD. One difference from other *BSD is that this closefrom() does not fail with any errors. In practice, while the manpages for NetBSD and OpenBSD claim that they return EINTR, they ignore internal errors from close() and never return EINTR. DFly does return EINTR, but for the common use case (closing fd's prior to execve()), the caller really wants all fd's closed and returning EINTR just forces callers to call closefrom() in a loop until it stops failing.
Note that this implementation of closefrom(2) does not make any effort to resolve userland races with open(2) in other threads. As such, it is not multithread safe.
Submitted by: rwatson (initial version) Reviewed by: rwatson MFC after: 2 weeks
show more ...
|