Re: bzip2

If it covers that tar needs for "tar xjf bla.tbz2" to work then this would be a good addition. 2013/6/6 Ted Unangst > Something that comes up from time to time is the question of whether > to import bzip2 into base or not. Turns out the question is moot > because already have imported it. Ther

iked address pools

I wish to submit a working implementation of address pools for iked, however as it's my first real code contribution and has 643 lines (mostly patch context) I'm wondering if posting here is the correct channel. Also, what is the preferred/normal way to include new files in a patch? --Ryan Slack

bzip2

Something that comes up from time to time is the question of whether to import bzip2 into base or not. Turns out the question is moot because already have imported it. There's a copy in perl. (I didn't know this until I happened to be watching a build closer than usual.) Since we already have the

Re: put procs on rb tree

> Date: Wed, 05 Jun 2013 14:12:36 -0400 > From: Ted Unangst > > On Wed, Jun 05, 2013 at 14:13, Alexandre Ratchov wrote: > > On Tue, Jun 04, 2013 at 11:33:12PM -0400, Ted Unangst wrote: > >> Instead of using a fixed size hash table for procs, use an rb tree. > >> > >> Makes thread/process lookup e

Re: put procs on rb tree

I'm ok with this. On Wed, Jun 05, 2013 at 02:12:36PM -0400, Ted Unangst wrote: > On Wed, Jun 05, 2013 at 14:13, Alexandre Ratchov wrote: > > On Tue, Jun 04, 2013 at 11:33:12PM -0400, Ted Unangst wrote: > >> Instead of using a fixed size hash table for procs, use an rb tree. > >> > >> Makes thre

[PATCH] amd.8 default configuration file

Hi, although amd's default configuration file placement is probably quite self-explanatory, I thought it would be worth to mention that in the man page. FreeBSD and NetBSD do the same. As Gmail (a web client) mangles the patches, here's the link for it: http://weezel.fsck.fi/amd8_defaultconfig.pa

Re: correct includes in man(2) pages

> we should probably not have more than one argument in our pages for the > .In lines, and, arguably, mandoc should behave the same as groff. Regardless, the comment doesn't add much. "#include " is pretty self-explanatory that it's for UFS quotas. :)

Re: put procs on rb tree

On Wed, Jun 05, 2013 at 14:13, Alexandre Ratchov wrote: > On Tue, Jun 04, 2013 at 11:33:12PM -0400, Ted Unangst wrote: >> Instead of using a fixed size hash table for procs, use an rb tree. >> >> Makes thread/process lookup even more web scale. >> > > any measurement? o ye of little faith... sto

Re: correct mistake in logger(1) man page

On Wed, Jun 05, 2013 at 19:28, Andr? St?be wrote: > "logger -f", as described in the man page, > > -f file Log to the specified file. > > actually logs (the contents of) the specified file. Thanks. I changed the wording to "Read from the specified file." so it's even more clear.

correct mistake in logger(1) man page

"logger -f", as described in the man page, -f file Log to the specified file. actually logs (the contents of) the specified file. Regards André Index: src/usr.bin/logger/logger.1 === RCS file: /cvs/src/usr.bin/logger/logg

Re: correct includes in man(2) pages

On Wed, Jun 05, 2013 at 01:14:15PM -0400, Ted Unangst wrote: > On Wed, Jun 05, 2013 at 17:56, Jason McIntyre wrote: > > we should be careful here. mandoc renders it like this: > > > > SYNOPSIS > > #include /* for ufs quotas */ > > #include > > > > whereas groff does this: > > > > SYNOPSIS > >

Re: correct includes in man(2) pages

On Wed, Jun 05, 2013 at 17:56, Jason McIntyre wrote: > we should be careful here. mandoc renders it like this: > > SYNOPSIS > #include /* for ufs quotas */ > #include > > whereas groff does this: > > SYNOPSIS > #include > /* for ufs quotas */ #include > > our mdoc(7) states that .In should

Re: correct includes in man(2) pages

On Wed, Jun 05, 2013 at 06:36:11PM +0200, Jan Klemkow wrote: > > The only special case is this one: > > Index: libc/sys/quotactl.2 > === > RCS file: /cvs/src/lib/libc/sys/quotactl.2,v > retrieving revision 1.11 > diff -u -p -r1.11 qu

Re: -current diff Re: tmpfs

On Wed, Jun 05, 2013 at 02:55:29PM +0200, Marc Espie wrote: > Here's the diff I have to -current with just tmpfs > (activate bits, uvm changes). > > pedro, I know some of your stuff is not in there (I dropped the mount_tmpfs > diff), feel free to give me a full correct updated diff. And of course

-current diff Re: tmpfs

Here's the diff I have to -current with just tmpfs (activate bits, uvm changes). pedro, I know some of your stuff is not in there (I dropped the mount_tmpfs diff), feel free to give me a full correct updated diff. Index: lib/libc/sys/mount.2 ===

Re: put procs on rb tree

On Wed, Jun 05, 2013 at 02:13:04PM +0200, Alexandre Ratchov wrote: > On Tue, Jun 04, 2013 at 11:33:12PM -0400, Ted Unangst wrote: > > Instead of using a fixed size hash table for procs, use an rb tree. > > > > Makes thread/process lookup even more web scale. > > > > any measurement? > It requi

Re: put procs on rb tree

On Tue, Jun 04, 2013 at 11:33:12PM -0400, Ted Unangst wrote: > Instead of using a fixed size hash table for procs, use an rb tree. > > Makes thread/process lookup even more web scale. > any measurement? -- Alexandre

Re: ipsec / PF received-on

On 04/06/2013, at 11:22 AM, Claudio Jeker wrote: > On Mon, Jun 03, 2013 at 11:49:58PM +0100, Stuart Henderson wrote: >> On a router running PF and isakmpd, I have a rule like this: >> >> match out on pppoe0 inet all received-on vlan5 nat-to $someip >> >> I was surprised to find this being appl

fix typo in ltrace usage

Index: ktrace.c === RCS file: /cvs/src/usr.bin/ktrace/ktrace.c,v retrieving revision 1.25 diff -u -r1.25 ktrace.c --- ktrace.c1 Jun 2013 09:57:58 - 1.25 +++ ktrace.c5 Jun 2013 07:55:58 - @@ -215,7 +215,7 @@ {