On Mon, May 2, 2011 at 11:10 AM, Garrett Cooper <[email protected]> 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
