Getting help with updating ral(4) for 35xx chipset.

2013-07-11 Thread Nathan Goings
Over the past couple weeks, I've been working on getting the ral(4) driver updated for the 35xx chipset. Specifically version 0x3060 from an Edimax EW-7128Gn. Although the mailing list page says tech@ is not a "tech support", I was privately directed from misc@ to post in tech@. I've previou

Re: manual patch for isakmpd's FIFO "r"

2013-07-11 Thread Jason McIntyre
On Thu, Jul 11, 2013 at 03:25:36PM +0200, Anders Berggren wrote: > > The following patch clarifies that sending "r" over the FIFO doesn't > > produce the exact same results as SIGUSR1. Or do you prefer that we change > > the behaviour of the FIFO's "r" to match SIGUSR1, for example by changing >

Re: netbt, Bluetooth kernel code

2013-07-11 Thread Theo de Raadt
> > So hi, and if there's anybody else looking at this code, please get in > > touch. I hope I'll be able to fix the problems of the device sleeping > > in mutexed code. If there is a high likelihood that this code will > > soon be removed from the tree, that would be nice to know too. Maybe I > >

Re: netbt, Bluetooth kernel code

2013-07-11 Thread Ted Unangst
On Thu, Jul 11, 2013 at 21:46, Tony Sidaway wrote: > So hi, and if there's anybody else looking at this code, please get in > touch. I hope I'll be able to fix the problems of the device sleeping > in mutexed code. If there is a high likelihood that this code will > soon be removed from the tree,

a.out in gcc-local(1)

2013-07-11 Thread Alexey Suslikov
Hi tech@ Just found no longer relevant block in gcc-local(1): - On a.out platforms (i.e. vax), gcc uses a linker wrapper to write stubs that call global constructors and destructors. Those platforms use gcc 2.95.3, and those calls can be traced using -Wl,-trace-ctors-dtors, using syslog_r(

netbt, Bluetooth kernel code

2013-07-11 Thread Tony Sidaway
I'm working on the netbt and /dev/bluetooth code, which is currently broken and has been disabled in the generic kernel for over a year now. I'm not an experienced BSD developer (yet) so I'm using this code as a way of learning how to debug and fix major problems. I'm also working on updating the

Re: base apache and HonorCipherOrder

2013-07-11 Thread Devin Ceartas
Thanks all; I am glad to see this. On Thu, Jul 11, 2013 at 11:35 AM, Joel Sing wrote: > On Mon, 8 Jul 2013, Damien Miller wrote: > > On Sun, 7 Jul 2013, Aaron Stellman wrote: > > > On Tue, Apr 23, 2013 at 09:08:19AM +0200, Otto Moerbeek wrote: > > > > If there is any interest, I might add the m

Re: base apache and HonorCipherOrder

2013-07-11 Thread Joel Sing
On Mon, 8 Jul 2013, Damien Miller wrote: > On Sun, 7 Jul 2013, Aaron Stellman wrote: > > On Tue, Apr 23, 2013 at 09:08:19AM +0200, Otto Moerbeek wrote: > > > If there is any interest, I might add the manual stuff, get ok's and > > > commit it. > > > > I find it useful to have SSLHonorCipherOrder in

Re: manual patch for isakmpd's FIFO "r"

2013-07-11 Thread Anders Berggren
> The following patch clarifies that sending "r" over the FIFO doesn't produce > the exact same results as SIGUSR1. Or do you prefer that we change the > behaviour of the FIFO's "r" to match SIGUSR1, for example by changing > ui_report() to something similar to ui_report_sa(); opening a file, an

Re: SSLHonorCipherOrder for OpenBSD's httpd

2013-07-11 Thread Otto Moerbeek
On Wed, Jul 10, 2013 at 10:28:32AM +0200, Otto Moerbeek wrote: > On Sun, Jul 07, 2013 at 10:17:11PM -0700, Aaron Stellman wrote: > > > On Mon, Jul 08, 2013 at 07:06:43AM +0200, Otto Moerbeek wrote: > > > I think you missed the renogiate case. Anyway, I posted almost the > > > same diff some time

manual patch for isakmpd's FIFO "r"

2013-07-11 Thread Anders Berggren
The following patch clarifies that sending "r" over the FIFO doesn't produce the exact same results as SIGUSR1. Or do you prefer that we change the behaviour of the FIFO's "r" to match SIGUSR1, for example by changing ui_report() to something similar to ui_report_sa(); opening a file, and rewrit

Better bgpd reload (step 1)

2013-07-11 Thread Claudio Jeker
This is the first step to make bgpd reload non blocking in the RDE. It also speeds up the reload time a fair bit in some cases (mainly if you run with multiple RIBs and have larger filtersets) and it should also fix a few edge cases on reloads. I already sent out an earlier version of this diff so