The diff attached to this mail fixes the bridge output for VLANs noted in
this link:
http://marc.info/?l=openbsd-misc&m=141508025731320&w=2
Now when we are doing VLAN input we check whether the VLAN is a bridge port
or not, if it does then we have to do nothing and just pass the packet and
the bri
On Tue, Nov 11, 2014 at 10:17 PM, Brent Cook wrote:
> Yes, this is an intentional design feature: fail fast if there is no entropy.
>
> I'm looking at your other patches and testing with mingw 3.1.0, but am
> having to fix a number of minor build failures.
>
> Out of curiosity, what version are yo
On Tue, Nov 11, 2014 at 02:46:40PM -0700, Todd C. Miller wrote:
> This all looks OK to me but I think it would be better to just
> remove MAP_FILE from the mmap() flags as it is not really
> needed.
Good idea, I missed that. Thanks!
Updated diff below.
cheers,
natano
Index: cl/cl.h
This all looks OK to me but I think it would be better to just
remove MAP_FILE from the mmap() flags as it is not really
needed.
- todd
The more I dig into vi, the more portability goo I find: The TRUE and
FALSE constants are defined by , thus no need to check for
them. The mvchgat macro, VWERASE and tons of other macros are present
in OpenBSDs curses implementation, this means a lot of the #ifdef maze
can be removed. SIGWINCH is p
Hi everyone,
I just built the kernel with XHCI_DEBUG enabled. I am having
the following problem:
1) boot the machine with keyboard and mouse plugged in
2) keyboard does not respond at the login prompt
3) plug it out and plug it back in at the same USB port
4) keyboard does not respond
5) plug it
> > Thanks.
>
> Looking again I saw no obvious issues.
\o/
> >> > + if (EC_GROUP_get_order(group, order, ctx) == 0) {
> >> > + /*
> >> > +* XXX EC_GROUP_get_order() will return 0 if successful
> >> > but
> >> > +* XXX order == 0. But then BN_m
I gave the openbsd src patches a spin last night. I wonder if there's
a way we could instead coerce mingw into pretending to be more POSIX
by way of header tricks in the portable tree:
Create a stubs for each POSIX network header, e.g. include/sys/socket.h:
#ifndef _WIN32
#include_next
#else
#in
Yes, this is an intentional design feature: fail fast if there is no entropy.
I'm looking at your other patches and testing with mingw 3.1.0, but am
having to fix a number of minor build failures.
Out of curiosity, what version are you testing against?
On Tue, Nov 11, 2014 at 8:07 AM, Dongsheng
On Tue, Nov 11, 2014 at 9:56 PM, Brent Cook wrote:
> Mystery solved!
This patch fixed the exited immediately issue.
When getentropy failed, LibReSSL will call _getentropy_fail, it call
TerminateProcess(GetCurrentProcess(), 0) to exit.
Thank you, applied.
I tried out your win32 port branch yesterday and noticed that all of
the tests and s_client all exited immediately, but it was too late to
dig into it. Mystery solved!
On Tue, Nov 11, 2014 at 1:21 AM, wrote:
> From: Dongsheng Song
>
> Please see
> http://msdn.microsoft.com
On Tue, Nov 11, 2014 at 02:21:35PM +0400, Vadim Zhukov wrote:
> Why TAILQ? SLIST should be enough.
SLIST makes sense yes.
> Also, moving sys/types.h is wrong.
OK, will fix.
> Why do you want to get this in? Any more ac(8) patches coming?
Not really, I was just randomly browsing through the sou
Remove unreachable code from ether_ifdetach, it has been marked that way
for almost 11 years.
Index: net/if_ethersubr.c
===
RCS file: /home/rzalamena/obsdcvs/src/sys/net/if_ethersubr.c,v
retrieving revision 1.177
diff -u -p -u -r1.177
2014-11-10 17:29 GMT+03:00 Miod Vallat :
>> > The following diff attempts to polish the GOST code in libcrypto and add
>> > many missing error checks (probably not exhaustive, but a good start).
>>
>> I knew that I'm not perfect, but I didn't know the depth of my
>> imperfectness...
>
> Well, most
Why TAILQ? SLIST should be enough.
Also, moving sys/types.h is wrong.
Why do you want to get this in? Any more ac(8) patches coming?
--
Vadim Zhukov
05 нояб. 2014 г. 14:34 пользователь "Dimitris Papastamos"
написал:
> Hi,
>
> I've attempted to convert the hand-rolled linked lists over to
> TAI
Hi everyone,
Any interest in this? It is a cleanup change and not intended to have
any functional differences.
Cheers,
Dimitris
16 matches
Mail list logo
