mirror of
https://sourceware.org/git/glibc.git
synced 2025-01-14 04:50:18 +00:00
ee768a30fe
POSIX.1-2024 (now official) specifies tm_gmtoff and tm_zone. This is a good time to update the manual’s “Date and Time” chapter so I went through it, fixed some outdated stuff that had been in there for decades, and improved it to match POSIX.1-2024 better and to clarify some implementation-defined behavior. Glibc already conforms to POSIX.1-2024 in these matters, so this is merely a documentation change. * manual/examples/strftim.c: Use snprintf instead of now-deprecated function asctime. Check for localtime failure. Simplify by using puts instead of fputs. Prefer ‘buf, sizeof buf’ to less-obvious ‘buffer, SIZE’. * manual/examples/timespec_subtract.c: Modernize to use struct timespec not struct timeval, and rename from timeval_subtract.c. All uses changed. Check for overflow. Do not check for negative return value, which ought to be OK since negative time_t is OK. Use GNU indenting style. * manual/time.texi: Document CLOCKS_PER_SEC, TIME_UTC, timespec_get, timespec_getres, strftime_l. Document the storage lifetime of tm_zone and of tzname. Caution against use of tzname, timezone and daylight, saying that these variables have unspecified values when TZ is geographic. This is what glibc actually does (contrary to what the manual said before this patch), and POSIX is planned to say the same thing <https://austingroupbugs.net/view.php?id=1816>. Also say that directly accessing the variables is not thread-safe. Say that localtime_r and ctime_r don’t necessarily set time zone state. Similarly, in the tzset documentation, say that it is called by ctime, localtime, mktime, strftime, not that it is called by all time conversion functions that depend on the time zone. Say that tm_isdst is useful mostly just for mktime, and that other uses should prefer tm_gmtoff and tm_zone instead. Do not say that strftime ignores tm_gmtoff and tm_zone, because it doesn’t do that. Document what gmtime does to tm_gmtoff and tm_zone. Say that the asctime, asctime_r, ctime, and ctime_r are now deprecated and/or obsolescent, and that behavior is undefined if the year is < 1000 or > 9999. Document strftime before these now-obsolescent functions, so that readers see the useful function first. Coin the terms “geographical format” and “proleptic format” for the two main formats of TZ settings, to simplify exposition. Use this wording consistently. Update top-level proleptic syntax to match POSIX.1-2024, which glibc already implements. Document the angle-bracket quoted forms of time zone abbreviations in proleptic TZ. Say that time zone abbreviations can contain only ASCII alphanumerics, ‘+’, and ‘-’. Document what happens if the proleptic form specifies a DST abbreviation and offset but omits the rules. POSIX says this is implementation-defined so we need to document it. Although this documentation mentions ‘posixrules’ tersely, we need to rethink ‘posixrules’ since I think it stops working after 2038. Clarify wording about TZ settings beginning with ‘;’. Say that timegm is in ISO C (as of C23). Say that POSIX.1-2024 removed gettimeofday. Say that tm_gmtoff and tm_zone are extensions to ISO C, which is clearer than saying they are invisible in a struct ISO C enviroment, and gives us more wiggle room if we want to make them visible in strict ISO C, something that ISO C allows. Drop mention of old standards like POSIX.1c and POSIX.2-1992 in the text when the history is so old that it’s no longer useful in a general-purpose manual. Define Coordinated Universal Time (UTC), time zone, time zone ruleset, and POSIX Epoch, and use these phrases more consistently. Improve TZ examples to show more variety, and to reflect current practice and timestamps. Remove obsolete example about Argentina. Add an example for Ireland. Don’t rely on GCC extensions when explaining ctime_r. Do not say that difftime produces the mathematically correct result, since it might be inexact. For clock_t don’t say “as in the example above” when there is no such example, and don’t say that casting to double works “properly and consistently no matter what”, as it suffers from rounding and overflow. Don’t say broken-down time is not useful for calculations; it’s merely painful. Say that UTC is not defined before 1960. Rename Time Zone Functions to Time Zone State. All uses changed. Update Internet RFC 822 → 5322, 1305 → 5905. Drop specific years of ISO 8601 as they don’t matter. Minor style changes: @code{"..."} → @t{"..."} to avoid overquoting in info files, @code → @env for environment variables, Daylight Saving Time → daylight saving time, white space → whitespace, prime meridian → Prime Meridian. |
||
---|---|---|
.. | ||
examples | ||
argp.texi | ||
arith.texi | ||
charset.texi | ||
check-safety.sh | ||
conf.texi | ||
contrib.texi | ||
creature.texi | ||
crypt.texi | ||
ctype.texi | ||
debug.texi | ||
dir | ||
dynlink.texi | ||
errno.texi | ||
fdl-1.3.texi | ||
filesys.texi | ||
freemanuals.texi | ||
getopt.texi | ||
header.texi | ||
install-plain.texi | ||
install.texi | ||
intro.texi | ||
io.texi | ||
ipc.texi | ||
job.texi | ||
lang.texi | ||
lgpl-2.1.texi | ||
libc-texinfo.sh | ||
libc.texinfo | ||
libcbook.texi | ||
llio.texi | ||
locale.texi | ||
macros.texi | ||
maint.texi | ||
Makefile | ||
math.texi | ||
memory.texi | ||
message.texi | ||
nss.texi | ||
nsswitch.texi | ||
pattern.texi | ||
pipe.texi | ||
platform.texi | ||
probes.texi | ||
process.texi | ||
README.pretty-printers | ||
README.tunables | ||
resource.texi | ||
search.texi | ||
setjmp.texi | ||
signal.texi | ||
socket.texi | ||
startup.texi | ||
stdbit.texi | ||
stdio-fp.c | ||
stdio.texi | ||
string.texi | ||
summary.pl | ||
sysinfo.texi | ||
syslog.texi | ||
terminal.texi | ||
texinfo.tex | ||
texis.awk | ||
threads.texi | ||
time.texi | ||
tsort.awk | ||
tunables.texi | ||
users.texi | ||
xtract-typefun.awk |
TUNABLE FRAMEWORK ================= Tunables is a feature in the GNU C Library that allows application authors and distribution maintainers to alter the runtime library behaviour to match their workload. The tunable framework allows modules within glibc to register variables that may be tweaked through an environment variable. It aims to enforce a strict namespace rule to bring consistency to naming of these tunable environment variables across the project. This document is a guide for glibc developers to add tunables to the framework. ADDING A NEW TUNABLE -------------------- The TOP_NAMESPACE macro is defined by default as 'glibc'. If distributions intend to add their own tunables, they should do so in a different top namespace by overriding the TOP_NAMESPACE macro for that tunable. Downstream implementations are discouraged from using the 'glibc' top namespace for tunables they don't already have consensus to push upstream. There are three steps to adding a tunable: 1. Add a tunable to the list and fully specify its properties: For each tunable you want to add, make an entry in elf/dl-tunables.list. The format of the file is as follows: TOP_NAMESPACE { NAMESPACE1 { TUNABLE1 { # tunable attributes, one per line } # A tunable with default attributes, i.e. string variable. TUNABLE2 TUNABLE3 { # its attributes } } NAMESPACE2 { ... } } The list of allowed attributes are: - type: Data type. Defaults to STRING. Allowed types are: INT_32, UINT_64, SIZE_T and STRING. Numeric types may be in octal or hexadecimal format too. - minval: Optional minimum acceptable value. For a string type this is the minimum length of the value. - maxval: Optional maximum acceptable value. For a string type this is the maximum length of the value. - default: Specify an optional default value for the tunable. - env_alias: An alias environment variable 2. Use TUNABLE_GET/TUNABLE_SET/TUNABLE_SET_WITH_BOUNDS to get and set tunables. 3. OPTIONAL: If tunables in a namespace are being used multiple times within a specific module, set the TUNABLE_NAMESPACE macro to reduce the amount of typing. GETTING AND SETTING TUNABLES ---------------------------- When the TUNABLE_NAMESPACE macro is defined, one may get tunables in that module using the TUNABLE_GET macro as follows: val = TUNABLE_GET (check, int32_t, TUNABLE_CALLBACK (check_callback)) where 'check' is the tunable name, 'int32_t' is the C type of the tunable and 'check_callback' is the function to call if the tunable got initialized to a non-default value. The macro returns the value as type 'int32_t'. The callback function should be defined as follows: void TUNABLE_CALLBACK (check_callback) (int32_t *valp) { ... } where it can expect the tunable value to be passed in VALP. Tunables in the module can be updated using: TUNABLE_SET (check, val) where 'check' is the tunable name and 'val' is a value of same type. To get and set tunables in a different namespace from that module, use the full form of the macros as follows: val = TUNABLE_GET_FULL (glibc, cpu, hwcap_mask, uint64_t, NULL) TUNABLE_SET_FULL (glibc, cpu, hwcap_mask, val) where 'glibc' is the top namespace, 'cpu' is the tunable namespace and the remaining arguments are the same as the short form macros. The minimum and maximum values can updated together with the tunable value using: TUNABLE_SET_WITH_BOUNDS (check, val, min, max) where 'check' is the tunable name, 'val' is a value of same type, 'min' and 'max' are the minimum and maximum values of the tunable. To set the minimum and maximum values of tunables in a different namespace from that module, use the full form of the macros as follows: val = TUNABLE_GET_FULL (glibc, cpu, hwcap_mask, uint64_t, NULL) TUNABLE_SET_WITH_BOUNDS_FULL (glibc, cpu, hwcap_mask, val, min, max) where 'glibc' is the top namespace, 'cpu' is the tunable namespace and the remaining arguments are the same as the short form macros. When TUNABLE_NAMESPACE is not defined in a module, TUNABLE_GET is equivalent to TUNABLE_GET_FULL, so you will need to provide full namespace information for both macros. Likewise for TUNABLE_SET, TUNABLE_SET_FULL, TUNABLE_SET_WITH_BOUNDS and TUNABLE_SET_WITH_BOUNDS_FULL. ** IMPORTANT NOTE ** The tunable list is set as read-only after the dynamic linker relocates itself, so setting tunable values must be limited only to tunables within the dynamic linker, that too before relocation. FUTURE WORK ----------- The framework currently only allows a one-time initialization of variables through environment variables and in some cases, modification of variables via an API call. A future goals for this project include: - Setting system-wide and user-wide defaults for tunables through some mechanism like a configuration file. - Allow tweaking of some tunables at runtime