There's no reason not to include <sys/param.h>. I'm a little reluctant to have it depend on the static MAXCPU definition, though. What happens when you mix-and match userland and kernel and they no longer agree on the definition of MAXCPU? I suggest creating a sysctl that exports the kernel's definition of MAXCPU, and have libmemstat look for that first, and fall back to using the static MAXCPU definition if the sysctl fails/doesn't exit. Scott On Sep 27, 2010, at 9:26 AM, Sean Bruno wrote: > Does this look like an appropriate modification to libmemstat? > > Sean > > > ==== //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4 > - /home/seanbru/ybsd_7/src/lib/libmemstat/memstat.h ==== > _at__at_ -28,12 +28,13 _at__at_ > > #ifndef _MEMSTAT_H_ > #define _MEMSTAT_H_ > +#include <sys/param.h> > > /* > * Number of CPU slots in library-internal data structures. This > should be > * at least the value of MAXCPU from param.h. > */ > -#define MEMSTAT_MAXCPU 64 > +#define MEMSTAT_MAXCPU MAXCPU /* defined in > sys/${ARCH}/include/param.h */ > > /* > * Amount of caller data to maintain for each caller data slot. > Applications > > > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Mon Sep 27 2010 - 14:00:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:07 UTC