remains world-readable. Otherwise, it ends up with 600 permissions which
make it unusable for building pkgsrc packages as non-root.
Problem found by wiz@.
uint64_t usermem. This only becomes relevant if you have several TB of RAM.
Promoting cachebufs to uint64_t is not necessary as it gets limited to
(currently) 512 anyway.
fixes the last issue of PR: 19852
passwd.conf file to passwd.conf.pre-sysinst file and creating a new one
from scratch:
- This is consistent with all other edits of configuration files performed
by sysinst. (E.g. in-place changes of rc.conf.)
- This eases the upgrade of the system to a newer set of files because the
diffs presented by etcupdate are easier to read.
No objections in tech-install@. Tested installing NetBSD/amd64.
- posix_memalign() does not set errno, it returns 0 or an error number
(maybe a jemalloc() vs. phkmalloc() issue, but also how the opengroup
documents it.)
- since "align" must be >= sizeof(void *), expect to fail align=4 on
LP64 systems.
- while i'm here, add a test for align=2 failing everywhere.
msdosfs and cd9660 are the only filesystems that verify the filesystem
type in the label. This is the wrong place, sanity checks should only
rely on the inner structure of the filesystem (like signatures or
magic numbers).
msdosfs also used the device type information from the label to
deduce a filesystem parameter heuristically for the gemdos variant.
If there is no information inside the filesystem data itself, this
should be an explicit mount option.
* Apparently there is only a single location for the scripts. Thus, remove
the references to "/etc/powerd/scripts/apm" and "/etc/powerd/scripts/acpi".
* Correct confusion: instead of "the device with which the device is
associated", write "the device with which the event is associated".
Correct also an example related to this.
* Improve wording, grammar, and markup in few places.
to "(void)0". This is what similar code in bind9 (up to 9.5) does.
(native NetBSD code usually does "do { } while (/* CONSTCOND */ 0)"
in this case)
Anyway, I've checked the code, didn't find ambiguities due to
the empty statements, so the whole thing is harmless.
Use the limits_flags only for calls to the {get,set}_limits() callbacks
and merge the results into upropset, rather than trying to maintain both
values (error prone).
well have triggered the recursive panic.
Fix the comment for panic() to reflect now-current reality: the code
was already changed never to sync() on panic(), now we avoid dumping
core on a recursive panic.
