Re: patch: nm(1): add support for symbols created with -ffunction-sections

2021-11-06 Thread George Koehler
On Sat, 6 Nov 2021 15:20:03 +0100 Sebastien Marie wrote: > When an object is compiled using -ffunction-sections... > The following diff makes nm(1) to properly mark the function 'T', by > recognize ".text.*" sections: ok gkoehler@ nm(1) has more problems. If one compiles with -fdata-sections,

Re: userret: take/release kernel lock once

2021-11-06 Thread Mark Kettenis
> Date: Sat, 6 Nov 2021 14:10:57 -0500 > From: Scott Cheloha > > On Fri, Nov 05, 2021 at 03:15:26PM +0100, Christian Ludwig wrote: > > > > comments inline. > > > > [...] > > > > Unlocking if (!need_lock) below looks odd. I think it would make more > > sense to reverse the logic: > > > >

clang performance issue which is much worse on openbsd

2021-11-06 Thread Luke Small
https://bugs.llvm.org/show_bug.cgi?id=50026 I reported it to the llvm people. it is two slightly different quicksort algorithms which perform radically differently. The one which you could assume would take more time, performs MUCH better. I made a custom quicksort algorithm which outperforms

Re: ftp: Print actually requested URLs

2021-11-06 Thread Klemens Nanni
On Sat, Nov 06, 2021 at 07:02:39PM +, Stuart Henderson wrote: > On 2021/11/06 17:29, Klemens Nanni wrote: > > Encoding URL paths changes the requested URL and therefore may yield > > different responses (opposed to an unencoded URL), solely depending on > > how the server implements

Re: userret: take/release kernel lock once

2021-11-06 Thread Scott Cheloha
On Fri, Nov 05, 2021 at 03:15:26PM +0100, Christian Ludwig wrote: > > comments inline. > > [...] > > Unlocking if (!need_lock) below looks odd. I think it would make more > sense to reverse the logic: > > have_lock = 0; > > if (flags) { > if (!have_lock) { >

Re: ftp: Print actually requested URLs

2021-11-06 Thread Stuart Henderson
On 2021/11/06 17:29, Klemens Nanni wrote: > Encoding URL paths changes the requested URL and therefore may yield > different responses (opposed to an unencoded URL), solely depending on > how the server implements de/encoding. Makes sense as this matches what various other tools that fetch URLs

Re: better audio defaults: please test

2021-11-06 Thread Klemens Nanni
On Thu, Nov 04, 2021 at 04:21:12PM +0100, Alexandre Ratchov wrote: > The current sndiod latency (minimum time between when the program > plays something and when sound reaches Joe's ears) is too large and > makes OpenBSD unpleasant to use for telephony, games, and makes > controls of video players

Re: ftp: Print actually requested URLs

2021-11-06 Thread Klemens Nanni
On Sat, Nov 06, 2021 at 11:33:21AM -0600, Theo de Raadt wrote: > > This matches exactly what is seen on the wire, e.g. with tshark(1). > > I don't see why this is important. Users don't need to see what is > on the wire. > > Why intentionaly expose them to a translation they are not supposed >

Re: poll/select: Lazy removal of knotes

2021-11-06 Thread Visa Hankala
On Sat, Nov 06, 2021 at 06:23:27PM +0100, Martin Pieuchot wrote: > On 06/11/21(Sat) 15:53, Visa Hankala wrote: > > On Fri, Nov 05, 2021 at 10:04:50AM +0100, Martin Pieuchot wrote: > > > New poll/select(2) implementation convert 'struct pollfd' and 'fdset' to > > > knotes (kqueue event descriptors)

Re: ftp: Print actually requested URLs

2021-11-06 Thread Theo de Raadt
> This matches exactly what is seen on the wire, e.g. with tshark(1). I don't see why this is important. Users don't need to see what is on the wire. Why intentionaly expose them to a translation they are not supposed to know or care about?

ftp: Print actually requested URLs

2021-11-06 Thread Klemens Nanni
Encoding URL paths changes the requested URL and therefore may yield different responses (opposed to an unencoded URL), solely depending on how the server implements de/encoding. Thus it is imperative to inform users about the factually requested URL in case servers behave unexpectedly. Consider

Re: poll/select: Lazy removal of knotes

2021-11-06 Thread Martin Pieuchot
On 06/11/21(Sat) 15:53, Visa Hankala wrote: > On Fri, Nov 05, 2021 at 10:04:50AM +0100, Martin Pieuchot wrote: > > New poll/select(2) implementation convert 'struct pollfd' and 'fdset' to > > knotes (kqueue event descriptors) then pass them to the kqueue subsystem. > > A knote is allocated, with

Re: better audio defaults: please test

2021-11-06 Thread Matthias Schmidt
Hi Alexandre, * Alexandre Ratchov wrote: > The current sndiod latency (minimum time between when the program > plays something and when sound reaches Joe's ears) is too large and > makes OpenBSD unpleasant to use for telephony, games, and makes > controls of video players slugish. > > The defaut

Re: poll/select: Lazy removal of knotes

2021-11-06 Thread Visa Hankala
On Fri, Nov 05, 2021 at 10:04:50AM +0100, Martin Pieuchot wrote: > New poll/select(2) implementation convert 'struct pollfd' and 'fdset' to > knotes (kqueue event descriptors) then pass them to the kqueue subsystem. > A knote is allocated, with kqueue_register(), for every read, write and > except

Re: patch: nm(1): add support for symbols created with -ffunction-sections

2021-11-06 Thread Antoine Jacoutot
On Sat, Nov 06, 2021 at 03:20:03PM +0100, Sebastien Marie wrote: > Hi, > > aja@ shows me some problems with x11/gnome/librsvg update (the port is > Rust based), and I finally tracked the problem inside nm(1). > > I will not speak of Rust anymore, and will use only C for the example. > > When an

patch: nm(1): add support for symbols created with -ffunction-sections

2021-11-06 Thread Sebastien Marie
Hi, aja@ shows me some problems with x11/gnome/librsvg update (the port is Rust based), and I finally tracked the problem inside nm(1). I will not speak of Rust anymore, and will use only C for the example. When an object is compiled using -ffunction-sections, the compiler/linker will use one

Re: net80211: use BSS load information when choosing access point

2021-11-06 Thread Stefan Sperling
On Wed, Nov 03, 2021 at 02:47:39PM +0100, Stefan Sperling wrote: > If channel load is not a reliable indicator I would hope vendors are at > least able to reliably count and report the number of associated stations? Here is new patch which makes the following changes relative to the previous