Add pieces of support for using both superblock types where
convenient, and specifically to the superblock accessors, but don't
actually enable it anywhere.
First substantive step on PR 50000.
in blocks instead of frags, so use lfs_blkstofrags to correct it.
This code was instead multiplying by the block size divided by
DEV_BSIZE to get the number of disk blocks rather than the number of
frags. (I gather that originally these were the same, but they're not
necessarily any more.)
If there are many enabled flags, ifconfig divides flags output into
multiple formatted strings due to snprintb_m, e.g.,
wm0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX>wm0: flags=8b43<MULTICAST> mtu 1500
This behavior is probably unexpected. The change always outputs enabled
flags at once like this:
wm0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
This contains all the accessor functions and macros out of lfs.h.
Add an include of lfs_accessors.h after all uses of lfs.h... except
for code that wants to define its own struct lfs-alike that the
accessors are supposed to play along with. For these, set STRUCT_LFS
and include lfs_accessors.h after the necessary structure has been
defined, so that lfs_accessors.h can emit functions in terms of it.
(This changes the rest of the code over; all the accessors were
already added.)
The difference between this commit and the previous one is arbitrary,
but the previous one passed the regression tests on its own so I'm
keeping it separate to help with any bisections that might be needed
in the future.
superblock. This will allow switching between 32/64 bit forms on the
fly; it will also allow handling LFS_EI reasonably tidily. (That
currently doesn't work on the superblock.)
It also gets rid of cpp abuse in the form of fake structure member
macros.
Also, instead of doing sleep/wakeup on &lfs_avail and &lfs_nextseg
inside the on-disk superblock, add extra elements to the in-memory
struct lfs for this. (XXX: these should be changed to condvars, but
not right now)
XXX: this migrates a structure needed by the lfs code in libsa (struct
salfs) into lfs.h, where it doesn't belong, but for the time being
this is necessary in order to allow the accessors (and the various
lfs macros and other goop that relies on them) to compile.
After that chanage, "MAXPARTITIONS" constant is not for the target port.
If host's MAXPARTITIONS is larger than a value of the target label and
target endianness is different from the build host, bswaplabel() could
overwrite data beyond the disklabel and primary boot stored after
LABELSECTOR in images might be corrupted.
This fixes boot failure of sun2 liveimage built by
"build.sh -U -m sun2 release live-image"
on TME.
Should be pulled up to netbsd-7.
Remove sync(2) call before unmount(2) in umount(8). This sync(2) is useless
since unmount(2) will perform a VFS_SYNC anyway.
But moreover, this sync(2) may be harmful, as there are some situation where
it cannot return (unreachable NFS server, for instance), causing umount -f
to be uneffective.
Coincidentally, the change also works around a gcc 5.1 bug which causes
a segmentation fault when trying to compile the longer version (guess
the compiler got exhausted, or something).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66345
resizedisk will adjust the media size in the headers, whereas
recover simply copies the existing header over the missing one.
XXX recover and resizedisk should probably be merged (even if just
partially, so that recover can properly handle media size changes).
Also, reading in the GPT should probably be centralised so that
error handling can be centralised, and users aren't given misleading
messages (i.e. they aren't told to run recover when they should be
running resizedisk). However, something that can be quickly pulled
up to netbsd-7 was needed, and there isn't time for a major overhaul
or rewrite.
Replace atoi(3) by strtol(3), and check that numbers are valid,
positive, and in int32_t range. The previous lack of check could
silently lead to the same serial being set to all RAID volumes
for instance because given numbers were bigger than INT_MAX. The
consequence is in an awful mess when RAIDframe would mix volumes...
