These are currently listed in order of uid because I went through
src/etc/group and src/etc/master.passwd line by line, and sorting any
other way after the fact -- like lexicographically, how it should be
-- was kinda inconvenient.
Feel free to sort, add information, add historical references,
correct any mistakes, &c., so that these remain living documents
describing NetBSD's standard users and groups and practices around
them.
It's been determined that it's too magical and it's either the job
of the bootloader or you compile it into the kernel yourself.
This entry works in /boot.cfg:
menu=Boot ZFS Root:load solaris;load zfs;fs /ramdisk-zfsroot.fs;boot
Rather than copying the needed modules from FFS to the ramdisk,
load then directly from FFS instead.
This way, we can symlink ramdisk stand into /altroot and let nature take
it's course like loading firmware.
Set shell exit on error rather than using chained commands.
zpool import seems to SIGBUS randomly on amd64 and if we didn't do the
former then zpool would hang the init. Now at least we exit to the shell.
Until we get ZFS integrated into our boot loader, this is the next best
thing. The idea is simple - have a small FFS partition with a kernel,
modules and this ramdisk. Once the ramdisk boots it will mount the FFS
partition read only, copy the needed ZFS modules to the ramdisk and then
unmount the partition. Then we import the ZFS root pool, mount the
ZFS root filesystem and then pivot to it.
Because the initial FFS partition is not mounted at this point, we
can mount it in /altroot so we can replace the kernel and modules with
newer ones so it's easily maintainable.
This ZFS boot strapper currently makes the following assumptions:
* The device NAME=boot is the FFS with kernel, modules and this ramdisk.
* The ZFS root pool and root filesystem are called rpool/ROOT.
A boot.cfg menu entry can then be added like so:
menu=Boot ZFS root:fs /ramdisk-zfsroot.fs;boot
91 passed test cases
0 failed test cases.
0 expected failed test cases.
62 skipped test cases.
There are many skipped tests, because the test itself supports full-
duplex, half-duplex and uni-directional devices but pad(4) used in ATF
tests is uni-directional device.
Background:
- All m68k ports have fixed PAGE_SIZE value in their kernels,
but each port uses different PAGE_SIZE value (4096 or 8192)
due to historical reasons.
- Currently module(7) binaries are built per each port so
all m68k kernel sources don't support run-time variable PAGE_SIZE.
- MI <uvm/uvm_param.h> assumes that the port supports a variable
PAGE_SIZE on module(7) builds if both MAX_PAGE_SIZE and MIN_PAGE_SIZE
are defined and they have different values.
- On the other hand, jemalloc(3) checks MAX_PAGE_SHIFT in
src/external/bsd/jemalloc/include/jemalloc/internal/jemalloc_internal_defs.h
for internal optimization.
- m68k ports share userland binaries (especially pkgsrc binaries)
among all ports, so we need to define MAX_PAGE_SHIFT as 13 to
support m68k ports where PAGE_SIZE==8192.
(though this would affect only if static binaries built on
4k page hosts are executed on 8k page hosts)
To solve these inconsistency on PAGE_SIZE definitions,
we should have an independent PAGE_SIZE related definitions
for userland, but it requires major reorganization.
For now (especially for netbsd-9) we define MAX/MIN PAGE_SIZE and
PAGE_SHIFT values in <m68k/vmparam.h> only in !defined(_KERNEL) case.
Discussed on source-changes-d@ and tech-kern@ with christos@ and thorpej@:
https://mail-index.netbsd.org/source-changes-d/2020/01/thread1.html#012035https://mail-index.netbsd.org/tech-kern/2020/01/thread1.html#025954
Should be pulled up to netbsd-9.
Associates a constructor and destructor with the percpu. Currently
the constructor runs immediately, but in principle we could use the
same API for future CPU hotplug support.
This lets you sleep for allocation or draining users before
deallocation when setting up or tearing down a percpu -- currently we
have many abuses of percpu_foreach in tree for that purpose.
Proposed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/01/30/msg026036.html
At this point it is highly unlikely this 1999 device still has users,
but it still comes up in the context of maxv's USB-fuzzing (and any device
could pretend to be a urio(4)), so it's best to get rid of it.
Renamed all major entries to obsolete, as was done in previous removals.
This still requires an update to sanitizers, but they're located in
"external", perhaps it should be first committed upstream?
Proposed on tech-kern a month ago.
stuff from the rest of the module. This allows loading of the
(main) compat_50 module on kernels that don't include ``options
QUOTA''.
Welcome to 9.99.40 !
Addresses PR kern/54875
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/01/13/msg025938.html
This was never (intentionally) enabled by default, and the design has
some shortcomings. You can get mostly the same results with ktrace,
as in usr.bin/make/filemon/filemon_ktrace.c which is now used instead
of filemon for make's meta mode.
If applications require higher performance than ktrace, or nesting
that ktrace doesn't support, we might consider adding something back
into the vfs system calls themselves, without hijacking the syscall
table. (Might want a more reliable output format too, e.g. one that
can handle newlines in file names.)
