tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: dtrace and ZFS update



On Fri, Oct 13, 2017 at 08:43:35PM +0000, maya%netbsd.org@localhost wrote:
> from before, cred seems messy

lots of things about this are messy...
the original solaris code already had hacks to build many files
both in a kernel environment and a userland environment,
and we've added a bunch of cross-OS compatibilty gunk on top.
I think the updated version of all that is a little less messy
than our existing version, but it's never going to be pretty.


>  #define	CRED()		(kauth_cred_get())
>  #define	kcred		cred0
> 
> elsewhere
> 
>  #define	kcred		NULL
>  #define	CRED()		NULL

the former are used for the kernel environment,
the latter are used for the userland environment.


> +uint64_t
> +kmem_size(void)
> +{
> +
> +	return (uint64_t)1 << 31;
> +}
> 
> That sounds like it might blow up on low memory

it turns out that this function is not used, I've removed it.


> You also have a duplicate definition now:
> 
> -#define	kmem_size()		(physmem * PAGESIZE)
> +#define	kmem_size()		((uint64_t)physmem * PAGESIZE)
> 
> +DTRACE_OPTS?=	-fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-ipa-sra -fno-ipa-icf
> 
> Make this conditional on DTrace?

yea, I mentioned in the mail that I needed to do something with that,
and conditionalizing it on MKDTRACE seems the most likely thing so far.
it's on my list of things I need to change before committing.


> +COPTS.dtrace.c += -Wno-format
> 
> Should probably fix those

none of those warnings indicate actual bugs, so I think it's more important to
minimize divergence from upstream than to quiet the warnings.
if people would rather not mask the warnings with -Wno-* that's ok with me,
but I really don't want to maintain a bunch of local changes that have little value.
I spent a lot of time dealing with all those local changes while I was merging
the new code and I don't want to have to spend that time all over again
for every update.

I can talk to the freebsd folks about fixing these warnings in their tree,
but I suspect they will refer me to their upstream (illumos or perhaps openzfs),
so it would be a bunch of work to make this code warning-free in a way that
doesn't create a bunch of ongoing work.

-Chuck


Home | Main Index | Thread Index | Old Index