| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
introduced after OTP_R13B03.
|
|
|
|
Correct typo in logger formatter docs
|
|
* maint-21:
Updated OTP version
Prepare release
|
|
|
|
|
|
|
|
Forward set/update indicator to handler callback changing_config
OTP-15364
|
|
* igor/tcp-nopush-ERL-698/OTP-15357:
"cork" tcp socket around file:sendfile
Add nopush TCP socket option
|
|
RaimoNiskanen/raimo/getifaddrs-netns/ERIERL-189/OTP-15121
Implement {netns,NS} option for inet:getifaddrs/1 and friends
|
|
This translates to TCP_CORK on Linux and TCP_NOPUSH on
BSD.
In effect, this acts as super-Nagle: no partial TCP segments
are sent out until this option is turned off. Once turned off,
all accumulated unsent data is sent out immediately. The latter
is *not* the case on OSX, hence the implementation ignores
"nopush" on OSX to reduce confusion.
|
|
This function is called when a logger API function for fetching
handler configuration is called. The point is to allow the handler to
remove internal data fields that it might have stored in the
configuration database, before returning the handler configuration to
the caller.
An example of such internal data are the 'handler_pid' and 'mode_tab'
fields that logger_std_h and logger_disk_log_h store in their
configuration maps.
|
|
The new parameter to this function, SetOrUpdate, indicates how
unspecified configuration data fields shall be set. The rule is that
if SetOrUpdate equals set, then default values shall be used, and if
SetOrUpdate equals update, then existing configuration values shall be
used. Consequently, these examples now apply to logger_std_h and
logger_disk_log_h:
set_handler_config(default, config, #{sync_mode_qlen => 20}) sets the
value of sync_mode_qlen to 20, and resets all other (writable) fields
in the config map to their default values.
update_handler_config(default, config, #{sync_mode_qlen => 20}) sets
the value of sync_mode_qlen to 20, and leaves all other fields in the
config map unchanged.
|
|
This function is similar to set_handler_config/3, but calls the handler
callback changing_config/3 with the first parameter SetOrUpdate=update.
|
|
Also implement the same option for the legacy undocumented functions
inet:getif/1,getiflist/1,ifget/2,ifset/2.
The arity 1 functions had before this change got signatures that
took a socket port that was used to do the needed syscall, so now
the signature was extended to also take an option list with the
only supported option {netns,Namespace}. The Socket argument
variant remains unsupported.
For inet:getifaddrs/1 the documentation file was changed to old
style function name definition so be able to hide the Socket
argument variant that is visible in the type spec.
The arity 2 functions had got an option list as second argument.
This list had to be partitioned into one list for the namespace
option(s) and the other for the rest.
The namespace option list was then fed to the already existing
namespace support for socket opening, which places the socket
in a namespace and hence made all these functions that in
inet_drv.c used getsockopt() work without change.
The functions that used getifaddrs() in inet_drv.c had to be
changed in inet_drv.c to swap namespaces around the
getifaddrs() syscall. This functionality was separated into
a new function call_getifaddrs().
|
|
|
|
|
|
Since logger has now knowledge of the handler specific data ('config'
field in the handler configuration map), it can not merge this data
structure with default or old values upon configuration
change. Instead, the handler callback changing_config must do
this. Earlier, this callback did not reflect if the configuration
change was initiated by a call to set_handler_config or
update_handler_config, so the handler did not know if unspecified
fields should get default values or the values from the existing
configuration.
To overcome this problem, the new parameter SetOrUpdate is added to
this callback. If SetOrUpdate equals set, then default values should
be used. If SetOrUpdate equals update, then existing configuration
values should be used.
|
|
* raimo/receive-TOS-TCLASS/ERIERL-187/OTP-15145:
Elaborate the disclaimer for 'pktoptions'
Improve platform filter
Fix endianness bug for CMSG parsing
|
|
|
|
* raimo/receive-TOS-TCLASS/ERIERL-187/OTP-15145:
Write testcases for recvtos and friends
Fix term buffer overflow bug
Fix documentation due to feedback
Implement socket option recvtos and friends
|
|
If the report callback function has two arguments, the second argument
is a map with options to limit the size of the log event. To even
allow a better formatting when the event shall be printed on a single
line, the new option single_line is now included in this
argument.
|
|
|
|
|
|
The encoding option was introduced in commit
270d909696a753af022df72a404c73f2895b4a02, to allow report callbacks to
format according to a given encoding. There was, however, no
connection between this encoding option, and the encoding of the
device to which the logger handler was writing.
Since a formatter is defined to return unicode:chardata(), and in
order to avoid mismatch with the encoding of the device, the encoding
option is now removed from the formatter. The handler itself must make
sure that it does not write illegal data to its device.
|
|
* maint-21:
Updated OTP version
Update release notes
Update version numbers
kernel: Fix missing abort_connection in net_kernel
Prevent inconsistent node lists
Fix an endless rescheduling loop when a process is executing process_info(self(), ...)
|
|
|
|
Implement socket options recvtclass, recvtos, recvttl and pktoptions.
Document the implemented socket options, new types and message formats.
The options recvtclass, recvtos and recvttl are boolean options that
when activated (true) for a socket will cause ancillary data to be
received through recvmsg(). That is for packet oriented sockets
(UDP and SCTP).
The required options for this feature were recvtclass and recvtos,
and recvttl was only added to test that the ancillary data parsing
handled multiple data items in one message correctly.
These options does not work on Windows since ancillary data
is not handled by the Winsock2 API.
For stream sockets (TCP) there is no clear connection between
a received packet and what is returned when reading data from
the socket, so recvmsg() is not useful. It is possible to get
the same ancillary data through a getsockopt() call with
the IPv6 socket option IPV6_PKTOPTIONS, on Linux named
IPV6_2292PKTOPTIONS after the now obsoleted RFC where it originated.
(unfortunately RFC 3542 that obsoletes it explicitly undefines
this way to get packet ancillary data from a stream socket)
Linux also has got a way to get packet ancillary data for IPv4
TCP sockets through a getsockopt() call with IP_PKTOPTIONS,
which appears to be Linux specific.
This implementation uses a flag field in the inet_drv.c socket
internal data that records if any setsockopt() call with recvtclass,
recvtos or recvttl (IPV6_RECVTCLASS, IP_RECVTOS or IP_RECVTTL)
has been activated. If so recvmsg() is used instead of recvfrom().
Ancillary data is delivered to the application by a new return
tuple format from gen_udp:recv/2,3 containing a list of
ancillary data tuples [{tclass,TCLASS} | {tos,TOS} | {ttl,TTL}],
as returned by recvmsg(). For a socket in active mode a new
message format, containing the ancillary data list, delivers
the data in the same way.
For gen_sctp the ancillary data is delivered in the same way,
except that the gen_sctp return tuple format already contained
an ancillary data list so there are just more possible elements
when using these socket options. Note that the active mode
message format has got an extra tuple level for the ancillary
data compared to what is now implemented gen_udp.
The gen_sctp active mode format was considered to be the odd one
- now all tuples containing ancillary data are flat,
except for gen_sctp active mode.
Note that testing has not shown that Linux SCTP sockets deliver
any ancillary data for these socket options, so it is probably
not implemented yet. Remains to be seen what FreeBSD does...
For gen_tcp inet:getopts([pktoptions]) will deliver the latest
received ancillary data for any activated socket option recvtclass,
recvtos or recvttl, on platforms where IP_PKTOPTIONS is defined
for an IPv4 socket, or where IPV6_PKTOPTIONS or IPV6_2292PKTOPTIONS
is defined for an IPv6 socket. It will be delivered as a
list of ancillary data items in the same way as for gen_udp
(and gen_sctp).
On some platforms, e.g the BSD:s, when you activate IP_RECVTOS
you get ancillary data tagged IP_RECVTOS with the TOS value,
but on Linux you get ancillary data tagged IP_TOS with the
TOS value. Linux follows the style of RFC 2292, and the BSD:s
use an older notion. For RFC 2292 that defines the IP_PKTOPTIONS
socket option it is more logical to tag the items with the
tag that is the item's, than with the tag that defines that you
want the item. Therefore this implementation translates all
BSD style ancillary data tags to the corresponding Linux style
data tags, so the application will only see the tags 'tclass',
'tos' and 'ttl' on all platforms.
|
|
The doc says the default kernel logger_level is info, it should be notice.
Please refer to commit 0d52b992c30eff8604e5a5363510fea38c712263 for more info.
|
|
Add logger:set_application_level/2
|
|
When printing a map with ~p in a log message, the formatter's
single_line option in some cases introduced unwanted commas after
'=>', for example:
This is now corrected. When single_line==true, width 0 is added to all
~p and ~P control sequences in the format string.
|
|
Fix kernel_app doc logger_level defaults
|
|
* lukas/erts/fix_udp_realloc_bug:
erts: Limit the automatic max buffer for UDP to 2^16
erts: Free udp buffer when getting EAGAIN
|
|
There is no reason to have a larger buffer than this as
the recvmsg call will never return more data.
OTP-15206
|
|
* maint-20:
Updated OTP version
Prepare release
ssl: Engine key trumps certfile option
inets: Prepare for release
inets: Improve error handling
|
|
|
|
|
|
Fix typo in logger docs
|
|
* lukas/clean_doc_xmldir/OTP-15190:
docs: make clean all XMLDIR
|
|
OTP-15146
|
|
|
|
The doc says the default kernel logger_level is info, it should be notice.
```
% erl
Erlang/OTP 21 [erts-10.0.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe] [dtrace]
Eshell V10.0.3 (abort with ^G)
1> application:get_env(kernel,logger_level).
{ok,notice}
```
|
|
|
|
* siri/logger/post-21/OTP-15132:
[logger] Allow setting kernel parameter 'logger_level' to 'all'
[kernel] Reduce risk of dead lock when terminating logger_sup
[logger] Fix regexp replacement for unicode strings
Update proc_lib:report_cb to obey logger formatter's size limiting params
[logger] Allow report callback with two arguments returning a string
Don't call report_cb from cth_log_redirect - formatter does that
Add legacy test of sasl_report_file_h and size limiting
[logger] Remove compiler warnings in test
[logger] Fix problem with test cases waiting for handler restart
[logger] Add ?LOG macro which takes Level as argument
[logger] Improve spec for set_handler_config/3 and set_primary_config/2
[logger] Generate .png file from .dia
[logger] Update documentation
|
|
If the report callback is a fun of arity 2, then the second argument
is a map with the keys 'encoding', 'depth' and 'chars_limit', and the
fun must return a string which is size limited according to the given
depth and chars_limit.
If the report callback is a fun of arity 1, then it must return a
tuple containing a format string and a list of arguments. The
formatter will produce the string, and limit it's size.
|
|
|
|
Specify which keys and associated values are allowed.
|
|
|
