remove vlan specific ifconfig settings

vlan(4) handles the vnetid and ifparent ioctls, so we dont need the vlan specific handling. i previously removed the code that requests info with a vlan specific ioctl, but this removes the vlan settings code. there's a couple of semantic changes to note though. firstly, this aliases the "vlan",

make gem(4) transmit mpsafe

the interrupt handler is already marked mpsafe, but it took the kernel lock to handle the tx ring. this is mostly modelled on hints in ifq.h (which i wrote, so im biased). it avoids the use of atomic ops to keep track of the free space by using the producer and consumer like myx does, and

Re: Reenable ASN1_DN IDs with certificates in iked

Tim Stewart writes: > A sample configuration: > > ikev2 "win10host" passive esp \ > from 0.0.0.0/0 to 10.1.1.51 \ > local any peer any \ > ikesa auth hmac-sha2-384 enc aes-256 prf hmac-sha2-384 group modp2048 \ > childsa enc aes-256-gcm group modp2048 \ > srcid

Re: i386 clang: fix binutils build

I think you want 0xU, not 0xL. Otherwise you will have the same issue on i386. - todd

release(8): add command example to step 3 for sysmerge(8)/MAKEDEV(8)

Hi, There is no command-line sample at the end of step 3 in release(8): After the build is completed, update /etc, /var, and /dev, using sysmerge(8) and MAKEDEV(8). While needs vary by site, providing a sample for the typical case is useful here because MAKEDEV operates in the

i386: sync trampoline code with amd64 for clang

This catches up i386 with the changes to acpi_wakecode.S and mptramp.s that were made on amd64 for clang. Here's kettenis@'s original commit message: ---> Generating mixed 16-bit/32-bit/64-bit code with clang's integrated assembler is a bit tricky. It supports the .code16,

OpenBSD Errata: June 4th, 2017 (perl)

Errata patches for perl have been released for OpenBSD 6.0 and 6.1. A race condition exists in the File::Path module. Binary updates for the amd64 and i386 platforms are available via the syspatch utility. Source code patches can be found on the respective errata pages:

ex(4): fix bungled logical/bitwise expression (clang)

/sys/dev/isa/if_ex.c:619:7: error: logical not is only applied to the left hand side of this bitwise operator [-Werror,-Wlogical-not-parentheses] if (!CSR_READ_2(sc, IO_PORT_REG) & Done_bit) ^~ I think the expression was

Re: eg(4): remove unused function

> Date: Sun, 4 Jun 2017 19:13:01 +0200 > From: Christian Weisgerber > > Remove unused function egprintstat(), as pointed out by clang. > > ok? ok kettenis@ > Index: if_eg.c > === > RCS file:

eg(4): remove unused function

Remove unused function egprintstat(), as pointed out by clang. ok? Index: if_eg.c === RCS file: /cvs/src/sys/dev/isa/if_eg.c,v retrieving revision 1.47 diff -u -p -r1.47 if_eg.c --- if_eg.c 22 Jan 2017 10:17:38 - 1.47

discrepancy between clang and gcc for mkdep

Consider the following: a.c: - #define TEST defined(X) #if TEST #include #endif even though it's not standard C, it does compile. It becomes interesting with the -M option. $ gcc -M a.c a.o: a.c $ clang -M a.c a.c:3:5: warning: macro expansion producing 'defined'

Re: Question on getcwd(3) behavior on OpenBSD

...on Sat, Jun 03, 2017 at 08:25:58PM +0200, Sebastien Marie wrote: > here you don't have VREAD perm on "test1" (only VEXEC), so you can't > obtain the name of "subdir" as it is written in "test1" vnode: getcwd(3) > fails. Thanks for the detailed explanation. I guess that git doesn't handle

Re: arm64: random-order kernel

On Sun, Jun 04, 2017 at 12:46:27AM +0200, Patrick Wildt wrote: > Hi, > > with some guidance from Theo I have random-order kernels on arm64. In > one instance the kernel did not boot up. This could be a real bug, or > not. > > Please try this diff and make sure the machine still boots up. If

Re: i386 clang: fix libc build

On Thu, Jun 01, 2017 at 02:01:02PM +0200, Mark Kettenis wrote: > > Date: Thu, 1 Jun 2017 13:33:05 +0200 > > From: Christian Weisgerber > > > > >From kettenis@'s corresponding commit on amd64: > > > > Remove branch prediction hints from conditional branch instructions. > >

[w...@roquesor.com: Re: ksh(1): vi mode UTF-8 bug]

I realized the issue I describe in the message below (sent to Ingo in private) happens in the tty console (no X11) indifferently of what you set in LC_CTYPE. The problem comes when you have a non english keyboard; you can easily type by accident some non ascii character smaller than 0xc0, then

Re: ksh(1): don't output invalid UTF-8 characters

Hi, Although this discussion hasn't settled, here's a new diff trying to address the previously raised issues: - The new function x_e_getu8() tries to read a complete UTF-8 character. When a continuation byte is expected but not received, it resets its state and retries. The fix to u8len()