On Tue, Apr 29, 2014 at 07:57:32PM -0600, Theo de Raadt wrote:
Don't bother with diffs to b_sock.c. Instead, if you have code
which uses it, talk to krw.
There is a monster diff coming which rewrites it all.
And by the way, all that code disapears and is replaced by 2 lines.
That's
Hello everyone,
I have been following the recent LibreSSL developments quite active and
would like to contribute.
I have some questions:
- The accelerated assembly code for the crypto, is that gonna stay?
- Why not use uint32_t and uint64_t all over (incl the APIs) instead of
custom XX_ULONG
Le 2014-04-29 22:04, Theo de Raadt a écrit :
measurements all over the world show that IPv4 is better
in every respect.
Not disagreeing, but I would like to have access to more data backing
this up. I'm not satisfied with what I found (see other post).
Change that, then we can talk.
Working
Date: Wed, 30 Apr 2014 13:39:20 +0100
From: Stuart Henderson st...@openbsd.org
Seen when running e2fsprogs regression tests with /tmp on tmpfs
I'm not surprised; tmpfs contains some serious bugs. I recommend not
using it until those are fixed.
Data modified on freelist: word
On Wed, Apr 30, 2014 at 03:38:39PM +0200, Mark Kettenis wrote:
Date: Wed, 30 Apr 2014 13:39:20 +0100
From: Stuart Henderson st...@openbsd.org
Seen when running e2fsprogs regression tests with /tmp on tmpfs
I'm not surprised; tmpfs contains some serious bugs. I recommend not
using it
On 30 April 2014 15:55, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
From: Mark Kettenis mark.kette...@xs4all.nl
Date: Wed, 30 Apr 2014 13:39:20 +0100
From: Stuart Henderson st...@openbsd.org
Seen when running e2fsprogs regression tests with
From: Mike Belopuhov m...@belopuhov.com
Date: Wed, 30 Apr 2014 16:00:45 +0200
On 30 April 2014 15:55, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
From: Mark Kettenis mark.kette...@xs4all.nl
Date: Wed, 30 Apr 2014 13:39:20 +0100
From:
On 30 April 2014 10:55, Mark Kettenis mark.kette...@xs4all.nl wrote:
From: Mike Belopuhov m...@belopuhov.com
Date: Wed, 30 Apr 2014 16:00:45 +0200
On 30 April 2014 15:55, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
From: Mark Kettenis
This is probably the simplest way to solve the problem for now.
if we want to mess with sys/queue we can do that separately.
On Wed, Apr 30, 2014 at 8:55 AM, Mark Kettenis mark.kette...@xs4all.nl wrote:
From: Mike Belopuhov m...@belopuhov.com
Date: Wed, 30 Apr 2014 16:00:45 +0200
On 30
On 30 April 2014 16:55, Mark Kettenis mark.kette...@xs4all.nl wrote:
From: Mike Belopuhov m...@belopuhov.com
Date: Wed, 30 Apr 2014 16:00:45 +0200
On 30 April 2014 15:55, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
From: Mark Kettenis
On Wed, Apr 30, 2014 at 03:38:39PM +0200, Mark Kettenis wrote:
Date: Wed, 30 Apr 2014 13:39:20 +0100
From: Stuart Henderson st...@openbsd.org
Seen when running e2fsprogs regression tests with /tmp on tmpfs
I'm not surprised; tmpfs contains some serious bugs. I recommend not
If I had to guess at this point - SRP may have a future.
I'm betting kssl does not, and this should probably go away.
On Tue, Apr 29, 2014 at 4:06 PM, Stefan Fritsch s...@sfritsch.de wrote:
Am Montag, 28. April 2014, 21:40:30 schrieb Ted Unangst:
Also note that I'm not really interested in
I have been following the recent LibreSSL developments quite active and
would like to contribute.
I have some questions:
- The accelerated assembly code for the crypto, is that gonna stay?
Of course. Why do you think anyone would try to break code which works?
- Why not use uint32_t
Speaking for myself here, but as far as LibreSSL is concerned, I'd say
my opinion has a certain weight.
- The accelerated assembly code for the crypto, is that gonna stay?
Yes. Including existing code for platforms OpenBSD itself does not run
on (e.g. s390).
- Why not use uint32_t and
I'm not comfortable with introducing more sys/queue.h APIs. So
perhaps we should just punt on the optimization and remove/insert all
list items. Removing the trap comments that pedro set up...
Since the removal macros poison pointers which should no longer be
dereferenced after the
I have been following the recent LibreSSL developments quite active and
would like to contribute.
I have some questions:
- The accelerated assembly code for the crypto, is that gonna stay?
Of course. Why do you think anyone would try to break code which works?
Because it is a huge amount
Ping.
On Wed, Apr 23, 2014 at 10:15:10PM -0500, Kent R. Spillner wrote:
The diff below removes an unncessary memset() on line 253 of conf.c.
cwm used to support reloading the config file, but okan@ removed that
functionality about a year ago in favor of simply restarting the whole
thing.
Ping.
On Wed, Apr 23, 2014 at 12:44:38PM -0500, Kent R. Spillner wrote:
I think I sent this out a long time ago but never followed up on it. :(
According to cwmrc(5) you can configure an autogroup like so:
autogroup group windowname,windowclass
However, parse.y doesn't actually
Ping.
On Wed, Apr 23, 2014 at 10:48:38PM -0500, Kent R. Spillner wrote:
The diff below removes the check for siz == 0 in xmalloc() because it is
unnecessary.
I was curious about the check for siz == 0 in xmalloc() when I first saw
it, so I dug in further and came to the conclusion it's
Hello,
I found some debug messages need to be fixed in sys/dev/usb/umodem.c.
Can I commit the diff?
SASANO Takayoshi u...@mx5.nisiq.net
Index: umodem.c
===
RCS file: /cvs/src/sys/dev/usb/umodem.c,v
retrieving revision 1.55
Thank you; I'm aware of these (along with others). If anyone is
waiting for me, please be patient while I find a working
laptop/desktop setup.
On Wed, Apr 30, 2014 at 5:07 PM, Kent R. Spillner kspill...@acm.org wrote:
Ping.
On Wed, Apr 23, 2014 at 12:44:38PM -0500, Kent R. Spillner wrote:
I
Il giorno 30/apr/2014 23.11, SASANO Takayoshi u...@mx5.nisiq.net ha
scritto:
Hello,
I found some debug messages need to be fixed in sys/dev/usb/umodem.c.
Can I commit the diff?
Ok dcoppa@
SASANO Takayoshi u...@mx5.nisiq.net
Index: umodem.c
On 2014/04/29 23:12, Stuart Henderson wrote:
On 2014/04/29 22:25, Paul de Weerd wrote:
Disabling IPv6 should not be necessary: it shouldn't be enabled by
default, even link-local addresses.
If doing this, then we need a way to enable link-local, like the opposite
of ifconfig $if -inet6.
Clean up a few things.
1. Drop support for no minor. This variant doesn't exist anymore.
2. Pull up the actual minor processing code into the switch that
parses it.
3. atoi is actually simpler than strtonum in this case, but check the
input beforehand so we don't get unexpected results.
4.
What's better than a freelist? Four freelists!
For each chunk size, pick one of four freelists at random. This
scatters allocations about some more and eliminates the guarantee that
consecutive allocations will always be on the same page.
Technically, there is no bound to how much memory will be
25 matches
Mail list logo
