OMAP4/5 Wake-up generator driver

It turns out on OMAP4/OMAP5 there is a "Wake-up generator" interrupt controller that routes interrupts to the GIC and does power management comparable to imx with the i.MX6 General Power Controller (GPC). / { #address-cells = <0x0001>; #size-cells = <0x0001>; compatible =

Re: rebound quantum entanglement

BTW I'm not picking on you.. my DNS setup blew up this week for local resolution and I've been dealing with the fallout - so the topic is relatively near and dear to my heart. On Wed, Sep 14, 2016 at 10:07 PM, Bob Beck wrote: > > Yep. and now you need to solve the problem that

Re: rebound quantum entanglement

Yep. and now you need to solve the problem that when prepending 127.0.0.1, and hitting rebound, which in turn is going to only grab the first dns server from my resolv.conf instead of all of them, that it now doubles my failure time when the first dns server doesn't respond (once for libc asking

Re: regression tests and patch for calendar(1)

Thus said "Todd C. Miller" on Wed, 14 Sep 2016 10:04:58 -0600: > I've committed the fix as well as the calendar regress. Excellent. I've actually been working on a program that can be put into regress instead of the large number of files that currently exist for the expected output; it will

Re: rebound quantum entanglement

Ted Unangst wrote: > Bob Beck wrote: > > how is rebound going to handle a change in resolv.conf? thats still a > > problem here > > oh, that's easy. it watches the file for changes. i never quite got around to > that, but it's another five lines. ok, so it's a net +15 lines, including blanks.

Re: rebound quantum entanglement

Bob Beck wrote: > wont this also mean if it is not running i have to wait for the localhost > attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i > slow everything down for a timeout? you get back unreachable and move on. it's fast. you can try it. :)

Re: rebound quantum entanglement

> > wont this also mean if it is not running i have to wait for the localhost > > attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i > > slow everything down for a timeout? > > Not if he connects to the TCP port 53 instead of the UDP; it looks like > rebound binds to

Re: rebound quantum entanglement

On Wed, 14 Sep 2016 20:00:32 -0600, Bob Beck wrote: > wont this also mean if it is not running i have to wait for the localhost > attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i > slow everything down for a timeout? Not if he connects to the TCP port 53 instead of the

Re: rebound quantum entanglement

> wont this also mean if it is not running i have to wait for the localhost > attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i > slow everything down for a timeout? i think that is right. ktrace would show what is going on. if it stalls, this is not enough.

Re: rebound quantum entanglement

wont this also mean if it is not running i have to wait for the localhost attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i slow everything down for a timeout? dont get me wrong, it is an interesting direction, but I think maybe get the rest of the five line changes into

Re: rebound quantum entanglement

Bob Beck wrote: > how is rebound going to handle a change in resolv.conf? thats still a > problem here oh, that's easy. it watches the file for changes. i never quite got around to that, but it's another five lines.

Re: rebound quantum entanglement

how is rebound going to handle a change in resolv.conf? thats still a problem here On Wednesday, 14 September 2016, Ted Unangst wrote: > So the plan is for rebound to be the 'system' resolver, with libc talking > to > rbeound and rebound talking to the cloud. The main

rebound quantum entanglement

So the plan is for rebound to be the 'system' resolver, with libc talking to rbeound and rebound talking to the cloud. The main wrinkle is how does rebound find the cloud? rebound.conf, but dhclient doesn't know anything about rebound.conf, preferring to edit resolv.conf. But if rebound reads

video(1): Use read(2) to read file specified with -i

Hi, video(1) fails to read files that were previously recorded with -o somefile, unless -g (to select read(2) as the input method) is also specified: $ video -o foo ^C $ video -i foo video: ioctl VIDIOC_REQBUFS: Bad file descriptor $ video -g -i foo [ plays the file ]

Re: libsa, stop saving memory

On Wed, 14 Sep 2016 20:41:48 +0200, Jasper Lievisse Adriaanse wrote: > nothing defines SAVE_MEMORY nor has it been modified since -r1.1. > ok to zap it? OK millert@ - todd

libsa, stop saving memory

Hi, nothing defines SAVE_MEMORY nor has it been modified since -r1.1. ok to zap it? Index: cread.c === RCS file: /cvs/src/sys/lib/libsa/cread.c,v retrieving revision 1.13 diff -u -p -r1.13 cread.c --- cread.c 18 Jan 2009

ftp5.usa.openbsd.org going down 7pm-1am Sunday September 18th

Due to a just-announced power outage happening this Sunday night, ftp5.usa.openbsd.org will be going down around 7pm EDT (UTC-4) on Sunday September 14th. I will bring it back up when the power comes back at midnight EDT, so it should be back up by 1am EDT. FYI --Kurt Mosiejczuk

Re: random malloc junk

> Daniel Micay wrote: > > > > The current OpenBSD code only wipes up to MALLOC_MAXCHUNK with junk @ 1, > > and it similarly doesn't wipe at all with 'U' (even though junk-on-free > > also serves the purpose of preventing information leaks, not just > > mitigating use-after-free). IMO, optimizing

Re: random malloc junk

Daniel Micay wrote: > > The current OpenBSD code only wipes up to MALLOC_MAXCHUNK with junk @ 1, > and it similarly doesn't wipe at all with 'U' (even though junk-on-free > also serves the purpose of preventing information leaks, not just > mitigating use-after-free). IMO, optimizing large

Re: Remove ip6_pcbopts

On 14 September 2016 at 17:53, Jeremie Courreges-Anglas wrote: > > Dead since the IPV6_PKTOPTIONS socket option was removed. > > ok? > > Sure.

Re: regression tests and patch for calendar(1)

On 31 Aug 2016 07:52:19 -0600, "Andy Bradford" wrote: > While writing a set of regression tests for calendar(1) I discovered a > bug introduced by my last patch. The following patch fixes that and all > regression tests in the attachment of tests passes. I've committed the fix as well as the

Remove ip6_pcbopts

Dead since the IPV6_PKTOPTIONS socket option was removed. ok? Index: ip6_output.c === RCS file: /cvs/src/sys/netinet6/ip6_output.c,v retrieving revision 1.214 diff -u -p -r1.214 ip6_output.c --- ip6_output.c14 Sep 2016

Re: [PATCH] Callback-based interface to libtls

Hi On 14.09.2016, at 14:21, Brent Cook wrote: > > On 14.09.2016, at 13:37, Brent Cook wrote: > > > > > ​Once the expectations of the callbacks are finalized, this needs a good > > explanation in the manual.​ > > [...] > ​Generally, what are the

Re: regression tests and patch for calendar(1)

Hi Andy, I just ran into this regression and wrote a similar patch (though I missed the WEEKLY test). Thanks for the fix! It solves the Easter-calculation problem I noticed. For anyone looking for a quick test, none of the pre- or post-Easter dates will be displayed when executing: calendar -t

let openbgpd announce rtlabels

It is quite common to want to do a cross-protocol readvertisement from IGP->EGP. We can add rtlabels in bgpd and ospfd, but only advertise in ospfd. This diff lets bgpd announce routes based on rtlabels. The existing "cannot announce routes that point to localhost" and "cannot announce

Re: random malloc junk

On Tue, 2016-09-13 at 13:27 +0200, Otto Moerbeek wrote: > On Thu, Sep 08, 2016 at 06:42:33PM -0400, Daniel Micay wrote: > > > A bit off-topic: 'J' enables junk-on-init which is for debugging, > > but it > > also currently has security improvements for large allocations. > > There's > > only

teach BFD how to send route messages

This is a work-in-progress diff that I would like to commit. I can print a few things, but there is a problem when trying to bring in more fields. Printing is also ugly, but I can fix that in-tree. While here, I print the descr's as ints, the same way Juniper does it. I also had to add

Re: [PATCH] Callback-based interface to libtls

On Wed, Sep 14, 2016 at 6:41 AM, Tobias Pape wrote: > Hi > > On 14.09.2016, at 13:37, Brent Cook wrote: > > > > > ​Once the expectations of the callbacks are finalized, this needs a good > explanation in the manual.​ > > > Ok, how would I do that best? > I

Re: [PATCH] Callback-based interface to libtls

Hi On 14.09.2016, at 13:37, Brent Cook wrote: > > ​Once the expectations of the callbacks are finalized, this needs a good > explanation in the manual.​ Ok, how would I do that best? I admit to have amended the man page by sheer copy-and-paste-of-very-small-bits™, so

Re: [PATCH] Callback-based interface to libtls

​Thanks!​ On Wed, Sep 14, 2016 at 4:48 AM, wrote: > Hi again, > > On 07.09.2016, at 18:08, tob...@netshed.de wrote: > [..] > >> On 05.09.2016, at 15:50, bust...@gmail.com wrote: > >> > >>> Hey, the typedef came in handy :) Ok bcook@ > >>> > >>> On Sep 5, 2016, at 11:52 AM,

Re: [PATCH] Callback-based interface to libtls

Hi again, On 07.09.2016, at 18:08, tob...@netshed.de wrote: [..] >> On 05.09.2016, at 15:50, bust...@gmail.com wrote: >> >>> Hey, the typedef came in handy :) Ok bcook@ >>> >>> On Sep 5, 2016, at 11:52 AM, Bob Beck wrote: >>> I am in agreement in principle, but please

Re: STANDARDS in err.3

On Wed, Sep 14, 2016 at 12:32 AM, Michal Mazurek wrote: > Mention that these functions aren't standard. > > OK? Per mdoc(5): STANDARDS References any standards implemented or used. If not adhering to any standards, the HISTORY section should

STANDARDS in err.3

Mention that these functions aren't standard. OK? Index: lib/libc/gen/err.3 === RCS file: /cvs/src/lib/libc/gen/err.3,v retrieving revision 1.20 diff -u -p -r1.20 err.3 --- lib/libc/gen/err.3 23 Apr 2014 16:26:33 - 1.20

Re: m_copym2 is unused, let's remove it

On Wed, Sep 14, 2016 at 02:46:27PM +1000, David Gwynne wrote: > Yes, this is just a conservative first step to that. OK on the first step. I hope more follow :) > On 14 Sep 2016 12:00 p.m., "Todd C. Miller" > wrote: > > > Looks OK. Do you intend to change m_copym0