Hi,
In August 2019 I tried to unlock lseek(2) which failed since the vnode
lock could not be acquired without holding the kernel lock back then,
found the hard way. claudio@ recently[1] make it possible to acquire a
vnode lock without holding the kernel lock. I therefore would like to
give this ano
On Fri, Apr 30, 2021 at 04:42:12PM +0200, Marc Espie wrote:
> On Fri, Apr 30, 2021 at 03:28:42PM +0100, Jason McIntyre wrote:
> > my argument boils down to: sh(1) is small and has no examples. adding
> > them changes the (deliberate) nature of the page. ksh(1) is what you
> > read when you can;t ge
On Fri, Apr 30, 2021 at 04:54:57PM +0200, Christian Weisgerber wrote:
> Marc Espie:
>
> > Until a patch from naddy, I wasn't even aware of getopts in sh(1)
>
> Let's start the discussion with this instead.
>
> This puts the deprecation notice in getopt.1 in a prominent place,
> and uses the same
> I failed to find a case where to use SYSCTL_INT_UNBOUNDED. We always
> find better "common sense" limits than completely unconstrained.
I agree. There must always be a bound.
Vitaliy Makkoveev writes:
> On Thu, Apr 29, 2021 at 09:31:57AM -0700, Greg Steuck wrote:
>> Alexander Bluhm writes:
>> >> I like this too. I somehow got the impression that macros are severely
>> >> frowned upon and didn't offer this kind of interface before.
>> >>
>> >> If you get this submitt
Sebastian Benoit wrote:
> Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.04.29 15:34:15 +0200:
> > Like for rsync repos files in the RRDP repos should be delayed until after
> > the validation finished. As with anything RPKI related there is little
> > trust in the repositories and their abiliti
> On Apr 28, 2021, at 03:47, Claudio Jeker wrote:
>
> There are various time fields in the JSON output.
> last_read, last_write, last_updown on sessions, last_update for rib
> entries and last_change for sets. Currently the value is the fmt_timeframe
> string (which looks something like 7w3d12h)
Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.04.29 15:34:15 +0200:
> Like for rsync repos files in the RRDP repos should be delayed until after
> the validation finished. As with anything RPKI related there is little
> trust in the repositories and their abilities to not botch an update.
>
> On
Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.04.28 12:40:46 +0200:
> At the moment bgpd will fall back to IPv4 unicast if there was no match in
> the multiprotocol capabilities between local and remote peer.
> This is not correct, if the router expects a certain AFI/SAFI for the
> session then i
Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.04.28 10:45:20 +0200:
> There are various time fields in the JSON output.
> last_read, last_write, last_updown on sessions, last_update for rib
> entries and last_change for sets. Currently the value is the fmt_timeframe
> string (which looks somethin
> On Apr 30, 2021, at 15:53, Stuart Henderson wrote:
>
> On 2021/04/05 09:34, Scott Cheloha wrote:
On Apr 5, 2021, at 09:07, Stuart Henderson wrote:
>>> I've attached r620-E5_2630v2-2p6c2t.tgz, from Dell PE R620 with E5-2630v2.
>>> This is a machine which has "disabling user TSC (skew=XXX
In this auxiliary script, replace the deprecated getopt with getopts.
There is no pressing reason to do so, but let's stop perpetuating
an obsolete idiom.
ok?
Index: usr.sbin/switchd/genmap.sh
===
RCS file: /cvs/src/usr.sbin/switchd/
On 2021/04/05 09:34, Scott Cheloha wrote:
> > On Apr 5, 2021, at 09:07, Stuart Henderson wrote:
> >
> > I've attached r620-E5_2630v2-2p6c2t.tgz, from Dell PE R620 with E5-2630v2.
> > This is a machine which has "disabling user TSC (skew=XXX)" reported for
> > some cores:
> >
> > Nov 5 16:08:34
On 22.4.2021. 13:08, Hrvoje Popovski wrote:
> On 22.4.2021. 12:38, Alexander Bluhm wrote:
>> It is not clear why the lock helps. Is it a bug in routing or ARP?
>> Or is it just different timing introduced by the additional kernel
>> lock? The parallel network task stress the subsystems of the ker
/etc/netstart contains the following getopts handler:
while getopts ":n" opt; do
That colon is just totally bogus, isn't it?
tilo
Index: netstart
===
RCS file: /cvs/src/etc/netstart,v
retrieving revision 1.211
diff -u -p -r1.211
On Fri, Apr 30, 2021 at 12:03:41AM +0200, Stefan Sperling wrote:
> This is another patch for Tx aggregation support in iwm(4).
> I have tested 7265, 8265, and 9560, and they seem to work.
>
> Causes of various fatal firmware errors from my earlier attempts at
> getting this to work have been ident
On Fri, Apr 30, 2021 at 06:00:00PM +, Kevin Chadwick wrote:
> On 4/30/21 12:18 PM, Stefan Sperling wrote:
> > Our default group cipher is CCMP which should not involve any TKIP MIC
> > checks on the AP. Such checks occuring would be a bug in this case.
>
> TKIP has been so easily crackable for
On Fri, 30 Apr 2021 11:15:21 -0600, "Theo de Raadt" wrote:
> I disagree.
>
> "dstsize" is conceptually easier for readers to understand.
>
> Secondly, there is nothing which says the library code has to match the
> manual page. Implementation does not need to match documentation.
My feelings exa
I disagree.
"dstsize" is conceptually easier for readers to understand.
Secondly, there is nothing which says the library code has to match the
manual page. Implementation does not need to match documentation.
Emil Engler wrote:
> Hello tech@,
> currently the man-page for strlcpy(3) and strl
Kevin Chadwick wrote:
> On 4/30/21 12:18 PM, Stefan Sperling wrote:
> > Our default group cipher is CCMP which should not involve any TKIP MIC
> > checks on the AP. Such checks occuring would be a bug in this case.
>
> TKIP has been so easily crackable for over a decade that I wonder if it has a
Hi Stefan,
* Stefan Sperling wrote:
> This is another patch for Tx aggregation support in iwm(4).
> I have tested 7265, 8265, and 9560, and they seem to work.
>
> Causes of various fatal firmware errors from my earlier attempts at
> getting this to work have been identified and fixed in this vers
On 4/30/21 12:18 PM, Stefan Sperling wrote:
> Our default group cipher is CCMP which should not involve any TKIP MIC
> checks on the AP. Such checks occuring would be a bug in this case.
TKIP has been so easily crackable for over a decade that I wonder if it has a
place in OpenBSD, atleast without
Hello tech@,
currently the man-page for strlcpy(3) and strlcat(3) calls
the third argument for those functions "dstsize" whereas the
C source code calls it "dsize". This patch addresses this issue
by renaming it to "dsize" to keep coherency between the man-page
and the source code.
diff --git a/li
On Fri, Apr 30, 2021 at 04:54:57PM +0200, Christian Weisgerber wrote:
> Marc Espie:
>
> > Until a patch from naddy, I wasn't even aware of getopts in sh(1)
>
> Let's start the discussion with this instead.
>
> This puts the deprecation notice in getopt.1 in a prominent place,
> and uses the same
Marc Espie:
> Until a patch from naddy, I wasn't even aware of getopts in sh(1)
Let's start the discussion with this instead.
This puts the deprecation notice in getopt.1 in a prominent place,
and uses the same snippet in sh.1 and ksh.1.
Index: bin/ksh/ksh.1
On Fri, Apr 30, 2021 at 03:28:42PM +0100, Jason McIntyre wrote:
> my argument boils down to: sh(1) is small and has no examples. adding
> them changes the (deliberate) nature of the page. ksh(1) is what you
> read when you can;t get to sleep.
>
> why is it wrong to add your example to ksh(1)? why
On Fri, Apr 30, 2021 at 03:28:42PM +0100, Jason McIntyre wrote:
> On Fri, Apr 30, 2021 at 04:07:55PM +0200, Marc Espie wrote:
> > On Fri, Apr 30, 2021 at 02:44:01PM +0100, Jason McIntyre wrote:
> > > On Fri, Apr 30, 2021 at 11:54:16AM +0200, Marc Espie wrote:
> > > > Until a patch from naddy, I was
On Fri, Apr 30, 2021 at 04:07:55PM +0200, Marc Espie wrote:
> On Fri, Apr 30, 2021 at 02:44:01PM +0100, Jason McIntyre wrote:
> > On Fri, Apr 30, 2021 at 11:54:16AM +0200, Marc Espie wrote:
> > > Until a patch from naddy, I wasn't even aware of getopts in sh(1)
> > >
> > > Unless I made some mista
On Fri, Apr 30, 2021 at 02:44:01PM +0100, Jason McIntyre wrote:
> On Fri, Apr 30, 2021 at 11:54:16AM +0200, Marc Espie wrote:
> > Until a patch from naddy, I wasn't even aware of getopts in sh(1)
> >
> > Unless I made some mistakes, this translates the example in getopt(1)
> > manpage.
> >
> > It
On Fri, Apr 30, 2021 at 11:54:16AM +0200, Marc Espie wrote:
> Until a patch from naddy, I wasn't even aware of getopts in sh(1)
>
> Unless I made some mistakes, this translates the example in getopt(1)
> manpage.
>
> It's likely some stronger wording might be adequate, I suspect some
> of the BUG
On Fri, Apr 30, 2021 at 02:31:22PM +0200, Mark Kettenis wrote:
> media autoselect mediaopt hostap
> nwid openbsd chan 60 wpakey password
> inet 192.168.32.1
>
> and this is what ifconfig athn0 shows:
>
> athn0: flags=8843 mtu 1500
> lladdr 6c:71:d9:33:44:55
> index 3 priority 4 ll
The conclusion of my previous fixes to vmd(8) [1] changes the event
handling in vmctl(8) to support receiving IMSG_VMDOP_TERMINATE_VM_EVENTs
from the control process. (This removes a XXX comment from vmd.)
For clarity, the messaging logic was changed previously:
- ...TERMINATE_VM_RESPONSE conveyi
> Date: Fri, 30 Apr 2021 14:18:46 +0200
> From: Stefan Sperling
[ Dropping Florian from the CC ]
> On Fri, Apr 30, 2021 at 12:36:57PM +0200, Mark Kettenis wrote:
> > Since booting into a kernel with this diff, I've started seeing the
> > following messages on my OpenBSD AP that uses athn(4):
> >
On Fri, Apr 30, 2021 at 12:36:57PM +0200, Mark Kettenis wrote:
> Since booting into a kernel with this diff, I've started seeing the
> following messages on my OpenBSD AP that uses athn(4):
>
> Apr 30 02:13:54 smetana /bsd: athn0: Michael MIC failure
> Apr 30 02:14:40 smetana /bsd: athn0: Michael
On Fri, Apr 30, 2021 at 12:14:26PM BST, Marc Espie wrote:
> On Fri, Apr 30, 2021 at 12:03:00PM +0100, Raf Czlonka wrote:
> > Hi Mark,
> >
> > You and me both ;^)
> >
> > Until recently, I thought that getopt(1) was POSIX, whereas it is
> > in fact getopts(1), and it is not a shell built-in there,
On Fri, Apr 30, 2021 at 12:03:00PM +0100, Raf Czlonka wrote:
> Hi Mark,
>
> You and me both ;^)
>
> Until recently, I thought that getopt(1) was POSIX, whereas it is
> in fact getopts(1), and it is not a shell built-in there, but a
> utility[0].
Nope, it is a shell built-in... the "wording" of p
Hi Mark,
You and me both ;^)
Until recently, I thought that getopt(1) was POSIX, whereas it is
in fact getopts(1), and it is not a shell built-in there, but a
utility[0].
[0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/getopts.html
Cheers,
Raf
On Fri, Apr 30, 2021 at 10:54:16AM
> Date: Fri, 30 Apr 2021 11:56:49 +0200
> From: Florian Obser
>
> This still works fine on
>
> iwm0 at pci2 dev 0 function 0 "Intel AC 7260" rev 0x83, msi
> iwm0: hw rev 0x140, fw ver 17.3216344376.0
Since booting into a kernel with this diff, I've started seeing the
following messages on my O
This still works fine on
iwm0 at pci2 dev 0 function 0 "Intel AC 7260" rev 0x83, msi
iwm0: hw rev 0x140, fw ver 17.3216344376.0
Thanks,
Florian
--
I'm not entirely sure you are real.
Until a patch from naddy, I wasn't even aware of getopts in sh(1)
Unless I made some mistakes, this translates the example in getopt(1)
manpage.
It's likely some stronger wording might be adequate, I suspect some
of the BUGS section in getopt(1) does not apply to the sh(1) built-in.
Index: bin/k
We have released OpenBGPD 6.9p0, which will be arriving in the
OpenBGPD directory of your local OpenBSD mirror soon.
This is the first stable release for the 6.9 version. It includes
the following changes:
* Introduced bgpd(8) 'rde evaluate all' to reduce path hiding in
IXP route-server
41 matches
Mail list logo