Rename compiler-warning-disable variables from
GCC_NO_warning
to
CC_WNO_warning
where warning is the full warning name as used by the compiler.
GCC_NO_IMPLICIT_FALLTHRU is CC_WNO_IMPLICIT_FALLTHROUGH
Using the convention CC_compilerflag, where compilerflag
is based on the full compiler flag name.
GCC_NO_FORMAT_TRUNCATION -Wno-format-truncation (GCC 7/8)
GCC_NO_STRINGOP_TRUNCATION -Wno-stringop-truncation (GCC 8)
GCC_NO_STRINGOP_OVERFLOW -Wno-stringop-overflow (GCC 8)
GCC_NO_CAST_FUNCTION_TYPE -Wno-cast-function-type (GCC 8)
use these to turn off warnings for most GCC-8 complaints. many
of these are false positives, most of the real bugs are already
commited, or are yet to come.
we plan to introduce versions of (some?) of these that use the
"-Wno-error=" form, which still displays the warnings but does
not make it an error, and all of the above will be re-considered
as either being "fix me" (warning still displayed) or "warning
is wrong."
(e.g. umount_ffs, umount_nfs, etc.) exec it instead of calling
unmount(2).
Closes PR 698.
Note that the original plan for the PR also involved adding a generic
facility to store an alternate FS type name in the kernel to use when
unmounting. This was intended to support filesystems implemented as
loopback nfs servers, where the visible mount would be of type "nfs"
pointing at localhost; in that case one would want to be able to
provide an additional string in order to run an unmount program that
would both remove that mount and also shut down the loopback nfs
server daemon.
However, in the 21+ years since the PR was filed, loopback nfs servers
have gone out of favor (for good reasons) so I don't see any need to
worry about this case at present, especially since the PR has been
hanging around this long anyway. (If anyone still has a loopback nfs
server that they want to use a custom unmount program with, file a new
PR and assign it to me and I'll deal with it specifically in the nfs
mount args structure, which unmount already knows how to retrieve and
examine.)
It is my understanding that filesystems implemented with fuse (which
has displaced the loopback nfs server model) can already set the FS
type field so no further work is needed to allow them to use a custom
unmount program. If this is not the case, please let me know and I'll
attend to it.
There is no longer any need that I see to provide a general facility
for storing an alternate filesystem type name.
(One might also ask whether there's any real need for this
functionality at all any more; this is a fair question, but (a) the
change is small and (b) there are certainly cases when doing FS
research where you want a custom unmount program; been there & done
that.)
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.
e.g,
umount -a -t nonfs,mfs
This makes it clear that the "no prefix" only needs to be on the first
file-system argument to -t. The mount(8) man page has a clear example
of this but for some reason umount(8) was missing one.
Use this routine both in mount_fs and rump_fs to provide equivalent
command line parameters and therefore usage interchangeability.
While doing this, combine some common mountgoop to mountprog.h
systems just checked != 0, breaking MNT_GETARGS. Others worked with < 0,
but make them check against -1 too for consistency. And sprinkle some
stylish line wrapping where appropriate.
lukem