Re: signify(1): make comments optional

Hi Ivan. Think I know who you are, and can guess why. This seems misguided. We have a horrible program called "file", but in general people identify what a file is what what purpose it serves not just by the filename, but also by how it starts. The "untrusted comment" has become the way to

[PATCH] openssh/manual.html - drop "query" from sshd manual page link

Hi all, As the title says - bring the link in line with the others. Regards, Raf Index: openssh/manual.html === RCS file: /cvs/www/openssh/manual.html,v retrieving revision 1.38 diff -u -p -r1.38 manual.html ---

signify(1): make comments optional

At the moment signify(1) requires sigfiles to begin with 'untrusted comment: '. Sometimes one wants to have no comments and just signature itself. Index: signify.c === RCS file: /cvs/src/usr.bin/signify/signify.c,v retrieving

Re: add in6 multicast support to vxlan(4) ; question on mbufs

On Fri, Oct 07, 2016 at 20:48 +1000, David Gwynne wrote: > On Thu, Oct 06, 2016 at 12:13:20PM +0200, Mike Belopuhov wrote: > > m_pullup will always get a new mbuf and on > > strict alignment architectures you will always do a m_dup_pkt > > (verified by my -DTEST1). > > i didnt think m_pullup was

acpiec on acer aspire S7 with CURRENT

Hi tech, while trying the latest snapshot I've noticed that the following warning is printed to a console several times a second (this does not happen in 6.0): acpi0: WARNING EC not initialized The investigation shows that the acpiec initialization fails in acpiec.c line 484: if (size != 2 ||

relayd(8): proc.c sync and remove fd limit change

This diff brings the relayd(8) proc.c up-to-date and removes the file limit alteration in relayd.c. The file limit alteration is not needed anymore since now the number of descriptors pre-allocated is very small (only one descriptor per child + 2 to distribute fds between child). It would be nice

bgpd draft-ietf-idr-large-community

Here is an initial implementation of draft-ietf-idr-large-community for OpenBGPD. I can connect and exchange routes with these attributes against exabgp. Normal communities are two 16bit numbers. With the addition of 32bit ASNs, those will not work if you wish to control one of them. Large

Re: rcctl ls - services and daemons

On Mon, Oct 10, 2016 at 06:43:05PM +0200, Jan Stary wrote: > The rcctl(8) manpage makes the distinction between 'daemons' and 'services', > and the description of some items in the output of 'rcctl ls' > mentions only 'daemons'. But they are both 'services and deamons' > in all cases (tested with

Re: Do not use rn_refines in if.c

On Mon, Oct 10, 2016 at 08:15:19PM +0200, Claudio Jeker wrote: > So rn_refines() is a function from the deep underbelly of radix code. > In my opinion if.c should not use this function especially now that we use > art for routing table lookups. Instead I implemented a simple > ifa_netmask_cmp()

remove pathnames.h from mv(1)

With the embedded cp.c and rm.c, the pathnames of "/bin/cp" and "/bin/rm" are not needed. Jan

Re: newlines in unexpand(1)

On Oct 10 15:22:01, t...@tedunangst.com wrote: > Jan Stary wrote: > > Why do we need to trim the newlines in unexpand(1)? > > The result seems to be the same without it. > > > > Jan > > > > > > Index: unexpand.c > > === > > RCS

remove unused flags from the cp.c inside mv(1)

The embedded cpmain() will never have _any_ flags set, as mv.c calls it as argv[0] = from; argv[1] = to; argv[2] = NULL; cpmain(2, argv); There is probably more code that could be romoved form the embedded cp.c, along the lines of tedu's recent cleanup of the

Re: let globals be global in unexpand(1)

On Oct 10 15:30:52, t...@tedunangst.com wrote: > Jan Stary wrote: > > In unexpand.c, the -a indicator is > > both a global int and a local char. > > I think this is backwards. We want fewer globals, not more. OK, other way round. Jan Index: unexpand.c

Re: let globals be global in unexpand(1)

Jan Stary wrote: > In unexpand.c, the -a indicator is > both a global int and a local char. I think this is backwards. We want fewer globals, not more.

Re: Do not use rn_refines in if.c

On 10 October 2016 at 20:15, Claudio Jeker wrote: > So rn_refines() is a function from the deep underbelly of radix code. > In my opinion if.c should not use this function especially now that we use > art for routing table lookups. Instead I implemented a simple >

Re: newlines in unexpand(1)

Jan Stary wrote: > Why do we need to trim the newlines in unexpand(1)? > The result seems to be the same without it. > > Jan > > > Index: unexpand.c > === > RCS file: /cvs/src/usr.bin/unexpand/unexpand.c,v > retrieving

let globals be global in unexpand(1)

In unexpand.c, the -a indicator is both a global int and a local char. Jan Index: unexpand.c === RCS file: /cvs/src/usr.bin/unexpand/unexpand.c,v retrieving revision 1.12 diff -u -p -r1.12 unexpand.c --- unexpand.c 11 Nov

Re: httpd(8)/proc.c: use less fds on startup

> Am 10.10.2016 um 18:47 schrieb Rafael Zalamena : > >> On Mon, Oct 10, 2016 at 12:32:49PM +0200, Reyk Floeter wrote: >>> On Tue, Oct 04, 2016 at 11:54:37PM +0200, Rafael Zalamena wrote: On Tue, Oct 04, 2016 at 07:46:52PM +0200, Rafael Zalamena wrote: This diff

newlines in unexpand(1)

Why do we need to trim the newlines in unexpand(1)? The result seems to be the same without it. Jan Index: unexpand.c === RCS file: /cvs/src/usr.bin/unexpand/unexpand.c,v retrieving revision 1.12 diff -u -p -r1.12

ddb: implement x /m

As far as I can tell, ddb's examine /m format /mdisplay in unsigned hex with character dump at the end of each line. The location is also displayed in hex at the beginning of each line. has been documented since the start of the

Do not use rn_refines in if.c

So rn_refines() is a function from the deep underbelly of radix code. In my opinion if.c should not use this function especially now that we use art for routing table lookups. Instead I implemented a simple ifa_netmask_cmp() function that does what the code expects and compares the two netmasks.

Re: rm.c functions in mv(1)

Jan Stary wrote: > bin/mv has its own copies of cp.c and mv.c. > Apparently, they are modifications of cp's cp.c and rm's rm.c, > used when moving as "copy and remove the source". > > In bin/mv/rm.c, the following snippet of rm_file() confuses me: > > if (S_ISDIR(sb.st_mode)) { >

Re: httpd(8)/proc.c: use less fds on startup

On Mon, Oct 10, 2016 at 12:32:49PM +0200, Reyk Floeter wrote: > On Tue, Oct 04, 2016 at 11:54:37PM +0200, Rafael Zalamena wrote: > > On Tue, Oct 04, 2016 at 07:46:52PM +0200, Rafael Zalamena wrote: > > > This diff makes proc.c daemons to use less file descriptors on startup, > > > this way we

rcctl ls - services and daemons

The rcctl(8) manpage makes the distinction between 'daemons' and 'services', and the description of some items in the output of 'rcctl ls' mentions only 'daemons'. But they are both 'services and deamons' in all cases (tested with e.g. postgresql running, stopped, or failed). Jan Index:

Re: rm.c functions in mv(1)

On Oct 10 12:25:39, h...@stare.cz wrote: > bin/mv has its own copies of cp.c and mv.c. > Apparently, they are modifications of cp's cp.c and rm's rm.c, > used when moving as "copy and remove the source". > > In bin/mv/rm.c, the following snippet of rm_file() confuses me: > > if

Re: tweek rcctl.8 spacing

Hi, Jan Stary wrote on Mon, Oct 10, 2016 at 02:22:57PM +0200: > The postscript output of 'man -Tps rcctl' makes the 'stopped' > list item of 'rcctl ls' break a line, while all the other items > are compact one-liners. The diff below changes the width, > which is the same for ascci, but "stopped"

Re: tweek rcctl.8 spacing

> > The postscript output of 'man -Tps rcctl' makes the 'stopped' > > list item of 'rcctl ls' break a line, while all the other items > > are compact one-liners. The diff below changes the width, > > which is the same for ascci, but "stopped" is slightly wider > > than "started" in the postscript

Re: tweek rcctl.8 spacing

Hi, Jan Stary wrote on Mon, Oct 10, 2016 at 02:22:57PM +0200: > The postscript output of 'man -Tps rcctl' makes the 'stopped' > list item of 'rcctl ls' break a line, while all the other items > are compact one-liners. The diff below changes the width, > which is the same for ascci, but "stopped"

tweek rcctl.8 spacing

The postscript output of 'man -Tps rcctl' makes the 'stopped' list item of 'rcctl ls' break a line, while all the other items are compact one-liners. The diff below changes the width, which is the same for ascci, but "stopped" is slightly wider than "started" in the postscript output. Jan

Re: rework xenocara make includes step

On Sun, Oct 09, 2016 at 09:21:48PM +0200, Martin Natano wrote: > On Sun, Oct 09, 2016 at 02:32:12PM +0200, Matthieu Herrb wrote: > > Hi, > > > > while looking at what is needed to switch the xenocara build system to > > the same kind of scheme as base (no more SUDO, start as root and drop > >

Re: M_PREPEND in vxlan encap on not strict-alignment archs

On 10 October 2016 at 05:48, David Gwynne wrote: > if the arch can cope with prepending on an unaligned address in > vxlan, then let it do it. > > this means less work if we can get away with it. > > ok? > I think it's safe to use mtod here. Getting an IP packet with an

Re: httpd(8)/proc.c: use less fds on startup

On Tue, Oct 04, 2016 at 11:54:37PM +0200, Rafael Zalamena wrote: > On Tue, Oct 04, 2016 at 07:46:52PM +0200, Rafael Zalamena wrote: > > This diff makes proc.c daemons to use less file descriptors on startup, > > this way we increase the number of child we can have considerably. This > > also

Re: M_PREPEND in vxlan encap on not strict-alignment archs

On 10 October 2016 at 10:56, Mark Kettenis wrote: >> Date: Mon, 10 Oct 2016 13:48:18 +1000 >> From: David Gwynne >> >> if the arch can cope with prepending on an unaligned address in >> vxlan, then let it do it. >> >> this means less work if we can

rm.c functions in mv(1)

bin/mv has its own copies of cp.c and mv.c. Apparently, they are modifications of cp's cp.c and rm's rm.c, used when moving as "copy and remove the source". In bin/mv/rm.c, the following snippet of rm_file() confuses me: if (S_ISDIR(sb.st_mode)) { warnx("%s: is a

Re: M_PREPEND in vxlan encap on not strict-alignment archs

> Date: Mon, 10 Oct 2016 13:48:18 +1000 > From: David Gwynne > > if the arch can cope with prepending on an unaligned address in > vxlan, then let it do it. > > this means less work if we can get away with it. > > ok? Let's face it. The vxlan protocol is badly designed.

Re: M_PREPEND in vxlan encap on not strict-alignment archs

ok yasuoka thanks, On Mon, 10 Oct 2016 13:48:18 +1000 David Gwynne wrote: > if the arch can cope with prepending on an unaligned address in > vxlan, then let it do it. > > this means less work if we can get away with it. > > ok? > > Index: if_vxlan.c >