History log of /src/lib/libsys/accept.2 (Results 1 – 25 of 46)
Revision Date Author Comments
# 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 ...


# dc36d6f9 23-Nov-2023 Warner Losh <imp@FreeBSD.org>

lib: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl s

lib: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.

Sponsored by: Netflix

show more ...


# b2c76c41 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

Remove $FreeBSD$: one-line nroff pattern

Remove /^\.\\"\s*\$FreeBSD\$$\n/


# fbbd9655 28-Feb-2017 Warner Losh <imp@FreeBSD.org>

Renumber copyright clause 4

Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is

Renumber copyright clause 4

Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.

Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96

show more ...


# b888b86e 10-Oct-2014 Xin LI <delphij@FreeBSD.org>

accept(2) may and can return EAGAIN, document it.

MFC after: 1 week


# b83686c8 11-Jan-2014 Jilles Tjoelker <jilles@FreeBSD.org>

Add some missing .Nm for newer syscalls in existing man pages.

MFC after: 1 week


# 0f49c96c 01-Oct-2013 Jilles Tjoelker <jilles@FreeBSD.org>

accept(2): Update portability note for accept4().

The accept(2) man page warns that O_NONBLOCK and other properties on the
new socket may vary across implementations. However, this issue only
applie

accept(2): Update portability note for accept4().

The accept(2) man page warns that O_NONBLOCK and other properties on the
new socket may vary across implementations. However, this issue only
applies to accept() and not to accept4(). On the other hand, accept4()
is not commonly available yet.

Reported by: pluknet
Reviewed by: bjk
Approved by: re (kib)

show more ...


# ed5987bd 01-May-2013 Jilles Tjoelker <jilles@FreeBSD.org>

accept(2), pipe(2): Fix .Dd.


# da7d2afb 01-May-2013 Jilles Tjoelker <jilles@FreeBSD.org>

Add accept4() system call.

The accept4() function, compared to accept(), allows setting the new file
descriptor atomically close-on-exec and explicitly controlling the
non-blocking status on the new

Add accept4() system call.

The accept4() function, compared to accept(), allows setting the new file
descriptor atomically close-on-exec and explicitly controlling the
non-blocking status on the new socket. (Note that the latter point means
that accept() is not equivalent to any form of accept4().)

The linuxulator's accept4 implementation leaves a race window where the new
file descriptor is not close-on-exec because it calls sys_accept(). This
implementation leaves no such race window (by using falloc() flags). The
linuxulator could be fixed and simplified by using the new code.

Like accept(), accept4() is async-signal-safe, a cancellation point and
permitted in capability mode.

show more ...


# 89bbe149 22-Apr-2013 Sergey Kandaurov <pluknet@FreeBSD.org>

Keep up with negative addrlen check removal in r249649.


# de9dcfba 26-Mar-2013 Jilles Tjoelker <jilles@FreeBSD.org>

accept(2): Mention inheritance of O_ASYNC and signal destination.

While almost nobody uses O_ASYNC, and rightly so, the inheritance of the
related properties across accept() is a portability issue l

accept(2): Mention inheritance of O_ASYNC and signal destination.

While almost nobody uses O_ASYNC, and rightly so, the inheritance of the
related properties across accept() is a portability issue like the
inheritance of O_NONBLOCK.

show more ...


# 4054af4f 02-Nov-2009 Colin Percival <cperciva@FreeBSD.org>

Attempt to reduce accidental foot-shooting by pointing out that
accept(2)ed sockets do not necessarily inherit O_NONBLOCK from
listening sockets on non-FreeBSD platforms.

Feet shot: cperciva
MFC aft

Attempt to reduce accidental foot-shooting by pointing out that
accept(2)ed sockets do not necessarily inherit O_NONBLOCK from
listening sockets on non-FreeBSD platforms.

Feet shot: cperciva
MFC after: 1 month

show more ...


# 20067a68 20-Jun-2008 Poul-Henning Kamp <phk@FreeBSD.org>

Add Xr to getsockname(2)


# c879ae35 09-Jan-2007 Warner Losh <imp@FreeBSD.org>

Per Regents of the University of Calfornia letter, remove advertising
clause.

# If I've done so improperly on a file, please let me know.


# e3446e1f 04-May-2005 Giorgos Keramidas <keramida@FreeBSD.org>

Document the fact that accept(2) may return EINVAL when addrlen is
negative (in addition to returning EINVAL when called on a descriptor
that is not a socket).

Submitted by: Arne H Juul <arnej@europ

Document the fact that accept(2) may return EINVAL when addrlen is
negative (in addition to returning EINVAL when called on a descriptor
that is not a socket).

Submitted by: Arne H Juul <arnej@europe.yahoo-inc.com>
PR: docs/80587

show more ...


# 1a0a9345 02-Jul-2004 Ruslan Ermilov <ru@FreeBSD.org>

Mechanically kill hard sentence breaks.


# cb450d22 23-Jun-2004 Bruce M Simpson <bms@FreeBSD.org>

Be specific about which socket properties are inherited from the original
socket upon accept(2).

PR: docs/54995, kern/45733


# 7e2a61e1 24-Dec-2003 Alfred Perlstein <alfred@FreeBSD.org>

Add restrict qualifiers. (docs)

PR: 44394
Submitted by: Craig Rodrigues <rodrige@attbi.com>


# 8f4b894f 05-Sep-2003 Peter Pentchev <roam@FreeBSD.org>

Clarify that the second argument to accept() may be a null pointer if
no peer address information is desired.

PR: 56044
Submitted by: Felix Opatz <felix@zotteljedi.de> and
Bernd Luevelsmeyer <bdl

Clarify that the second argument to accept() may be a null pointer if
no peer address information is desired.

PR: 56044
Submitted by: Felix Opatz <felix@zotteljedi.de> and
Bernd Luevelsmeyer <bdluevel@heitec.net>
MFC after: 1 month

show more ...


# 2efeeba5 19-Dec-2002 Ruslan Ermilov <ru@FreeBSD.org>

mdoc(7) police: "The .Fa argument.".


# 2faeeff4 18-Dec-2002 Ruslan Ermilov <ru@FreeBSD.org>

mdoc(7) police: Tidy up the syscall language.

Stop calling system calls "function calls".

Use "The .Fn system call" a-la "The .Nm utility".

When referring to a non-BSD implementation in
the HISTOR

mdoc(7) police: Tidy up the syscall language.

Stop calling system calls "function calls".

Use "The .Fn system call" a-la "The .Nm utility".

When referring to a non-BSD implementation in
the HISTORY section, call syscall a function,
to be safe.

show more ...


# 3d6cab60 29-May-2002 Ruslan Ermilov <ru@FreeBSD.org>

mdoc(7) police: sort xrefs.


# 3a0b92ec 08-May-2002 Mike Silbersack <silby@FreeBSD.org>

Some updates to mention accept filters and how
listen queues work in a syncache world.

MFC after: 3 days


# cf1b88ff 07-Jan-2002 Dima Dorfman <dd@FreeBSD.org>

Nuke the paragraph that says "One can obtain user connection request
data without confirming the connection by issuing a recvmsg(2) [...]".
There's no such code in the kernel.

PR: 26861
Submitted b

Nuke the paragraph that says "One can obtain user connection request
data without confirming the connection by issuing a recvmsg(2) [...]".
There's no such code in the kernel.

PR: 26861
Submitted by: Richard A Steenbergen <ras@e-gerbil.net>,
Tom Rhodes <darklogik@pittgoth.com>

show more ...


12