minor patch for bgpd.conf man page
Found whilst paging down looking for something else... --- /usr/share/man/man5/bgpd.conf.5 Mon Feb 13 03:34:48 2012 +++ bgpd.conf.5 Tue Jun 19 16:52:55 2012 @@ -30,7 +30,7 @@ in RFC 4271. .Sh SECTIONS The .Nm -config file is divided into four main sections. +config file is divided into five main sections. .Bl -tag -width .It Sy Macros User-defined variables may be defined and used later, simplifying the OK? *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
compat_linux: Add socket type mask.
The newer glibc's, when creating a socket, add some higher bit flags to
the type argument that are used for debug, statistics, profiling
whatever. They are not useful and implementation specific.
This is needed for DNS resolving, otherwise the nss library from glibc
will always fail to do the right thing.
Tested on sample files cooked by my self system utilities from the
iputils rpm and opera. All of them didn't work before this diff and now
do.
Okay?
Index: linux_socket.c
===
RCS file: /cvs/src/sys/compat/linux/linux_socket.c,v
retrieving revision 1.44
diff -u -p -r1.44 linux_socket.c
--- linux_socket.c 22 Apr 2012 05:43:14 - 1.44
+++ linux_socket.c 19 Jun 2012 08:21:09 -
@@ -245,7 +245,7 @@ linux_socket(p, v, retval)
return error;
SCARG(bsa, protocol) = lsa.protocol;
- SCARG(bsa, type) = lsa.type;
+ SCARG(bsa, type) = lsa.type LINUX_SOCKET_TYPE_MASK;
SCARG(bsa, domain) = linux_to_bsd_domain(lsa.domain);
if (SCARG(bsa, domain) == -1)
return EINVAL;
Index: linux_socket.h
===
RCS file: /cvs/src/sys/compat/linux/linux_socket.h,v
retrieving revision 1.9
diff -u -p -r1.9 linux_socket.h
--- linux_socket.h 3 Dec 2011 12:38:30 - 1.9
+++ linux_socket.h 19 Jun 2012 08:21:09 -
@@ -120,6 +120,9 @@
#defineLINUX_MSG_WAITALL 0x100
#defineLINUX_MSG_NOSIGNAL 0x4000
+/* Mask out extra type-related options */
+#define LINUX_SOCKET_TYPE_MASK 0xf
+
struct linux_sockaddr {
unsigned short sa_family;
charsa_data[14];
compat_linux: Add dummies for epoll and eventfd.
Okay?
Index: linux_dummy.c
===
RCS file: /cvs/src/sys/compat/linux/linux_dummy.c,v
retrieving revision 1.19
diff -u -p -r1.19 linux_dummy.c
--- linux_dummy.c 14 Dec 2011 08:33:18 - 1.19
+++ linux_dummy.c 19 Jun 2012 08:28:42 -
@@ -112,6 +112,14 @@ DUMMY(setfsgid); /* #216 */
DUMMY(pivot_root); /* #217 */
DUMMY(mincore);/* #218 */
DUMMY(fadvise64); /* #250 */
+DUMMY(epoll_create); /* #254 */
+DUMMY(epoll_ctl); /* #255 */
+DUMMY(epoll_wait); /* #256 */
+DUMMY(epoll_pwait);/* #319 */
+DUMMY(eventfd);/* #323 */
+DUMMY(eventfd2); /* #328 */
+DUMMY(epoll_create1); /* #329 */
+
#define DUMMY_XATTR(s) \
int\
Index: syscalls.master
===
RCS file: /cvs/src/sys/compat/linux/syscalls.master,v
retrieving revision 1.69
diff -u -p -r1.69 syscalls.master
--- syscalls.master 8 Jun 2012 14:28:23 - 1.69
+++ syscalls.master 19 Jun 2012 08:28:42 -
@@ -400,9 +400,9 @@
251UNIMPL
252NOARGS linux_exit_group { int sys_exit(int rval); }
253UNIMPL linux_sys_lookup_dcookie
-254UNIMPL linux_sys_epoll_create
-255UNIMPL linux_sys_epoll_ctl
-256UNIMPL linux_sys_epoll_wait
+254NOARGS { int linux_sys_epoll_create(void); }
+255NOARGS { int linux_sys_epoll_ctl(void); }
+256NOARGS { int linux_sys_epoll_wait(void); }
257UNIMPL linux_sys_remap_file_pages
258STD { int linux_sys_set_tid_address(void *tidptr); }
259UNIMPL linux_sys_timer_create
@@ -472,17 +472,17 @@
316UNIMPL vmsplice
317UNIMPL move_pages
318UNIMPL getcpu
-319UNIMPL epoll_wait
+319NOARGS { int linux_sys_epoll_pwait(void); }
320UNIMPL utimensat
321UNIMPL signalfd
322UNIMPL timerfd_create
-323UNIMPL eventfd
+323NOARGS { int linux_sys_eventfd(void); }
324UNIMPL fallocate
325UNIMPL timerfd_settime
326UNIMPL timerfd_gettime
327UNIMPL signalfd4
-328UNIMPL eventfd2
-329UNIMPL epoll_create1
+328NOARGS { int linux_sys_eventfd2(void); }
+329NOARGS { int linux_sys_epoll_create1(void); }
330UNIMPL dup3
331STD { int linux_sys_pipe2(int *fdp, int flags); }
332UNIMPL inotify_init1
compat_linux: Implement tgkill
Needed for newer glibc, okay?
Index: linux_signal.c
===
RCS file: /cvs/src/sys/compat/linux/linux_signal.c,v
retrieving revision 1.14
diff -u -p -r1.14 linux_signal.c
--- linux_signal.c 9 Dec 2009 16:29:56 - 1.14
+++ linux_signal.c 19 Jun 2012 08:32:24 -
@@ -919,3 +919,28 @@ linux_sys_kill(p, v, retval)
SCARG(ka, signum) = linux_to_bsd_sig[SCARG(uap, signum)];
return (sys_kill(p, ka, retval));
}
+
+int
+linux_sys_tgkill(struct proc *p, void *v, register_t *retval)
+{
+ struct linux_sys_tgkill_args /* {
+ syscallarg(int) tgid;
+ syscallarg(int) tid;
+ syscallarg(int) sig;
+ }; */ *uap = v;
+
+ int error;
+ int sig;
+ struct sys_kill_args ka;
+
+ if (SCARG(uap, tgid) 0 || SCARG(uap, tid) 0)
+ return (EINVAL);
+
+ if ((error = linux_to_bsd_signal(SCARG(uap, sig), sig)))
+ return (error);
+
+ /* XXX: Ignoring tgid, behaving like the obsolete linux_sys_tkill */
+ SCARG(ka, pid) = SCARG(uap, tid);
+ SCARG(ka, signum) = sig;
+ return (sys_kill(p, ka, retval));
+}
Index: syscalls.master
===
RCS file: /cvs/src/sys/compat/linux/syscalls.master,v
retrieving revision 1.69
diff -u -p -r1.69 syscalls.master
--- syscalls.master 8 Jun 2012 14:28:23 - 1.69
+++ syscalls.master 19 Jun 2012 08:32:24 -
@@ -420,7 +420,7 @@
struct linux_statfs64 *sp); }
269STD { int linux_sys_fstatfs64(int fd, \
struct linux_statfs64 *sp); }
-270UNIMPL linux_sys_tgkill
+270STD { int linux_sys_tgkill(int tgid, int tid, int sig); }
271UNIMPL linux_sys_utimes
272UNIMPL linux_sys_fadvise64_64
273UNIMPL linux_sys_vserver
compat_linux: Add extra argument validation.
Make things more robust... Okay?
Index: linux_futex.c
===
RCS file: /cvs/src/sys/compat/linux/linux_futex.c,v
retrieving revision 1.4
diff -u -p -r1.4 linux_futex.c
--- linux_futex.c 19 Jun 2012 08:50:59 - 1.4
+++ linux_futex.c 19 Jun 2012 08:56:39 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: linux_futex.c,v 1.4 2012/06/19 08:50:59 pirofti Exp $ */
+/* $OpenBSD: linux_futex.c,v 1.1 2011/09/18 02:23:18 pirofti Exp $ */
/* $NetBSD: linux_futex.c,v 1.26 2010/07/07 01:30:35 chs Exp $ */
/*-
@@ -188,12 +188,17 @@ linux_do_futex(struct proc *p, const str
return EWOULDBLOCK;
}
- if ((error = futex_itimespecfix(ts)) != 0) {
- mtx_leave(futex_lock);
- return error;
+ /* Check for infinity */
+ if (ts-tv_sec == 0 ts-tv_nsec == 0) {
+ timeout_hz = 0;
+ } else {
+ if ((error = futex_itimespecfix(ts)) != 0) {
+ mtx_leave(futex_lock);
+ return error;
+ }
+ TIMESPEC_TO_TIMEVAL(tv, ts);
+ timeout_hz = tvtohz(tv);
}
- TIMESPEC_TO_TIMEVAL(tv, ts);
- timeout_hz = tvtohz(tv);
/*
* If the user process requests a non null timeout,
@@ -272,6 +277,15 @@ linux_do_futex(struct proc *p, const str
if (args_val 0)
return EINVAL;
+ /*
+* Don't allow using the same address for requeueing.
+*
+* glibc seems to cope with this.
+*/
+ if (SCARG(uap, uaddr) == SCARG(uap, uaddr2)) {
+ return EINVAL;
+ }
+
mtx_enter(futex_lock);
if ((error = copyin(SCARG(uap, uaddr),
uaddr_val, sizeof(uaddr_val))) != 0) {
@@ -294,6 +308,17 @@ linux_do_futex(struct proc *p, const str
f = futex_get(SCARG(uap, uaddr));
newf = futex_get(SCARG(uap, uaddr2));
+ /*
+* Check if uaddr2 is in use.
+* If true, return EINVAL to avoid deadlock.
+*
+* glibc seems to cope with this.
+*/
+ if (newf-f_refcount != 1) {
+ futex_put(f);
+ futex_put(newf);
+ return EINVAL;
+ }
*retval = futex_wake(f, args_val, newf,
(int)(unsigned long)SCARG(uap, timeout));
compat_linux: Fix msleep and wakeup calls.
Try to sleep on the actual data address and not on the stack address of
the pointer to the data. Avoids eternal sleep.
Okay?
Index: linux_futex.c
===
RCS file: /cvs/src/sys/compat/linux/linux_futex.c,v
retrieving revision 1.4
diff -u -p -r1.4 linux_futex.c
--- linux_futex.c 19 Jun 2012 08:50:59 - 1.4
+++ linux_futex.c 19 Jun 2012 09:03:44 -
@@ -474,7 +474,7 @@ futex_sleep(struct futex **fp, struct pr
requeue:
TAILQ_INSERT_TAIL(f-f_waiting_proc, wp, wp_list);
- ret = msleep(f, futex_lock, PUSER | PCATCH, futex_sleep, timeout);
+ ret = msleep(f, futex_lock, PUSER | PCATCH, futex_sleep, timeout);
TAILQ_REMOVE(f-f_waiting_proc, wp, wp_list);
@@ -508,7 +508,7 @@ futex_wake(struct futex *f, int n, struc
* note that sleeping threads are not in the process of requeueing.
*/
if (!TAILQ_EMPTY(f-f_waiting_proc))
- wakeup(f); /* only call wakeup once */
+ wakeup(f); /* only call wakeup once */
TAILQ_FOREACH(wp, f-f_waiting_proc, wp_list) {
KASSERT(wp-wp_new_futex == NULL);
compat_linux: Set appropiate retval on futex wait
Seems I forgot to set the return value after wakeup. Okay?
Index: linux_futex.c
===
RCS file: /cvs/src/sys/compat/linux/linux_futex.c,v
retrieving revision 1.4
diff -u -p -r1.4 linux_futex.c
--- linux_futex.c 19 Jun 2012 08:50:59 - 1.4
+++ linux_futex.c 19 Jun 2012 09:07:54 -
@@ -227,6 +227,7 @@ linux_do_futex(struct proc *p, const str
DPRINTF((FUTEX_WAIT %d: Woke up from uaddr %8.8X with
ret = %d\n, tid, SCARG(uap, uaddr), ret));
+ *retval = ret ? -1 : 0;
switch (ret) {
case EWOULDBLOCK: /* timeout */
return ETIMEDOUT;
compat_linux: Fix counting in futex_wake.
Count should always be zero no matter if we need to relocate or not.
Okay?
Index: linux_futex.c
===
RCS file: /cvs/src/sys/compat/linux/linux_futex.c,v
retrieving revision 1.4
diff -u -p -r1.4 linux_futex.c
--- linux_futex.c 19 Jun 2012 08:50:59 - 1.4
+++ linux_futex.c 19 Jun 2012 09:10:20 -
@@ -496,12 +496,10 @@ int
futex_wake(struct futex *f, int n, struct futex *newf, int n2)
{
struct waiting_proc *wp;
- int count;
+ int count = 0;
KASSERT(newf != f);
MUTEX_ASSERT_LOCKED(futex_lock);
-
- count = newf ? 0 : 1;
/*
* first, wake up any threads sleeping on this futex.
tweak libs to be -fpic
Some ports want to aggregate these into shared objects...
this tends to fail.
Any negative side-effect ?
Index: libl/Makefile
===
RCS file: /cvs/src/lib/libl/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- libl/Makefile 24 Nov 2005 20:49:18 - 1.4
+++ libl/Makefile 19 Jun 2012 09:39:47 -
@@ -5,6 +5,7 @@ LIB=l
WANTLINT=
SRCS= libmain.c libyywrap.c
NOPIC=
+CFLAGS += ${PICFLAG}
.PATH: ${.CURDIR}/../../usr.bin/lex
Index: libarch/amd64/Makefile
===
RCS file: /cvs/src/lib/libarch/amd64/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- libarch/amd64/Makefile 13 Apr 2011 02:49:12 - 1.10
+++ libarch/amd64/Makefile 19 Jun 2012 09:39:47 -
@@ -10,6 +10,7 @@ MLINKS+=amd64_get_ioperm.2 amd64_set_iop
.if ${MACHINE_ARCH} == amd64
.PATH: ${LIBC}/amd64
NOPIC=
+CFLAGS += ${PICFLAG}
SRCS+= amd64_iopl.c amd64_get_ioperm.c amd64_set_ioperm.c \
amd64_get_fsbase.c amd64_set_fsbase.c
.include bsd.lib.mk
Re: tweak libs to be -fpic
I suppose if people want screw themselves using multiple lex and run into trouble, it isn't our fault. Note that netbsd libc has yacc in it and oh boy, they've had a rough road there.
Re: compat_linux: Fix counting in futex_wake.
On Tue, Jun 19, 2012 at 12:13:09PM +0300, Paul Irofti wrote:
Count should always be zero no matter if we need to relocate or not.
Okay?
Makes sense to me (including the other diffs you sent which I didn't reply to
individually).
Index: linux_futex.c
===
RCS file: /cvs/src/sys/compat/linux/linux_futex.c,v
retrieving revision 1.4
diff -u -p -r1.4 linux_futex.c
--- linux_futex.c 19 Jun 2012 08:50:59 - 1.4
+++ linux_futex.c 19 Jun 2012 09:10:20 -
@@ -496,12 +496,10 @@ int
futex_wake(struct futex *f, int n, struct futex *newf, int n2)
{
struct waiting_proc *wp;
- int count;
+ int count = 0;
KASSERT(newf != f);
MUTEX_ASSERT_LOCKED(futex_lock);
-
- count = newf ? 0 : 1;
/*
* first, wake up any threads sleeping on this futex.
--
Cheers,
Jasper
Stay Hungry. Stay Foolish
Re: tweak libs to be -fpic
Some ports want to aggregate these into shared objects...
this tends to fail.
Any negative side-effect ?
I think this is a really bad idea. You're going to end up with multiple
copies of the code and you'll
never be quite sure what copy ends up being used. Especially dangerous
for dlopen()'ed stuff.
Turn it into a proper shared library instead.
Index: libl/Makefile
===
RCS file: /cvs/src/lib/libl/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- libl/Makefile24 Nov 2005 20:49:18 - 1.4
+++ libl/Makefile19 Jun 2012 09:39:47 -
@@ -5,6 +5,7 @@ LIB= l
WANTLINT=
SRCS= libmain.c libyywrap.c
NOPIC=
+CFLAGS += ${PICFLAG}
.PATH: ${.CURDIR}/../../usr.bin/lex
Index: libarch/amd64/Makefile
===
RCS file: /cvs/src/lib/libarch/amd64/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- libarch/amd64/Makefile 13 Apr 2011 02:49:12 - 1.10
+++ libarch/amd64/Makefile 19 Jun 2012 09:39:47 -
@@ -10,6 +10,7 @@ MLINKS+=amd64_get_ioperm.2 amd64_set_iop
.if ${MACHINE_ARCH} == amd64
.PATH: ${LIBC}/amd64
NOPIC=
+CFLAGS += ${PICFLAG}
SRCS+= amd64_iopl.c amd64_get_ioperm.c amd64_set_ioperm.c \
amd64_get_fsbase.c amd64_set_fsbase.c
.include bsd.lib.mk
Re: tweak libs to be -fpic
Oh whoops, I ok'd the previous!
Come on Marc, you know better. That won't work on the vax, which
has no PIC.
As Mark said, it has to be done properly.
Some ports want to aggregate these into shared objects...
this tends to fail.
Any negative side-effect ?
I think this is a really bad idea. You're going to end up with multiple
copies of the code and you'll
never be quite sure what copy ends up being used. Especially dangerous
for dlopen()'ed stuff.
Turn it into a proper shared library instead.
Index: libl/Makefile
===
RCS file: /cvs/src/lib/libl/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- libl/Makefile 24 Nov 2005 20:49:18 - 1.4
+++ libl/Makefile 19 Jun 2012 09:39:47 -
@@ -5,6 +5,7 @@ LIB= l
WANTLINT=
SRCS= libmain.c libyywrap.c
NOPIC=
+CFLAGS += ${PICFLAG}
.PATH:${.CURDIR}/../../usr.bin/lex
Index: libarch/amd64/Makefile
===
RCS file: /cvs/src/lib/libarch/amd64/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- libarch/amd64/Makefile 13 Apr 2011 02:49:12 - 1.10
+++ libarch/amd64/Makefile 19 Jun 2012 09:39:47 -
@@ -10,6 +10,7 @@ MLINKS+=amd64_get_ioperm.2 amd64_set_iop
.if ${MACHINE_ARCH} == amd64
.PATH: ${LIBC}/amd64
NOPIC=
+CFLAGS += ${PICFLAG}
SRCS+=amd64_iopl.c amd64_get_ioperm.c amd64_set_ioperm.c \
amd64_get_fsbase.c amd64_set_fsbase.c
.include bsd.lib.mk
Re: tweak libs to be -fpic
On Tue, Jun 19, 2012 at 08:45:18AM -0600, Theo de Raadt wrote:
Oh whoops, I ok'd the previous!
Come on Marc, you know better. That won't work on the vax, which
has no PIC.
LOL. I'm using PICFLAG, I'm hoping the vax has a define there.
I don't expect the corresponding software to work on the vax.
Especially the second lib, what was its name, oh right,
lib/arch/amd64.
As Mark said, it has to be done properly.
Some ports want to aggregate these into shared objects...
this tends to fail.
Any negative side-effect ?
I think this is a really bad idea. You're going to end up with multiple
copies of the code and you'll
never be quite sure what copy ends up being used. Especially dangerous
for dlopen()'ed stuff.
Turn it into a proper shared library instead.
Frankly, I don't expect those to turn up in triplicates. What I see here
is just an extra layer of build goo that will create a library that is just
part of a software that will most probably never include a second same thing
anywhere.
So, turning that into a shared library is really a non-issue. It's just build
goo.
I was really more thinking among the line: does compiling this as ${PICFLAG}
code has issues on any machine ? the only reason it matters is because
ld complains about relocations on amd64 if some code is pic and non-pic.
... and libtool (yeah right) would compile it as a real library on vax, so
the non-pic flag is not an issue there.
Alternately, I can just keep it broken, and wait until someone fixes the
affected ports while going insane (yeah, this is the kind of fucked-up
build infrastructure we're talking about, see my latest commit to
graphics/dcmtk, and the fact that libtool --version will say
libtool (not (GNU libtool) 1.26
just so that some fucked-up configure script won't say hey, that's libtol.
Oh that's not GNU libtool, so I'll just create a broken makefile...
So, hey, doing a shared library is totally equivalent to me.
I don't give a fuck as long as things work (it compiles, let's ship it, as
kili would say...)
You guys seem to have an actual opinion about it, just
tell me, the Makefile/shlib_version goo is equally trivial to write.
Re: [PATCH] uvideo(4): fix kernel crash when enumerating non-existant formats
On Mon, Jun 18, 2012 at 05:46:00PM +0200, Martin Pieuchot wrote: [...] Thanks. Out of curiosity with which application did you find this? [...] I tried playing around with my new webcam and used an uninitialized fmtdesc (mainly because I didn't understand the API then), which had a rather high index value (IIRC something around 2000). I was rather surprised when my little test program crashed my laptop repeatably :) -- Gregor Best [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Support for UCD-SNMP-MIB in snmpd (part one)
❦ 16 juin 2012 22:32 CEST, Seth Wright s...@crosse.org : Matthew's UCD-DISKIO-MIB patch got me interested in adding support for the UCD-SNMP-MIB in snmpd. Maybe it would be better to implement standard MIB like HOST-RESOURCES-MIB. -- Keep it simple to make it faster. - The Elements of Programming Style (Kernighan Plauger)
Re: Support for UCD-SNMP-MIB in snmpd (part one)
On Tue, Jun 19, 2012 at 1:35 PM, Vincent Bernat ber...@luffy.cx wrote: Maybe it would be better to implement standard MIB like HOST-RESOURCES-MIB. snmpd already supports HOST-RESOURCES-MIB. Seth, does your diff expose any new information that's not already available via snmpd? If not, I think we'd prefer to stick with standard MIBs where possible. I implemented UCD-DISKIO-MIB only because I couldn't find any existing MIB that was a good fit for disk IO stats. (Arguably it might go under the interface statistics since you can think of SCSI as just a specialized network protocol, but I wasn't sure if that would fly and UCD-DISKIO-MIB was less work.)
Re: Support for UCD-SNMP-MIB in snmpd (part one)
On Tue, Jun 19, 2012 at 4:35 PM, Vincent Bernat ber...@luffy.cx wrote: ❦ 16 juin 2012 22:32 CEST, Seth Wright s...@crosse.org : Matthew's UCD-DISKIO-MIB patch got me interested in adding support for the UCD-SNMP-MIB in snmpd. Maybe it would be better to implement standard MIB like HOST-RESOURCES-MIB. A lot of that MIB is already implemented, actually--maybe all? I haven't checked. This was more because the pretty graphs in Zenoss were blank for my two OpenBSD servers, and rather than change the data we polled for hundreds of machines (and lose all that historical data by changing graph points), I thought that instead I'd just implement the bits that we use. -- Seth
Re: compat_linux: Add socket type mask.
On Tue, Jun 19, 2012 at 1:26 AM, Paul Irofti p...@irofti.net wrote: The newer glibc's, when creating a socket, add some higher bit flags to the type argument that are used for debug, statistics, profiling whatever. They are not useful and implementation specific. Aren't those SOCK_CLOEXEC and SOCK_NONBLOCK? I would expect ignoring the former to result in rapid fd leaks, and ignoring of the latter to result in code blocking unexpectedly... Philip Guenther
Re: Support for UCD-SNMP-MIB in snmpd (part one)
On Tue, Jun 19, 2012 at 4:49 PM, Matthew Dempsky matt...@dempsky.org wrote: On Tue, Jun 19, 2012 at 1:35 PM, Vincent Bernat ber...@luffy.cx wrote: Maybe it would be better to implement standard MIB like HOST-RESOURCES-MIB. snmpd already supports HOST-RESOURCES-MIB. Seth, does your diff expose any new information that's not already available via snmpd? If not, I think we'd prefer to stick with standard MIBs where possible. I implemented UCD-DISKIO-MIB only because I couldn't find any existing MIB that was a good fit for disk IO stats. (Arguably it might go under the interface statistics since you can think of SCSI as just a specialized network protocol, but I wasn't sure if that would fly and UCD-DISKIO-MIB was less work.) I kind of thought the UCD-SNMP-MIB was fairly standard and/or widespread, but perhaps not? At any rate, it does add some value, I think. * HR-MIB includes hrProcessorLoad which is a percentage-based value for each CPU (if I'm reading the MIB right) for the one-minute timeframe. UCD-SNMP presents 1-, 5-, and 15-minute aggregate values, which may be more useful. * HR-MIB, under the hrStorage* attributes, includes free and used values for memory, but doesn't get any more granular than that. UCD-SNMP tries to break it down a bit further. * UCD-SNMP includes a bunch of CPU stats that I'm only starting to look at (the third blank graph in my monitoring templates) that I can't find in a walk against base snmpd. Those were going to be in diff number next. So yes, I think it does provide some value over what's already in there, but that's just the opinion of a guy scratching a proverbial itch.
Re: Support for UCD-SNMP-MIB in snmpd (part one)
[+joel] On Tue, Jun 19, 2012 at 2:11 PM, Seth Wright s...@crosse.org wrote: I kind of thought the UCD-SNMP-MIB was fairly standard and/or widespread, but perhaps not? HOST-RESOURCES-MIB is an RFC standard, which I assume gives it more stature than UCD-SNMP-MIB, but I honestly haven't used SNMP much in the last few years, so I'm not the best person to make a decision here. * HR-MIB includes hrProcessorLoad which is a percentage-based value for each CPU (if I'm reading the MIB right) for the one-minute timeframe. UCD-SNMP presents 1-, 5-, and 15-minute aggregate values, which may be more useful. I think you're referring to how UCD-SNMP-MIB exposes 1, 5, and 15 minute load averages, which are different from CPU utilization. In particular, it tends to be a common source of confusion among users because OpenBSD calculates load averages very differently than other operating systems (e.g., http://www.undeadly.org/cgi?action=articlesid=20090715034920mode=expanded). You should be able to calculate 5 and 15 minute rolling averages in your SNMP monitoring software too. * HR-MIB, under the hrStorage* attributes, includes free and used values for memory, but doesn't get any more granular than that. UCD-SNMP tries to break it down a bit further. That's valid, though I believe we could expose much more fine grained memory via HOST-RESOURCES-MIB too. E.g., buffer cache, kernel pool(9) and malloc(9) buckets, and so on. I'm not sure off hand if the memory groups in UCD-SNMP-MIB maps well to our VM system either, but I guess they all say they can be left out if the OS doesn't support the category. * UCD-SNMP includes a bunch of CPU stats that I'm only starting to look at (the third blank graph in my monitoring templates) that I can't find in a walk against base snmpd. Those were going to be in diff number next. These might be interesting, and it's data not exposed otherwise currently. The closest HOST-RESOURCES-MIB has is hrSWRunPerfCPU and hrSWRunPerfMem, but those don't track interrupt CPU usage. So yes, I think it does provide some value over what's already in there, but that's just the opinion of a guy scratching a proverbial itch. Understood, I'm just trying to make sure the diff makes sense to be committed.
