different code path than using dlopen() before rump_init(), since
the former uses the in-kernel linker and the latter links the object
in rtld).
So:
golem> ./rump_server -l librumpvfs.so -m /sys/modules/tmpfs/tmpfs.kmod unix:///tmp/commsuck
==>
golem> env RUMP_SERVER=unix:///tmp/commsuck rump.modstat
NAME CLASS SOURCE REFS SIZE REQUIRES
suser secmodel builtin 0 - -
tmpfs vfs filesys 0 16713 -
wapbl vfs builtin 0 - -
Source is filesys instead of builtin, as expected.
Notably, for -m you *must* use -l librumpvfs.so. This is because
you need VFS in your kernel to be able to load modules from the
file system. In a regular kernel "librumpvfs.so" is linked at
kernel build time and loaded by the bootloader. Here we use dlopen()
for both effects (the other choices would have been to link
rump_server with -lrumpvfs, but that would limit the flexibility,
or link tmpfs.kmod directly into the binary, but that would limit
the flexibility even more).
and depending on file system data, can actually be a false error.
Fixes what I was actually testing for in bin/44209, though the
actual problem was not what I originally described.
copy appropriate data to where they are expected in the updated superblock.
When writing the updated superblock, move the updated values back to the
old ffsv1 superblock locations. Also check for old superblock format when
updating the last cylinder group and adjust cg_old_ncyl appropriately.
Derived from how mksf sets them. Should address PR bin/44209.
Fix multiple issues:
- Remove bogus 2038 check and add overflow checks in the appropriate places.
- Correct incomplete leap year calculation that broke things after 2100.
- Check localtime return values
- Change int calculations to time_t to avoid oveflow.
- Consistently check/return -1 and remove bogus comment about not being
able to return -1.
Now:
$ date -d 20991201
Tue Dec 1 00:00:00 EST 2099
$ date -d 40991201
Tue Dec 1 00:00:00 EST 4099
$ date -d 10000000991201
Tue Dec 1 00:00:00 EST 1000000099
TIME=0:04.48 CPU=117.8% (5.288u 0.000s) SWAPS=0 (0+95)pf (0i+0o) (0Kc+0Kd)
$ date -d 100000000991201
date: Cannot parse `100000000991201'
TIME=0:53.48 CPU=99.2% (53.086u 0.000s) SWAPS=0 (0+96)pf (0i+0o) (0Kc+0Kd)
Exit 1
