[Patch]: VA-API integration with xenocara

This is a rather large patch that moves my previously submitted VA-API ports into xenocara. For your convenience, I've inlined a diff that shows you all of the changes I made to existing files that you can easily read in your MUA. The xenocara patch also contains these changes and should be the

Re: arc4random: Replace memset(3) with explicit_bzero(3)

Fabio Scotoni wrote: > As far as I can tell, all of the calls to memset(3) in > lib/libc/crypt/arc4random.c are intended to wipe memory to avoid having > the randomly generated data in memory twice, so it would seem good > practice to use explicit_bzero(3) to avoid this being optimized out.

fix mcount.po target in libc/gmon/Makefile.inc

According to the comment in lib/libc/gmon/Makefile.inc, mcount needs special treatment since it cannot be compiled with profiling or pie. When depend was removed as an independent target, this special case was missed. Align it with the inference rules in bsd.lib.mk. This also makes 'make clean'

Re: ublink(4), led(4) and ledctl(1)

On Fri, Dec 13, 2019 at 10:34:59PM +0100, Patrick Wildt wrote: > Hi, > > I have a ThingM blink(1) USB RGB device that shows up as uhid(4). > The tooling is "interesting", especially with all those libusb and > HID libraries doing the abstraction. This introduces ublink(4), a > dedicated kernel

arc4random: Replace memset(3) with explicit_bzero(3)

As far as I can tell, all of the calls to memset(3) in lib/libc/crypt/arc4random.c are intended to wipe memory to avoid having the randomly generated data in memory twice, so it would seem good practice to use explicit_bzero(3) to avoid this being optimized out. Index: lib/libc/crypt/arc4random.c

bgpct minor cleanup

This is just some minor cleanup needed before starting to split out functions into a new file. First it shuffles and changes the fmt_timecore functions. It adds an additional check to not print negative timeframes (the result would most probably be wrong anyway). Second switch show_mrt_dump to use

Re: typo fix for "patern"

We don't accept such changes to what we consider upstream software incorporated into our tree, it just creates difficulty later. Submit to the upstreams. Bryan Stenson wrote: > Another set of typos (inlined below). > > Bryan Stenson > > diff --git gnu/gcc/gcc/config/mips/mips.c

Re: attention please: host's IP stack behavior got changed slightly

On Mon, 16 Dec 2019 14:13:50 +0100, Alexander Bluhm wrote: > Daniel, is your sshd bound to a * or to a 127.0.0.1 socket? According to fstat, it's *:22 > If it > is a * socket, does it work to redirect to the IP address of the > incoming interface? Yes it does. Cheers, Daniel

Re: [Patch]: Integrate VA-API into xenocara

On Wed, Dec 18, 2019 at 03:28:48PM -0600, Brad DeMorrow wrote: > This is a rather large patch that moves my previously submitted > VA-API ports into xenocara. For your convenience, I've inlined > a diff that shows you all of the changes I made to existing files > that you can easily read in your

Re: "usually" is usually spelled "usually"

thanks. i'll work upstream to fix my OCD. :) On Thu, Dec 19, 2019 at 12:27 PM Jason McIntyre wrote: > > On Thu, Dec 19, 2019 at 11:59:20AM -0800, Bryan Stenson wrote: > > Hi all - > > > > Just a doc/typo patch (inlined): > > > > Bryan Stenson > > > > --- > > as theo noted, 3rd party fixes like

Re: ublink(4), led(4) and ledctl(1)

While it's nice to have basic support in the kernel, for people using these devices for sequences / controlling a chain of neopixels / etc they're going to need a custom kernel with the driver disabled in order to access it from userland. For release users this either locks them out of using

[1/3] ssh/readconf.c: Remove SSH1 options in example

Hey! This diff removes unsupported SSH1 options from the format example comment. Best, Martin P.S.: This is the first of 3 diffs, I did them with git this time I hope they are in the correct format. diff --git readconf.c readconf.c index 44464bed71e..eff2d5d1672 100644 --- readconf.c +++

Re: "usually" is usually spelled "usually"

On Thu, Dec 19, 2019 at 11:59:20AM -0800, Bryan Stenson wrote: > Hi all - > > Just a doc/typo patch (inlined): > > Bryan Stenson > > --- as theo noted, 3rd party fixes like this should go upstream (generally stuff in /usr/src/gnu). i committed the last three fixes though. jmc > > diff --git

[2/3] ssh/readconf.c: reorder keywords

Hey! Part 2: This moves always unsupported keywords in the appropriate section. Also move oSecurityProvider to match the order in the OpCodes enum. Best, Martin diff --git readconf.c readconf.c index eff2d5d1672..c2c3d55b656 100644 --- readconf.c +++ readconf.c @@ -183,6 +183,9 @@ static

"usually" is usually spelled "usually"

Hi all - Just a doc/typo patch (inlined): Bryan Stenson --- diff --git gnu/gcc/gcc/unwind.inc gnu/gcc/gcc/unwind.inc index b533eb58873..d55f49cab79 100644 --- gnu/gcc/gcc/unwind.inc +++ gnu/gcc/gcc/unwind.inc @@ -107,7 +107,7 @@ _Unwind_RaiseException(struct _Unwind_Exception *exc) return

[3/3] ssh/readconf.c: Remove deprecated/unsupported opcodes

Hey! Final part: Remove deprecated/always unsupported opcodes from the enum. This is already the case for the majority of the deprecated/always unsupported opcodes. Best, Martin diff --git readconf.c readconf.c index c2c3d55b656..cc845c6fc16 100644 --- readconf.c +++ readconf.c @@ -130,15

Re: ublink(4), led(4) and ledctl(1)

Stuart Henderson wrote: > While it's nice to have basic support in the kernel, for people using > these devices for sequences / controlling a chain of neopixels / etc > they're going to need a custom kernel with the driver disabled in order > to access it from userland. > > For release users

Re: typo fix for "patern"

oh, my apologies. sorry for the noise. thanks. On Thu, Dec 19, 2019 at 12:16 PM Theo de Raadt wrote: > > We don't accept such changes to what we consider upstream software > incorporated into our tree, it just creates difficulty later. > > Submit to the upstreams. > > > Bryan Stenson wrote: >

typo fix for "patern"

Another set of typos (inlined below). Bryan Stenson diff --git gnu/gcc/gcc/config/mips/mips.c gnu/gcc/gcc/config/mips/mips.c index 1edd6b90e4b..1c9d8902428 100644 --- gnu/gcc/gcc/config/mips/mips.c +++ gnu/gcc/gcc/config/mips/mips.c @@ -8911,7 +8911,7 @@ vr4130_align_insns (void) if

Clarify drand48() return values

Clarify that drand48 returns values not including 1.0. Index: src/lib/libc/stdlib/rand48.3 === RCS file: /cvs/src/lib/libc/stdlib/rand48.3,v retrieving revision 1.20 diff -u -r1.20 rand48.3 --- src/lib/libc/stdlib/rand48.3

Re: Clarify drand48() return values

j...@bitminer.ca wrote: > Clarify that drand48 returns values not including 1.0. > > Index: src/lib/libc/stdlib/rand48.3 > === > RCS file: /cvs/src/lib/libc/stdlib/rand48.3,v > retrieving revision 1.20 > diff -u -r1.20 rand48.3 >

bgpctl: split out show functions into own file

This diff just moves most show related functions into a new file. It is mostly mechanical (remove function from bgpctl.c and add it to output.c). OK? -- :wq Claudio ? obj Index: Makefile === RCS file:

Re: amd64 SMEP SMAP trap panic print

On Fri, 20 Dec 2019, Alexander Bluhm wrote: > Can we use the regular trap panic for SMEP and SMAP? pageflttrap() > returns 0 to print a nice reason in kerntrap(). Especially if ddb is > disabled, additional information is printed. > > attempt to access user address 0xe27539f1000 in supervisor

Re: Clarify drand48() return values

OK ok ok. I admit and agree my original patch was flawed. Dumbing down need not be done just for my benefit. --J On 2019-12-19 21:34, Theo de Raadt wrote: Yes, it should be fixed. I'll let the math nerds crawl through the tree looking for additional errors. My objection stands, that we

Re: fix mcount.po target in libc/gmon/Makefile.inc

On Thu, 19 Dec 2019, Theo Buehler wrote: > According to the comment in lib/libc/gmon/Makefile.inc, mcount needs > special treatment since it cannot be compiled with profiling or pie. > > When depend was removed as an independent target, this special case was > missed. Align it with the inference

Re: Clarify drand48() return values

Yes, it should be fixed. I'll let the math nerds crawl through the tree looking for additional errors. My objection stands, that we should not dumb this down. Andras Farkas wrote: > Not to appeal to majority, but to compare and contrast... > FreeBSD, NetBSD, POSIX, and Solaris all use the

amd64 SMEP SMAP trap panic print

Hi, Can we use the regular trap panic for SMEP and SMAP? pageflttrap() returns 0 to print a nice reason in kerntrap(). Especially if ddb is disabled, additional information is printed. attempt to access user address 0xe27539f1000 in supervisor mode fatal page fault in supervisor mode trap type

Re: Clarify drand48() return values

On Thu, Dec 19, 2019 at 04:19:36PM -0800, j...@bitminer.ca wrote: > > Clarify that drand48 returns values not including 1.0. > > Index: src/lib/libc/stdlib/rand48.3 > === > RCS file: /cvs/src/lib/libc/stdlib/rand48.3,v > retrieving

Re: Clarify drand48() return values

On Thu, Dec 19, 2019 at 10:05 PM Theo de Raadt wrote: > It's a mathematical notation that anyone using this page should > understand because it comes with the territory. > [snip] > > I think understanding the landscape's notation is a requirement, and we > don't need to say things a 2nd time in

Re: Clarify drand48() return values

Not to appeal to majority, but to compare and contrast... FreeBSD, NetBSD, POSIX, and Solaris all use the correct (or the more explicit) interval notation for [0.0, 1.0) in drand48.3 https://www.freebsd.org/cgi/man.cgi?query=drand48=0=3=FreeBSD+12.1-RELEASE+and+Ports=default=html

Re: midi(4): *sleep(9) -> *sleep_nsec(9)

On Wed, Dec 18, 2019 at 10:41:56AM -0600, Scott Cheloha wrote: > On Wed, Dec 18, 2019 at 09:54:43AM +0100, Alexandre Ratchov wrote: > > On Tue, Dec 17, 2019 at 07:09:02PM -0600, Scott Cheloha wrote: > > > The only conversion I'm having trouble with is the tsleep(). > > > The comment says "20ms",

net80211: block ack Rx fixes

The function ieee80211_input_ba_seq() forwards any frames on the Rx block ack queue up to a certain sequence number. But it forgets to move the sequence number window forward accordingly. This exacerbates the effect of lost frames: We will keep expecting to receive these frames which have now been