On Mon, 17 Feb 2014 17:30:41 -0500, Ted Unangst wrote:
> I don't see how K&R compat helps us. None of the headers in
> /usr/include are K&R anymore. How would one compile the generated output?
You're assuming that the resulting code will be built on OpenBSD.
That's a bad assumption. The code gen
On Mon, 17 Feb 2014 15:25:12 -0500, Ted Unangst wrote:
> It's only been 25 years. I think we can depend on prototypes and
> const now.
Is there really a reason to break K&R compatibility in the generated
code? What problem are you solving?
- todd
On Mon, Feb 17, 2014 at 15:20, Todd C. Miller wrote:
> On Mon, 17 Feb 2014 15:25:12 -0500, Ted Unangst wrote:
>
>> It's only been 25 years. I think we can depend on prototypes and
>> const now.
>
> Is there really a reason to break K&R compatibility in the generated
> code? What problem are you
It's only been 25 years. I think we can depend on prototypes and
const now.
Index: output.c
===
RCS file: /cvs/src/usr.bin/yacc/output.c,v
retrieving revision 1.19
diff -u -p -r1.19 output.c
--- output.c8 Jan 2014 22:55:59 -
>> Date: Mon, 17 Feb 2014 11:22:27 +
>> From: Stuart Henderson
>>
>> On 2014/02/17 09:35, Philipp wrote:
>> > Am 17.02.2014 09:22 schrieb Alex Mathiasen:
>> > >Thank you! This solved my problem.
>> >
>> > Cheers.. found the hard way the other day.
>> >
>> > There should really be some dmesg
* Claudio Jeker [2014-02-17 16:27]:
> How much memory are 10'000 states using these days?
bit over 4MB with one state key per state.
> Would it be possible to auto tune these values somehow?
I keep thinking about it - maybe sth based on physmem.
> One issue I have seen is that because of adapt
On Mon, Feb 17, 2014 at 03:21:53PM +0100, Henning Brauer wrote:
> * Stuart Henderson [2014-02-17 14:45]:
> > Hmm. Well, I was assuming from the name and pfctl(8) description that
> > it should be "state-limit", but actually it seems that is just used for
> > max-src-states and this case just falls
* Stuart Henderson [2014-02-17 14:45]:
> Hmm. Well, I was assuming from the name and pfctl(8) description that
> it should be "state-limit", but actually it seems that is just used for
> max-src-states and this case just falls under "memory" which is not
> too descriptive.
indeed.
> I don't see
On Mon, Feb 17, 2014 at 02:19:42PM +0100, Andre de Oliveira wrote:
> On Sun, Feb 16, 2014 at 10:28:48PM -0500, James Turner wrote:
> > Forgot to include tech@...
> >
> > Hi Andre,
> >
> > I tested upd(4) with my APC Back-UPS ES 550. It looks like it may only
> > have partial support but figured t
On 2014/02/17 12:56, Stuart Henderson wrote:
> The log entries which are at risk of being printed frequently are
> "hidden" by default, i.e. put behind LOG_DEBUG or similar. It seems to
> me that increasing the "state-limit" counter is just as useful as adding
> a new LOG_DEBUG for this..
Hmm. Wel
On Sun, Feb 16, 2014 at 10:28:48PM -0500, James Turner wrote:
> Forgot to include tech@...
>
> Hi Andre,
>
> I tested upd(4) with my APC Back-UPS ES 550. It looks like it may only
> have partial support but figured the report will be helpful nonetheless.
> I'm currently using NUT for monitoring.
* Philipp [2014-02-17 13:36]:
> Am 17.02.2014 13:11 schrieb Henning Brauer:
> >how do you emit such a maessage in pcap? as payload with a dummy
> >packet header? (N!!)
> pf is taking action without telling anyone - and that's not nice.
doesn't change a thing wrt pflog. pflog d
On 2014/02/17 13:36, Philipp wrote:
> Am 17.02.2014 13:11 schrieb Henning Brauer:
> >how do you emit such a maessage in pcap? as payload with a dummy
> >packet header? (N!!)
>
> pf is taking action without telling anyone - and that's not nice.
>
> There *are* other log() entri
> Date: Mon, 17 Feb 2014 11:22:27 +
> From: Stuart Henderson
>
> On 2014/02/17 09:35, Philipp wrote:
> > Am 17.02.2014 09:22 schrieb Alex Mathiasen:
> > >Thank you! This solved my problem.
> >
> > Cheers.. found the hard way the other day.
> >
> > There should really be some dmesg when stat
Am 17.02.2014 13:11 schrieb Henning Brauer:
how do you emit such a maessage in pcap? as payload with a dummy
packet header? (N!!)
pf is taking action without telling anyone - and that's not nice.
There *are* other log() entries in pf.c already so I wonder how the
initial
* Philipp [2014-02-17 13:04]:
> Am 17.02.2014 12:22 schrieb Stuart Henderson:
> >Writing messages that show up in dmesg is not cheap, particularly
> >on systems with serial console.
> Well, ok. How about pflog?
you made my day.
forgot the pflog format?
how do you emit such a maessage in pcap? a
Am 17.02.2014 12:22 schrieb Stuart Henderson:
Writing messages that show up in dmesg is not cheap, particularly
on systems with serial console.
Well, ok. How about pflog?
On 2014/02/17 08:22, Alex Mathiasen wrote:
> Thank you! This solved my problem.
>
> The limit was reached several times within few seconds.
>
> Give this man a medal.
>
> Best regards
>
> Alex Mathiasen
Sounds like you are keeping state for all connections through your bgp
router then - if
On 2014/02/17 09:35, Philipp wrote:
> Am 17.02.2014 09:22 schrieb Alex Mathiasen:
> >Thank you! This solved my problem.
>
> Cheers.. found the hard way the other day.
>
> There should really be some dmesg when state-tables overflow.
> This "silent" dropping is wasting time in debugging such situa
the original implementation use identical logic for both ‘high’ & ‘low’,
which will cause ‘high’ & ‘low’ end up at same RB-tree node, instead of an
expected interval.
and finally, break ‘for’ loop logic
luckily all these conditions never meet in practice.
On Feb 17, 2014, at 5:14 PM, Mike Larkin
On Mon, Feb 17, 2014 at 05:02:34PM +0800, Kieran Devlin wrote:
>
Probably get a better response if you explained what this diff does
and/or fixes...
-ml
> Index: uvm/uvm_pmemrange.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_pmemrange.
Index: uvm/uvm_pmemrange.c
===
RCS file: /cvs/src/sys/uvm/uvm_pmemrange.c,v
retrieving revision 1.37
diff -p -u -r1.37 uvm_pmemrange.c
--- uvm/uvm_pmemrange.c 6 Feb 2014 16:40:40 - 1.37
+++ uvm/uvm_pmemrange.c 13 Feb 2014 22
Am 17.02.2014 09:22 schrieb Alex Mathiasen:
Thank you! This solved my problem.
Cheers.. found the hard way the other day.
There should really be some dmesg when state-tables overflow.
This "silent" dropping is wasting time in debugging such situations.
Sorry for talk instead of diff :-}
Thank you! This solved my problem.
The limit was reached several times within few seconds.
Give this man a medal.
Best regards
Alex Mathiasen
-Oprindelig meddelelse-
Fra: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org] På vegne af Philipp
Sendt: 16. februar 2014 19:19
Til: 't
On Sun, Feb 16, 2014 at 2:57 AM, Mark Kettenis wrote:
> This adds support for a few more instruction patterns that are
> apparentl needed by gcc 4.8. Taken from binutils 2.17. Not sure if
> adding NoRex64 to the existing patterns is really necessary, but it
> shouldn't hurt.
This arose because
25 matches
Mail list logo
