[PATCH] draft patch to make usr.bin/kdump WARNS?= 6 clean

Brandon Gooch jamesbrandongooch at gmail.com
Mon May 2 16:46:44 UTC 2011


On Mon, May 2, 2011 at 11:10 AM, Garrett Cooper <yanegomi at gmail.com> wrote:
>    I wanted to do something different this weekend, and I picked
> usr.bin/kdump as a likely 'victim' for converting from WARNS?= 0 to
> WARNS?= 6. I'm curious as to whether or not this is on the right
> track, but here's the reasoning I used:
>
> 1. Conditionally include diskmbr.h or diskpc98.h based on whether or
> not an architecture was non-pc98 or pc98 to avoid duplicate
> definitions, because the beforementioned headers are mutually
> exclusive.
> 2. Move the sockfamilyname declaration to kdump_subr.h as it's used in
> the generated ioctl.c file.
> 3. Fix a signed vs unsigned comparison with a simple cast because the
> size_t value will be sufficiently small that it can be converted to a
> signed comparison.
> 4. Fix a cast assignment type source//dest value alignment issue on
> ia64 assigning a struct sockaddr value to either struct sockaddr_in or
> struct sockaddr_in6 by using calloc and memcpy.
> 5. Fix structure alignment issues on arm by marking some structures as __packed.
> 6. Fix a shadowed declaration for flags by renaming a locally scoped
> variable to _flags; add appropriate type to field.
> 7. Remove unused argument to ktruser_malloc.
> 8. Add missing declarations for ktruser_malloc and ktruser_rtld.
>
>    I've run some basic tests and things seem sane (in particular
> ktrace'ing ktrace :)... ktrace'ing 'ssh ::1' and ktrace'ing 'ssh
> localhost', but I was wondering if there was anything I was missing or
> if someone else who ran arm or ia64 could test this patch out for me.
>    I've run make universe on amd64, i386, ia64, mips, and pc98, and
> things seem sane, but I can't play around with those machines to
> determine whether or not they're functional at runtime with the above
> changes.
> Thanks!
> -Garrett
>
> PS Oh yeah... no commit bit means that I can't commit this either, but
> I was curious if my approach was correct before getting to that step
> :).

Cool, but where's the patch for review?

-Brandon


More information about the freebsd-hackers mailing list