Re: [PATCH] [0/1] pf refactoring

Hi Mike, On Fri, 19 Aug 2016, Mike Belopuhov wrote: > I've looked through it and couldn't find anything wrong with it. Thanks. > I do however find pacthing of values in pf_translate_icmp_af > unneccessary since we'll be throwing away the original header > anyway. Do you mean e.g. circa line

Re: connect_sync

On Fri, 19 Aug 2016 19:14:54 -0400, "Ted Unangst" wrote: > hmm. so I was trying to avoid the need for two different functions. I think > there's a mental overhead to "do this, then maybe that". this loop reads > very strangely to me. it's hard to mentally trace the code. it's not really a > loop,

Re: connect_sync

Todd C. Miller wrote: > Here's a rewrite of my connect_sync() changes to use connect_wait() > instead. Unlike the version in the connect(2) manual, this one > returns EINTR when interrupted by a signal which is probably better. > Index: usr.bin/ftp/fetch.c >

Re: connect_sync

Here's a rewrite of my connect_sync() changes to use connect_wait() instead. Unlike the version in the connect(2) manual, this one returns EINTR when interrupted by a signal which is probably better. - todd Index: usr.bin/ftp/extern.h

Re: connect_sync

Another option is to use the connect_wait() function I added to EXAMPLES in connect(2). You would only call it if connect(2) returns -1 with errno == EINTR. - todd

connect_sync

connect_sync looks like it could be a useful piece of code in other places. however, putting the loop in the function means that ^C may not work... ftp has disgusting signal handlers and longjmps, but i don't think that's how we want other programs to be written. i've rewritten the function

Re: ld.so initarray support

> From: Philip Guenther > Date: Thu, 18 Aug 2016 21:09:10 -0700 > > On Thursday, August 18, 2016, Mark Kettenis wrote: > ... > > > > > > There is a functional change here. Our current ld.so doesn't run > > > > DT_INIT and DT_FINI for the main

Re: MP-safe L2 "lookup" w/o atomic operation

On Mon, Aug 15, 2016 at 01:52:46PM +0200, Martin Pieuchot wrote: > More tests, comments, ok are welcome. There is an issue with path mtu discovery that my regression test found, but i think that can be fixed with this diff in tree. > +/* > + * Invalidate the cached route entry of the gateway

XN bit support for armv7

The diff below makes the armv7 pmap use the XN (eXecure Never) bit. This bit makes pages non-executable, making OpenBSD/armv7 catch up with many of our architectures and provide this important security measure. The biggest change made by the diff is that pmap_protect() now also deals with setting

Re: [PATCH] [1/1] pf refactoring

On 19 August 2016 at 11:49, Richard Procter wrote: > > The final patch in the pf series. Will commit when I do the previous one > in around 24 hours unless there are objections. > > > - pushes the 'field changed' guards into the 'change field' functions. > This lets

Re: [PATCH] [0/1] pf refactoring

On 19 August 2016 at 11:33, Richard Procter wrote: > Hi, > > I've reduced the pf refactor (phase two) to two patches, which I'll be > committing in 24 hours or so unless there are any objections. > > I'm confident it won't, but supposing post-commit these have in >

Re: netinet6 free() diff

Hello - Regenerated diff against -current. Index: netinet6/frag6.c === RCS file: /cvs/src/sys/netinet6/frag6.c,v retrieving revision 1.67 diff -u -p -r1.67 frag6.c --- netinet6/frag6.c7 Mar 2016 18:44:00 - 1.67 +++

com@fdt simplification

Figuring out the clock frequency that is used for a com(4) device on armv7 is hard. If you're lucky, the device tree contains a "clock-frequency" property that gives you the answer. But if that property isn't there you're supposed to traverse the clock tree to find out the base frequency and

Re: man update after login.conf uses auto rounds

On Fri, Aug 19, 2016 at 11:12:02AM +0100, Stuart Henderson wrote: > On 2016/08/19 12:04, Daniel Jakots wrote: > > Hi, > > > > In June tedu@ committed [0] a diff to move login.conf to use auto > > rounds for bcrypt on amd64, sparc64, i386 and macppc. > > > > Here's a diff to update the man pages.

Re: man update after login.conf uses auto rounds

On 2016/08/19 12:04, Daniel Jakots wrote: > Hi, > > In June tedu@ committed [0] a diff to move login.conf to use auto > rounds for bcrypt on amd64, sparc64, i386 and macppc. > > Here's a diff to update the man pages. Currently the man pages are > outdated on these four architectures but I guess

man update after login.conf uses auto rounds

Hi, In June tedu@ committed [0] a diff to move login.conf to use auto rounds for bcrypt on amd64, sparc64, i386 and macppc. Here's a diff to update the man pages. Currently the man pages are outdated on these four architectures but I guess it's still right for other (old) architectures. After

[PATCH] [1/1] pf refactoring

The final patch in the pf series. Will commit when I do the previous one in around 24 hours unless there are objections. - pushes the 'field changed' guards into the 'change field' functions. This lets us normalise many of the existing guards and eliminate lots of code from pf_translate().

[PATCH] [0/1] pf refactoring

Hi, I've reduced the pf refactor (phase two) to two patches, which I'll be committing in 24 hours or so unless there are any objections. I'm confident it won't, but supposing post-commit these have in fact blown up, my first suspect would be the afto paths. This patch removes

Re: bpf(4), csignal() and selwakup()

On 16/08/16(Tue) 20:01, Philip Guenther wrote: > On Mon, 15 Aug 2016, Martin Pieuchot wrote: > > I'd like to make sure that bpf_tap(9) does not grab the KERNEL_LOCK(). > > The reason is to reduce the potential lock ordering problems within PF. > > > > I'm currently using a mutex to serialize

Re: MP-safe L2 "lookup" w/o atomic operation

On 15/08/16(Mon) 13:52, Martin Pieuchot wrote: > On 11/08/16(Thu) 16:04, Martin Pieuchot wrote: > > One of the remaining SMP issue with our routing table usage is to > > guarantee that the L2 entry referenced by a RTF_GATEWAY route via > > the ``rt_gwroute'' pointer wont be replaced/invalidated by

Re: dev/i2c: nxptda(4)

On Fri, Aug 19, 2016 at 02:38:32PM +1000, Jonathan Gray wrote: > > Perhaps even handle the modesetting ioctls and use the modesetting > driver with xorg? BTW, to add a kms drm driver for a simple framebuffer based graphics output, the code written duing GSoC 2015 by leo grange may be a good