Re: cu: loop over cua00-09+cuaU0-U9

On Tue, Jan 09, 2018 at 01:44:04PM -0700, Theo de Raadt wrote: > No way. > > No justification provided for anyone to want this feature. > Np, this is just what i want this for: ucom0 at uchcom0 ucom1 at uplcom0 ucom2 at uslcom0 portno 0 ucom3 at uftdi0 portno 1 ucom4 at uftdi1 portno 1 ucom5

cu: loop over cua00-09+cuaU0-U9

Hi, maybe someone else does find this usable :) will loop to find the first available cua line unless -r or line_path chosen before open(), so this does not really change the mostly expected behaviour i can think of; only does make cua00 little less special. -Artturi diff --git

Re: cu: loop over cua00-09+cuaU0-U9

No way. No justification provided for anyone to want this feature. > maybe someone else does find this usable :) > will loop to find the first available cua line unless -r or line_path > chosen before open(), so this does not really change the mostly > expected behaviour i can think of; only

Re: make mpls_input take struct ifnet *ifp as an argument

(forwarded from misc@) Hi, while reading the changes in OpenBSD source code (hopefully to learn more), I've notice the usage of Uninitialized variable. Looks like the latest commit unintentionally removed the assignment line (sorry for the github link):

Re: cu: loop over cua00-09+cuaU0-U9

You want to connect to the next available port? yeah, and I'll work up a diff so that newfs without any arguements initializes the next partition. The concept is ridiculous. > On Tue, Jan 09, 2018 at 01:44:04PM -0700, Theo de Raadt wrote: > > No way. > > > > No justification provided for

Use kernel-space address with FUSE_DEBUG

The following patch use the proper address space when using a kernel with FUSE_DEBUG (kernel instead of user, see the copyin above). While here, add some sanity check to the debug function fuse_dump_buff. -- Thomas Jeunet Index: sys/miscfs/fuse/fuse_device.c

Unify a bit further

Diff below is mostly cosmetic. The only real change is that `mtx_owner' becomes the first field of 'struct mutex' on i386/amd64/arm64. ok? Index: amd64/include/mutex.h === RCS file: /cvs/src/sys/arch/amd64/include/mutex.h,v

Re: mg: extract child status with WEXITSTATUS

On Tue, 09 Jan 2018 10:05:22 -0600, Scott Cheloha wrote: > After discussing it with jca@ and trying a few variations I've settled > on the attached diff. > > We indicate if sh(1) was signalled because we have that information at > hand. Otherwise we report the exit status as we always have.

pf icmp error

Hi, I think we should use pf_send_icmp() in pf_route(). It is more consistent and sets the routing domain and other mbuf flags. In pf_route6() the bad packet counter and PF_DUPTO check were missing which is inconsistent to IPv4. ok? bluhm Index: net/pf.c

Re: sosetstate/soclrstate

On Tue, Jan 09, 2018 at 11:23:32AM +0100, Martin Pieuchot wrote: > --- netinet6/ip6_output.c 1 Sep 2017 15:05:31 - 1.232 > +++ netinet6/ip6_output.c 9 Jan 2018 10:16:10 - > @@ -1033,12 +1033,12 @@ int > ip6_ctloutput(int op, struct socket *so, int level, int optname, >

Re: TCP/UDP/etc input path w/o KERNEL_LOCK()

On 02/01/18(Tue) 16:04, Martin Pieuchot wrote: > New year, new diff. Assuming we can live with the kqueue(2) races, > here's a diff to remove the KERNEL_LOCK() from all pr_input() routines. > > I'd appreciate tests. I got multiple positive reports, I'd like to commit this to see if anything

Re: sosetstate/soclrstate

On 09/01/18(Tue) 00:42, Alexander Bluhm wrote: > On Mon, Jan 08, 2018 at 03:50:14PM +0100, Martin Pieuchot wrote: > > ok? > > OK bluhm@ with a few remarks. visa@ pointed out that since all the writes are done under the socket lock it is enough to use an aligned int32 variable. So here's an

shuffle protocol family input in ether_input()

the main change here is to defer chopping the ethernet header off the frame until just before the protocol input function is called. this means we don't have to reattach it for pppoe. ok? Index: if_ethersubr.c === RCS file:

Basic SHA3 support

Hi everyone, enclosed you find a patch to add basic SHA3-/Keccak support to OpenBSD. Changes have been made to libc, and a suite of sha3 checksum tools were added (sha3-224, sha3-256, sha3-384, sha-512), extending the existing md5(1) checksum tool. The SHA3 implementation itself was taken from

Re: shuffle protocol family input in ether_input()

On Tue, Jan 09, 2018 at 06:40:49PM +1000, David Gwynne wrote: > the main change here is to defer chopping the ethernet header off > the frame until just before the protocol input function is called. > this means we don't have to reattach it for pppoe. > > ok? OK bluhm@ > Index: if_ethersubr.c >

Re: mg: extract child status with WEXITSTATUS

After discussing it with jca@ and trying a few variations I've settled on the attached diff. We indicate if sh(1) was signalled because we have that information at hand. Otherwise we report the exit status as we always have. ok? Index: grep.c

Re: TCP/UDP/etc input path w/o KERNEL_LOCK()

On Tue, Jan 09, 2018 at 11:24:14AM +0100, Martin Pieuchot wrote: > On 02/01/18(Tue) 16:04, Martin Pieuchot wrote: > > New year, new diff. Assuming we can live with the kqueue(2) races, > > here's a diff to remove the KERNEL_LOCK() from all pr_input() routines. > > > > I'd appreciate tests. > >

Re: Basic SHA3 support

On Tue, 09 Jan 2018 16:47:18 +0100, Daniel Loebenberger wrote: > Changes have been made to libc, and a suite of sha3 checksum tools > were added (sha3-224, sha3-256, sha3-384, sha-512), extending the > existing md5(1) checksum tool. > > The SHA3 implementation itself was taken from the reference

Re: mg: extract child status with WEXITSTATUS

On Tue, Jan 09, 2018 at 10:05:22AM -0600, Scott Cheloha wrote: > After discussing it with jca@ and trying a few variations I've settled > on the attached diff. > > We indicate if sh(1) was signalled because we have that information at > hand. Otherwise we report the exit status as we always

simplify valid carp interface check in carp_proto_input_if

this copies the "valid interface" check from carp6_proto_input_if to carp_proto_input_if. the current check looks to see if the current interface is carp, or if the current interface has any carps attached to it. the carp6_proto_input_if check just checks if the current interface is IFT_CARP or

Re: simplify valid carp interface check in carp_proto_input_if

so carp_output calls ether_output, which makes it pretty obvious that carp is for ethernet only. ie, this diff is safe. > On 10 Jan 2018, at 14:05, David Gwynne wrote: > > this copies the "valid interface" check from carp6_proto_input_if > to carp_proto_input_if. the