Re: the pshared situation

> On Wed, Mar 19, 2014 at 3:40 PM, Ted Unangst wrote: > ... > > If we're going to do this, I think we need to do it the right way. > > > > 1. Export opaque storage types, as in > > typedef struct _sem_storage { > > char payload[64]; > > } sem_t; > > Then librthread will be able to add and

Re: the pshared situation

On Wed, Mar 19, 2014 at 3:40 PM, Ted Unangst wrote: ... > If we're going to do this, I think we need to do it the right way. > > 1. Export opaque storage types, as in > typedef struct _sem_storage { > char payload[64]; > } sem_t; > Then librthread will be able to add and shuffle fields ins

Re: dd gigabytes

Freebsd: If the number ends with a ``b'', ``k'', ``m'', ``g'', or ``w'', the number is multiplied by 512, 1024 (1K), 1048576 (1M), 1073741824 (1G) or the number of bytes in an integer, respectively. NetBSD: Where sizes are specified, a decimal number of bytes is expected. Two or more numbe

Re: dd gigabytes

GNU dd definitely has it (along with the wholly-expected proliferation of other useless units). It's definitely not called for by POSIX. IIRC, Solaris supports some units but not others. HPUX doesn't support any units at all. Don't know what other BSDs or AIX support. -Adam On March 23, 201

bcrypt base64

The base64 functions in bcrypt.c are a little special. They can't be easily converted to using the "normal" b64_pton functions because bcrypt doesn't support == padding. Here's a diff that does make a few improvements. Better function argument types. size_t, const where appropriate, and leave char

Re: Unbound in base, yes, what about ldns?

> I was waiting to be sure about this before adding an extra log socket in > the jail. > > Unbound opens /dev/log pre-chroot, so under normal conditions this is > not necessary, *however* if syslogd is restarted, the old socket is > no longer valid, so Unbound stops logging. > > So I think yes we

Re: dd gigabytes

Fine with me. dd is often used in portable scripts. Do we need to document this as an extension, or has it already arrived in other implimentations? > A gigabyte is like a megabyte, except it's bigger and better. > > This adds support for g/G suffixes. It also updates and corrects the > comment

Fix sendbug(1) link

Hi tech@ -- About a week and a half ago, this commit: http://marc.info/?l=openbsd-cvs&m=139452134505276&w=2 removed the query-pr.html page. sendbug(1) needs updating to reflect this, diff below. OK? ~Brian Index: sendbug.1 ===

Re: HEADS UP: librt revert

On Sun, Mar 23, 2014 at 05:05:06PM -0400, STeve Andre' wrote: > >If you've built a tree with librt, you want to > ># rm -f /usr/lib/librt.a > > Shouldn't that be librt*a to get rid of librt_p.a too? Thanks to tedu@ there's now rm -f /usr/lib/librt{,_p}.a in faq/current.html

dd gigabytes

A gigabyte is like a megabyte, except it's bigger and better. This adds support for g/G suffixes. It also updates and corrects the comments in the source. Also move the goto label out of the if. Index: args.c === RCS file: /cvs/src/b

Re: Unbound in base, yes, what about ldns?

moved from misc to tech On 2014/03/23 18:09, Chris Smith wrote: > On Thu, Mar 20, 2014 at 7:39 PM, Stuart Henderson > wrote: > > You can uninstall the package if you don't need it, or you can keep it > > if you do need it (for example, for drill or the ldns-* tools). > > How about this line add

Re: security(8): check for nobody in /etc/ftpusers

Hi Arto, Arto Jonsson wrote on Sun, Mar 23, 2014 at 08:09:02PM +0200: > Or should this check removed completely? Yes, and Gleydson Soares has Andrew's and my OK for removing check_ftpusers() completely. I don't think checking for "nobody" is needed. Hopefully, "nobody" will have no password set

Re: HEADS UP: librt revert

On Sun, Mar 23, 2014 at 05:05:06PM -0400, STeve Andre' wrote: > On 03/23/14 14:34, Marc Espie wrote: > >kili@ just committed a revert of the librt addition in src and corresponding > >patches in ports. > > > >If you've built a tree with librt, you want to > ># rm -f /usr/lib/librt.a > > Shouldn't

Re: HEADS UP: librt revert

On 03/23/14 14:34, Marc Espie wrote: kili@ just committed a revert of the librt addition in src and corresponding patches in ports. If you've built a tree with librt, you want to # rm -f /usr/lib/librt.a Shouldn't that be librt*a to get rid of librt_p.a too? --STeve Andre'

Re: remove ftpd/sshd libwrap support

With the exception of sshd (which I think need discussion) I suspect that all the wrapper call sequences could be purged from the tree.

remove ftpd/sshd libwrap support

This removes libwrap support from ftpd and sshd. Index: libexec/ftpd/Makefile === RCS file: /cvs/src/libexec/ftpd/Makefile,v retrieving revision 1.24 diff -u -p -r1.24 Makefile --- libexec/ftpd/Makefile 15 Jun 2005 16:13:27 -000

Re: to fault or not to fault

On Sun, Mar 23, 2014 at 20:10, Miod Vallat wrote: > Except that 1. this is ugly unless you express the values in hex, as > noone can spot these are multiples of 4096 in decimal, and 2. I think it > is more important to make clear that nback == nforw - 1 (or + 1 in the > SEQ case), regardless of th

Re: to fault or not to fault

> These calculations strike me as weird. Also, I think there's a bug. > nback should always be the -1 value, right? Oh, wait, it was like > that. Even stranger. I think the nback = 8 nforw = 7 was a bug, to begin with, but this diff attempts to first reach a status quo, for 4KB page size platforms

Re: to fault or not to fault

On Sun, Mar 23, 2014 at 19:45, Miod Vallat wrote: > The current logic is borrowed from FreeBSD, about 15 years ago, and goes > like this: > - for MADV_RANDOM areas, do not try to fault any other page. > - for MADV_NORMAL areas, try to fault the 3 preceding pages and the 4 > following pages. > - f

to fault or not to fault

Our vm system has some optimization logic which, when servicing a page fault, attempts to fault the neighbouring pages, if this is expected to speed things up on the long term. That logic is controlled by the madvise() state of the memory area being faulted in, with the defaults being that device

Re: HEADS UP: librt revert

On Sun, Mar 23, 2014 at 10:46:08PM +0400, Loganaden Velvindron wrote: > On Sun, Mar 23, 2014 at 10:34 PM, Marc Espie wrote: > > kili@ just committed a revert of the librt addition in src and > > corresponding > > patches in ports. > > > > If you've built a tree with librt, you want to > > # rm -

Re: HEADS UP: librt revert

On Sun, Mar 23, 2014 at 10:46 PM, Loganaden Velvindron wrote: > On Sun, Mar 23, 2014 at 10:34 PM, Marc Espie wrote: >> kili@ just committed a revert of the librt addition in src and corresponding >> patches in ports. >> >> If you've built a tree with librt, you want to >> # rm -f /usr/lib/librt.

Re: HEADS UP: librt revert

On Sun, Mar 23, 2014 at 10:34 PM, Marc Espie wrote: > kili@ just committed a revert of the librt addition in src and corresponding > patches in ports. > > If you've built a tree with librt, you want to > # rm -f /usr/lib/librt.a > > This lib was added to facilitate porting software, as posix asks

HEADS UP: librt revert

kili@ just committed a revert of the librt addition in src and corresponding patches in ports. If you've built a tree with librt, you want to # rm -f /usr/lib/librt.a This lib was added to facilitate porting software, as posix asks for it. but since it's only a stub, it was only added as a stati

security(8): check for nobody in /etc/ftpusers

Or should this check removed completely? Index: security === RCS file: /cvs/src/libexec/security/security,v retrieving revision 1.23 diff -u -p -r1.23 security --- security21 Mar 2013 09:37:37 - 1.23 +++ security23 Ma

print time_t with %lld in last(1)

Index: last.c === RCS file: /cvs/src/usr.bin/last/last.c,v retrieving revision 1.39 diff -u -p -r1.39 last.c --- last.c 22 Aug 2013 04:43:40 - 1.39 +++ last.c 27 Feb 2014 13:55:22 - @@ -266,8 +266,8 @@ wtmp(void)