ZFS expects a null-terminated name.
Always create a copy with PNBUF_GET()/strlcpy()/PNBUF_PUT().
For LOOKUP use a small buffer on stack and allocate/free compomnent names
longer than 30 chars.
further dmu_tx_assign() fails because over quota or no space.
Use the emulated uiocopy() and uioskip() like illumos does.
Fix the uiocopy() emulation to not clobber the iovecs.
Use user flag UF_NODUMP instead of UF_IMMUTABLE for the test as it
is the only user flag supported by all tested file systems.
PR kern/47656 test zfs_flags.
It turns out this code always sees __HAVE_MM_MD_DIRECT_MAPPED_PHYS as
disabled on amd64, for reasons that I shall address forthwith, but it
is enabled on aarch64 and so the MKZFS=yes build breaks.
As it happens, on x86 both _HARDKERNEL and _KERNEL get defined; see
the conditional in sys/rump/Makefile.rump that _refrains_ from
defining _RUMPKERNEL on x86.
So the only version of this code that has been tested is the one with
all of it included. But on, e.g., aarch64, we do not get _HARDKERNEL
here, and the code fails to build because some things use the field
struct spa::spa_deadman_cycid under _KERNEL when it is declared only
under _HARDKERNEL.
If there's a reason _not_ to use this in rump -- and it's not obvious
to me why -- then all access to the field needs to agree to use
_HARDKERNEL.
Rather than write out a table for each architecture, rely on the C
compiler to define _LP64 for 64-bit ones, on the assumption that
anything not LP64 is ILP32, and on CTASSERTs to verify this
assumption so that if it's wrong it'll fail safely with a noisy build
failure.
Gives zfs half a chance of building on, e.g., powerpc.
These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.
HOWEVER! Some subsystems have
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))
even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.
To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.
I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:
cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))
It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.
Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)
Comment here already says it isn't necessary and will be removed.
Hasten the process for us and avoid the problematic typedef.
This is useful because u_longlong_t would otherwise need to be
provided by compat headers.
Mark arguments to dtrace_probe_lookup() with __UNCONST().
The proper fix constifying it causes pollution of const in too many files.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Constify char* types when initialized with liternals.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
hannken