On Sat, 7 Nov 2015, Svatopluk Kraus wrote:

You broke buildkernel. The following patch helps:

diff --git a/sys/sys/sysctl.h b/sys/sys/sysctl.h
index 950e712..a34c890 100644
--- a/sys/sys/sysctl.h
+++ b/sys/sys/sysctl.h
@@ -37,6 +37,7 @@
#define _SYS_SYSCTL_H_

#include <sys/queue.h>
+#include <sys/stdint.h>

struct thread;
/*

This adds namespace pollution.  It shouldn't be needed.  <sys/stdint.h>
is standard namespace pollution in <sys/systm.h>.  (It has a bogus
comment there describing only one thing that it is for.)

This pollution is already in dnv.h, nv.h and racct.h.

@@ -949,7 +950,7 @@ extern char kern_ident[];
/* Dynamic oid handling */
struct sysctl_oid *sysctl_add_oid(struct sysctl_ctx_list *clist,
     struct sysctl_oid_list *parent, int nbr, const char *name, int kind,
-     void *arg1, intptr_t arg2, int (*handler)(SYSCTL_HANDLER_ARGS),
+     void *arg1, intmax_t arg2, int (*handler)(SYSCTL_HANDLER_ARGS),
     const char *fmt, const char *descr);
int sysctl_remove_name(struct sysctl_oid *parent, const char *name, int del,
     int recurse);

Apparently the original change wasn't tested on 32-bit arches.

I put intptr_t in <sys/types.h> long ago, since it was more needed and
less magic than intmax_t.  This was obfuscated by moving it to
<sys/_stdint.h> and including that in various places.  intmax_t is
still only in <sys/stdint.h> which is much larger.  It and uintmax_t
should be together with intptr_t.  That is more polluting in theory
but less in practice.

<sys/stdint.h> doesn't declare much else directly, but includes
<sys/_stdint.h> for the most important types (fixed-width ones).  It
mainly declares least-width and fast-width types directly.  These
should be used in most cases where fixed-width types are now used,
especially in kernels, but their usability is shown by them almost
never being used.

Bruce
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to