Re: Support for UCD-SNMP-MIB in snmpd (part one)
[+joel] On Tue, Jun 19, 2012 at 2:11 PM, Seth Wright 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=article&sid=20090715034920&mode=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.
Re: Support for UCD-SNMP-MIB in snmpd (part one)
On Tue, Jun 19, 2012 at 4:49 PM, Matthew Dempsky wrote: > On Tue, Jun 19, 2012 at 1:35 PM, Vincent Bernat 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: compat_linux: Add socket type mask.
On Tue, Jun 19, 2012 at 1:26 AM, Paul Irofti 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:35 PM, Vincent Bernat wrote: > ❦ 16 juin 2012 22:32 CEST, Seth Wright : > >> 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: Support for UCD-SNMP-MIB in snmpd (part one)
On Tue, Jun 19, 2012 at 1:35 PM, Vincent Bernat 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)
❦ 16 juin 2012 22:32 CEST, Seth Wright : > 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: tweak libs to be -fpic
> > 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. *MEEP* Same player shoot again. > Especially the second lib, what was its name, oh right, > lib/arch/amd64. And you mentioned libl initially; are there really use cases for a PIC libarch on amd64? If there are, why did you leave out i386 libarch?
Re: minor patch for bgpd.conf man page
On Tue, Jun 19, 2012 at 05:00:09PM +1000, Rod Whitworth wrote: > Found whilst paging down looking for something else... Funny, found that yesterday as well but had no time to commit it yet. > --- /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 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. > -- :wq Claudio
Re: tweak libs to be -fpic
So, here's the same diff with shlib glue. If you think that's slightly insane, blame bsd.lib.mk ! Note: for now, there's only arch/libamd64. I don't feel qualified to comment/test/do the other arches if need be. 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 17:19:25 - @@ -4,7 +4,6 @@ LIB= l WANTLINT= SRCS= libmain.c libyywrap.c -NOPIC= .PATH: ${.CURDIR}/../../usr.bin/lex @@ -13,6 +12,13 @@ NOPIC= LINKS= ${LIBDIR}/libl.a ${LIBDIR}/libfl.a .if !defined(NOPROFILE) LINKS+=${LIBDIR}/libl_p.a ${LIBDIR}/libfl_p.a +.endif + +.if !defined (NOPIC) +.if (${MACHINE_CPU} != "mips64") +LINKS+= ${LIBDIR}/libl_pic.a ${LIBDIR}/libfl_pic.a +.endif +LINKS+= ${LIBDIR}/libl.so.${SHLIB_MAJOR}.${SHLIB_MINOR} ${LIBDIR}/libfl.so.${SHLIB_MAJOR}.${SHLIB_MINOR} .endif .include Index: libl/shlib_version === RCS file: libl/shlib_version diff -N libl/shlib_version @@ -0,0 +1,3 @@ +# $OpenBSD$ +major=0 +minor=0 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 17:19:25 - @@ -9,7 +9,7 @@ MLINKS+=amd64_get_ioperm.2 amd64_set_iop .if ${MACHINE_ARCH} == "amd64" .PATH: ${LIBC}/amd64 -NOPIC= + SRCS+= amd64_iopl.c amd64_get_ioperm.c amd64_set_ioperm.c \ amd64_get_fsbase.c amd64_set_fsbase.c .include Index: libarch/amd64/shlib_version === RCS file: libarch/amd64/shlib_version diff -N libarch/amd64/shlib_version @@ -0,0 +1,3 @@ +# $OpenBSD$ +major=0 +minor=0
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: 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: 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
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
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
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.
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
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.
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 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: 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: 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 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: 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];
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 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.