Re: mg(1) tell make-backup-files is on by default

Solene Rapenne(sol...@perso.pw) on 2019.11.08 18:39:20 +0100: > Someone on reddit had issue with this config file, there was no backup > file, in file directory or in ~/.mg.d > > make-backup-files > backup-to-home-directory > > in fact, having "make-backup-files" disables backups. > > > I've lo

Re: upgrade66.html missing acme-client.conf staging api url change

Solene Rapenne(sol...@perso.pw) on 2019.11.08 18:13:40 +0100: > The staging api changed too. I know people who did not update that url, > it's not especially obvious because the old url doesn't contain v01. > > ok ? Nice! I actually wondered about that and my google foo was too low. Thanks for fi

mg(1) tell make-backup-files is on by default

Someone on reddit had issue with this config file, there was no backup file, in file directory or in ~/.mg.d make-backup-files backup-to-home-directory in fact, having "make-backup-files" disables backups. I've looked at the mg logic for backup files and I could sort that the default make-backu

Re: iwm: support more than one frame per interrupt

On Fri, Nov 08, 2019 at 07:15:18PM +0200, Stefan Sperling wrote: > On Fri, Nov 08, 2019 at 07:13:17PM +0200, Stefan Sperling wrote: > > Previous versions of this diff included monitor mode support. I have > > stripped > > this out for now and I am looking for stability tests in client mode only. >

Re: iwm: support more than one frame per interrupt

On Fri, Nov 08, 2019 at 07:13:17PM +0200, Stefan Sperling wrote: > Previous versions of this diff included monitor mode support. I have stripped > this out for now and I am looking for stability tests in client mode only. > If this diff passes through testing this time around, adding monitor mode >

iwm: support more than one frame per interrupt

This adds support for receiving more than one frame per interrupt to iwm(4). There have been several past attempts at this already, all of which failed due to stability issues found during testing. Previous versions of this diff included monitor mode support. I have stripped this out for now and I

upgrade66.html missing acme-client.conf staging api url change

The staging api changed too. I know people who did not update that url, it's not especially obvious because the old url doesn't contain v01. ok ? Index: upgrade66.html === RCS file: /data/cvs/www/faq/upgrade66.html,v retrieving revis

uvm_mapanon() & trylock

uvm_mapanon() is called in two occasions: mmap(2) and sigaltstack(2). Both code paths are obviously in process context an can sleep. That explains why none of them set the UVM_FLAG_TRYLOCK when calling such function. The diff below removes support for this flag. This introduces a difference with

Re: vm_map_assert_{un,}locked()

On 08/11/19(Fri) 17:28, Martin Pieuchot wrote: > Current UVM code uses comments to explains when a `map' should be locked > or unlocked. > > The diff below introduces functions to check those assertions and start > to use them in two safe places. This also has the advantage of self- > documenting

Re: net80211: do not connect to any open network by default

Stefan Sperling wrote: > .Cm join . > .It Cm -nwid > -Set the NWID to the empty string to allow the interface to connect > -to any available access point. > +Clear the currently configured network ID. I don't understand. You are assuming that sentence will have obvious consequences for users

Re: net80211: do not connect to any open network by default

On Fri, Nov 08, 2019 at 04:28:23PM +, Stuart Henderson wrote: > On 2019/11/08 17:56, Stefan Sperling wrote: > > The default wifi interface behaviour of connecting to any open network > > when nothing is configured is confusing people who have gotten used to > > the behaviour of ifconfig join. >

vm_map_assert_{un,}locked()

Current UVM code uses comments to explains when a `map' should be locked or unlocked. The diff below introduces functions to check those assertions and start to use them in two safe places. This also has the advantage of self- documenting the code, so fewer comments. While here move the definiti

Re: net80211: do not connect to any open network by default

On 2019/11/08 17:56, Stefan Sperling wrote: > The default wifi interface behaviour of connecting to any open network > when nothing is configured is confusing people who have gotten used to > the behaviour of ifconfig join. > > With this diff connecting to any open network on 'ifconfg iwm0 up' req

net80211: do not connect to any open network by default

The default wifi interface behaviour of connecting to any open network when nothing is configured is confusing people who have gotten used to the behaviour of ifconfig join. With this diff connecting to any open network on 'ifconfg iwm0 up' requires the user to run ifconfig iwm0 join "" first. Oth

Re: sysupgrade: Allow to use another directory for the sets

On 2019/11/06 13:41, Renaud Allard wrote: > Hello, > > Given the amount of people which encrypt /home directory on their servers, > it might be useful to be able to define another directory for the sets in > sysupgrade as /home_sysupgrade will not be available in that case. This (encrypted /home

net80211: make join deselect failing APs

An AP which never responds to auth/assoc requests can remain in the joinlist and keep being selected. This results in an endless loop between SCAN and AUTH (and sometimes ASSOC) states: iwm0: SCAN -> AUTH iwm0: sending auth to 00:1a:dd:da:e3:f1 on channel 64 mode 11a iwm0: AUTH -> SCAN Another AP