> > MAP_HASSEMAPHORE is used in rthread_sem.c, but it doesn't do anything,
> > so I suspect it's just cargo culting based on man page misinformation?
> > Are there architectures that actually have restrictions on semaphore
> > memory?
>
> There architectures where atomic instructions only work on
> Stuart Henderson , 2014-06-27 11:00
>
> > +/* Stolen from ftp-proxy */
>
> Old version of ftp-proxy I guess. It hasn't used DIOCNATLOOK for several
> releases, it has switched to the much easier-to-use divert-to / getsockname().
And also :
> Henning Brauer , 2014-06-27 14:07
> noo
On Fri, Jun 27, 2014 at 02:46:01PM +0200, Mark Kettenis wrote:
> Losing the descriptions of the "no-op" flags is a bit unfortunate.
> Can you add those back?
Okay, restored them below. Also tested that kdump can handle this
change gracefully.
In this diff I've also moved MAP_FILE down to the leg
* Leclerc, Sebastien [2014-06-27 16:40]:
> + if (ioctl(pfdev, DIOCNATLOOK, &pnl) == -1)
no
DIOCNATLOOK is stupid. I'll celebrate the day when I can kill it.
Please look at less ancient ftp-proxy/*-proxy code for inspiration.
> De : Stuart Henderson [mailto:st...@openbsd.org]
>
> On 2014/06/27 09:58, Leclerc, Sebastien wrote:
> > Hi,
> >
> > Would this piece of code be useful to someone else than me?
>
> Not sure about base, but it may make sense to add to ports.
I'm not familiar with the creation of a port, but I'm
On 2014/06/27 09:58, Leclerc, Sebastien wrote:
> Hi,
>
> Would this piece of code be useful to someone else than me?
Not sure about base, but it may make sense to add to ports.
> +/* Stolen from ftp-proxy */
Old version of ftp-proxy I guess. It hasn't used DIOCNATLOOK for several
releases, it h
Hi,
Would this piece of code be useful to someone else than me?
It works with pf's divert-to to block some scanners. It's basically a
stripped-down spamd(8), that listens to every TCP connection that is
diverted to it, and sends the received data to the great bitbucket in
the sky, one byte per se
> Date: Thu, 26 Jun 2014 12:28:18 -0700
> From: Matthew Dempsky
>
> I just reviewed our mmap(2) flags to compare them against Linux,
> FreeBSD, Solaris, and Darwin's flags. Of the flags listed below, none
> of them are specified by POSIX, and none of them do anything
> interesting on OpenBSD: MA
Ted Unangst wrote:
> On Mon, Jun 09, 2014 at 21:54, Theo de Raadt wrote:
>>> > A better patch is probably the following which also increases the size
>>> > of the buffer to at least 64k:
>>>
>>> Agreed.
>>
>> One thing to be aware of. That function is syncronous. It will read
>> as much as it c
> Date: Thu, 26 Jun 2014 17:01:23 -0700
> From: Matthew Dempsky
>
> On Thu, Jun 26, 2014 at 12:28:18PM -0700, Matthew Dempsky wrote:
> > I just reviewed our mmap(2) flags to compare them against Linux,
> > FreeBSD, Solaris, and Darwin's flags. Of the flags listed below, none
> > of them are spec
Hi,
On Tue, 17 Jun 2014 12:48:24 +0900 (JST)
YASUOKA Masahiko wrote:
> On Mon, 16 Jun 2014 11:35:07 -0600
> Theo de Raadt wrote:
>>> > Followings are our kernel variables' default:
>>> >
>>> > - sb_max: 256K
>>> > - tcbhash_size: 128
>>> > - udbhash_size: 128
>>> >
>>> > These variables
2014-06-26 23:19 GMT+02:00, Stuart Henderson :
> On 2014/06/26 20:20, Christian Weisgerber wrote:
>> As everybody noticed, there was another problem. Please update to
>> cvsync-0.25.0pre0p0 for the latest bug fix. Sorry for all the
>> inconvenience.
>
> At least the following anoncvs mirrors have
12 matches
Mail list logo
