making struct __sFILE editable

This is a recipe for bringing the system into a state where the FILE type is opaque for libc users (unless they -D_EXPOSE__sFILE). 1. Apply the attached diff. 2. cd /usr/src/lib/libc && make && make install 3. Do step 3 of release(8). After that transition, I changed "short _file

Re: [patch] Make tcpbench server non-forking and non-blocking.

On Mon, 8 Jun 2009, Christiano Farina Haesbaert wrote: > Hmm, I didn't know we had a soft limit, I thought you had to recompile > the kernel and tune max files, I agree, I'll add support for expanding > the limit. Is there any sane limit ? Or I can push as far as it goes ? Does your diff prealloc

Re: net.inet*.icmp*.rediraccept

* Stuart Henderson [2009-06-08 22:27:40 +0100]: >On 2009/06/08 20:29, Rainer Giedat wrote: >> On Mon, Jun 08, 2009 at 04:26:35PM +0100, Stuart Henderson wrote: >> > Prompted by an undeadly post [0]. What does anyone think about >> > disabling acceptance of ICMP redirects by default? I had a look >

Re: net.inet*.icmp*.rediraccept

On 2009/06/08 20:29, Rainer Giedat wrote: > On Mon, Jun 08, 2009 at 04:26:35PM +0100, Stuart Henderson wrote: > > Prompted by an undeadly post [0]. What does anyone think about > > disabling acceptance of ICMP redirects by default? I had a look > > in a few relevant places and didn't notice any dis

Re: net.inet*.icmp*.rediraccept

On Mon, Jun 08, 2009 at 10:27:40PM +0100, Stuart Henderson wrote: > On 2009/06/08 20:29, Rainer Giedat wrote: > > On Mon, Jun 08, 2009 at 04:26:35PM +0100, Stuart Henderson wrote: > > > Prompted by an undeadly post [0]. What does anyone think about > > > disabling acceptance of ICMP redirects by de

Re: Please test this diff on as many acpi systems as possible

g...@gwk.ca writes: > This will call the ACPI _PDC method, normally this ins't implemented on > systems with amd processors but the acpi spec says that we should try > and evaulate it anyway. In addition to the diff that was backed out > prior to the 4.5 release it will also attempt to evaluate th

Re: net.inet*.icmp*.rediraccept

On Mon, Jun 08, 2009 at 04:26:35PM +0100, Stuart Henderson wrote: > Prompted by an undeadly post [0]. What does anyone think about > disabling acceptance of ICMP redirects by default? I had a look > in a few relevant places and didn't notice any discussion about > this before, but if my google/grep

Re: Please test this diff on as many acpi systems as possible

On Sat, Jun 06, 2009 at 10:23:34PM -0600, g...@gwk.ca wrote: > And it works better if you send the actual diff you would like tested > sorry about this, but please test this one. > seemingly no regressions on thinkpad T61, speedstep is properly recognized now. OpenBSD 4.5-current (GENERIC.MP) #4:

Re: [patch] Make tcpbench server non-forking and non-blocking.

On Mon, Jun 08, 2009 at 06:14:31PM +0200, Reyk Floeter wrote: > hi, > > the idea sounds ok, but why just 128? tcpbench is for benchmarking > and testing and it should be possible to run more concurrent > connections. > > it could call getrlimit() to get the actual RLIMIT_NOFILE value which > is

Re: [patch] Make tcpbench server non-forking and non-blocking.

hi, the idea sounds ok, but why just 128? tcpbench is for benchmarking and testing and it should be possible to run more concurrent connections. it could call getrlimit() to get the actual RLIMIT_NOFILE value which is 128 by default but can be much higher. another variant is the way spamd/spamd

net.inet*.icmp*.rediraccept

Prompted by an undeadly post [0]. What does anyone think about disabling acceptance of ICMP redirects by default? I had a look in a few relevant places and didn't notice any discussion about this before, but if my google/grep-fu is lacking, please point me in the right direction. [0] http://undea

[patch] Make tcpbench server non-forking and non-blocking.

Hi, The following patch makes tcpbench(1) non-forking and non-blocking, I've changed the output to show the file descriptor instead of the pid. The server will no longer die due to excessive forking as it's all wraped in a single process, we are limited however to 128 fds. There is an error when

Re: ACPI C-States diff

The patch makes my dell d430 reboot at boot (just after acpi stuff). jor...@peereboom.us a icrit : Sending out an initial attempt at implementing C-states for APCI CPUs. The C-states are used to implement the CPU idle loop per CPU. Please send dmesgs of booting using this patch. Index: acpicpu

Re: ACPI C-States diff

On Sunday 07 June 2009 21.48.24 you wrote: > Sending out an initial attempt at implementing C-states for APCI CPUs. > The C-states are used to implement the CPU idle loop per CPU. > > Please send dmesgs of booting using this patch. I can not boot bsd.mp with this patch with a ThinkPad T60; kernel c

Re: Please test this diff on as many acpi systems as possible

On Sunday 07 June 2009 06.23.34 g...@gwk.ca wrote: > And it works better if you send the actual diff you would like tested > sorry about this, but please test this one. I'm experiencing no problem on a ThinkPad T60. Daniel -- LIVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D

Re: Please test this diff on as many acpi systems as possible

Works fine here too on amd64, dell d430. OpenBSD 4.5-current (GENERIC.MP) #0: Mon Jun 8 15:49:34 CEST 2009 r...@dbd-lappy.secu-info.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1599606784 (1525MB) avail mem = 1541443584 (1470MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4

Re: Please test this diff on as many acpi systems as possible

On Sat, Jun 06, 2009 at 10:09:19PM -0600, g...@gwk.ca wrote: > Hi there, > > This will call the ACPI _PDC method, normally this ins't implemented on > systems with amd processors but the acpi spec says that we should try > and evaulate it anyway. In addition to the diff that was backed out > prior