Date: Mon, 2 May 2011 09:10:58 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: freebsd-hackers@freebsd.org Subject: [PATCH] draft patch to make usr.bin/kdump WARNS?= 6 clean Message-ID: <BANLkTinR1qXERz9QJfneM4aKXhdLdz3ZtQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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
:).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTinR1qXERz9QJfneM4aKXhdLdz3ZtQ>