On Sun, 2020-07-26 at 04:15 +0100, ropers wrote:
> On 25/07/2020, Martijn van Duren wrote:
> > This function is used throughout the OpenBSD tree and I think it's
> > fine as it is. This way it's clearer to me that it's about byte
> > 7 and 8
>
> You mean bits 7 and 8 when counting from 1 from the
On 25/07/2020, Martijn van Duren wrote:
> This function is used throughout the OpenBSD tree and I think it's
> fine as it is. This way it's clearer to me that it's about byte
> 7 and 8
You mean bits 7 and 8 when counting from 1 from the right?
> and not have to do the math in my head to check if
Hi,
I want to add clock-based timeouts to the kernel because tick-based
timeouts suffer from a few problems:
1. They are not sensitive to NTP adjustment, so they can easily
expire too early or too late. This is incorrect, particularly
for POSIX interfaces that forbid early return.
2.
On Sat, Jul 25, 2020 at 02:01:06PM +0200, Jeremie Courreges-Anglas wrote:
>
> For those two reasons I think the feature should be opt-in.
Yeah, I agree with you. My first approach was to have it check what
kind of DNS record that was requested, and add the AD-flag only if type
was SSHFP, but tha
Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2020.07.25 14:01:06 +0200:
> On Fri, Jul 17 2020, Jesper Wallin wrote:
> > Hi all,
> >
> > I recently decided to add SSHFP records for my servers, since I never
> > memorize or write down my key fingerprints. I learned that if I
> > want ssh(1) to trus
On 2020/07/25 18:10, Marcus Glocker wrote:
> On Sun, Jul 19, 2020 at 02:12:21PM +, sc.dy...@gmail.com wrote:
>
>> On 2020/07/19 11:25, Marcus Glocker wrote:
>>> On Sun, 19 Jul 2020 02:25:30 +
>>> sc.dy...@gmail.com wrote:
>>>
hi,
It works on AMD Bolton xHCI (78141022), Intel
Hi,
Martijn van Duren wrote on Sat, Jul 25, 2020 at 09:54:53PM +0200:
> This function is used throughout the OpenBSD tree and I think it's
> fine as it is. This way it's clearer to me that it's about byte
> 7 and 8 and not have to do the math in my head to check if we
> might have botched it.
>
This function is used throughout the OpenBSD tree and I think it's
fine as it is. This way it's clearer to me that it's about byte
7 and 8 and not have to do the math in my head to check if we
might have botched it.
Also compilers should be smart enough to optimize this out at
compile-time anyway.
On Sun, Jul 19, 2020 at 02:12:21PM +, sc.dy...@gmail.com wrote:
> On 2020/07/19 11:25, Marcus Glocker wrote:
> > On Sun, 19 Jul 2020 02:25:30 +
> > sc.dy...@gmail.com wrote:
> >
> >> hi,
> >>
> >> It works on AMD Bolton xHCI (78141022), Intel PCH (1e318086),
> >> and ASM1042 (10421b21).
>
On Fri, Jul 17, 2020 at 10:47:50AM -0900, Philip Guenther wrote:
> On Thu, Jul 16, 2020 at 4:55 PM Scott Cheloha
> wrote:
>
> > > On Jul 16, 2020, at 19:36, Theo de Raadt wrote:
> > >
> > >> Note the third sentence.
> > >>
> > >> Given that, I reason that a serializing instruction before *and* a
On Sat, Jul 25, 2020 at 10:27:15AM -0600, Theo de Raadt wrote:
Hello Theo,
> My primary concern is about a user changing settings which then persist
> past close.
>
> Upon re-open, how do they know what mode they are in?
>
> I understand the default mode for a camera might not be nice. But at le
On Sat, Jul 25, 2020 at 10:27:15AM -0600, Theo de Raadt wrote:
> Matthieu Herrb wrote:
>
> > On Sat, Jul 25, 2020 at 09:17:24AM -0600, Theo de Raadt wrote:
> > > Marcus Glocker wrote:
> > >
> > > > Instead of introducing the CLI parameter controls in video(1), we could
> > > > introduce videoc
Stuart Henderson wrote:
> On 2020/07/25 09:20, Theo de Raadt wrote:
> > The normal idiom is when last-close happens in a driver, all modal-state
> > is lost and restored to default, and when you use the driver again --
> > the new open gets you a raw configuration which is then changed via
> > io
On 2020/07/25 09:20, Theo de Raadt wrote:
> The normal idiom is when last-close happens in a driver, all modal-state
> is lost and restored to default, and when you use the driver again --
> the new open gets you a raw configuration which is then changed via
> ioctl, before futher use.
Isn't this
Index: emacs.c
===
RCS file: /cvs/src/bin/ksh/emacs.c,v
retrieving revision 1.87
diff -u -r1.87 emacs.c
--- emacs.c 8 May 2020 14:30:42 - 1.87
+++ emacs.c 25 Jul 2020 16:31:22 -
@@ -269,10 +269,11 @@
{ 0,
Matthieu Herrb wrote:
> On Sat, Jul 25, 2020 at 09:17:24AM -0600, Theo de Raadt wrote:
> > Marcus Glocker wrote:
> >
> > > Instead of introducing the CLI parameter controls in video(1), we could
> > > introduce videoctl(1) in base, same as we have with audioctl(1). This
> > > also gives us the
On Sat, Jul 25, 2020 at 09:17:24AM -0600, Theo de Raadt wrote:
> Marcus Glocker wrote:
>
> > Instead of introducing the CLI parameter controls in video(1), we could
> > introduce videoctl(1) in base, same as we have with audioctl(1). This
> > also gives us the possibility to only display the cur
$ video -c white_balance_temperature=6500
$ video
$ video -c reset
$ video
BTW, no other subsystem of ours has this "reset" type thing.
A few subsystems have persistance, but persistant modes are usually only
in the software layer, not in the hardware layer.
The normal idiom is when last
Marcus Glocker wrote:
> Instead of introducing the CLI parameter controls in video(1), we could
> introduce videoctl(1) in base, same as we have with audioctl(1). This
> also gives us the possibility to only display the current video
> parameters.
I must have missed something. Why does it need
On Sat, Jul 25, 2020 at 09:37:37PM +0900, YASUOKA Masahiko wrote:
> Is this part a reason why we have "divert-reply"?
Yes.
Divert rules pass packets to the local network stack. With divert-to
you specify the socket address. This works for incomming connections.
The divert-to address can be 127.
On Sat, 25 Jul 2020 13:29:57 +0200
Alexander Bluhm wrote:
> On Sat, Jul 25, 2020 at 08:20:21PM +0900, YASUOKA Masahiko wrote:
>> Currently SO_BINDANY is usable without any divert or divert-reply
>> rule.
>
> This is why we have the divert-reply feature. Just mark the states
> with that keyword w
On Sat, Jul 25, 2020 at 04:27:44PM +0900, YASUOKA Masahiko wrote:
> When an unicast address is specified for carppeer, if the peer is
> down, sending out advertisemnent packets will fail, this failure is
> treated as an error of the sending host, then the error counter is
> incremented and carpdemo
On Fri, Jul 17 2020, Jesper Wallin wrote:
> Hi all,
>
> I recently decided to add SSHFP records for my servers, since I never
> memorize or write down my key fingerprints. I learned that if I
> want ssh(1) to trust these records, DNSSEC needs to be enabled for my
> zone. To validate these record
On Sat, Jul 25, 2020 at 08:20:21PM +0900, YASUOKA Masahiko wrote:
> Currently SO_BINDANY is usable without any divert or divert-reply
> rule.
This is why we have the divert-reply feature. Just mark the states
with that keyword when you want to use them with SO_BINDANY.
See man setsockopt
Is tha
Hi,
# let me correct the previous mail, it has some typos.
Currently SO_BINDANY is usable without any divert or divert-reply
rule.
pf reserves its associated PCB to its state when the packet is going
out. This time, the pf rule is not required to have "divert" or
"divert-reply" option. When re
Hi,
Currently SO_BINDANY is usable without any divert or divert-reply
rule.
pf reserves its associated PCB to its state when the packet is going
out. This time, the pf rule is not required to have "divert" or
"divert-reply" option. When receiving reverse direction packets,
those packets are goi
Hi,
When an unicast address is specified for carppeer, if the peer is
down, sending out advertisemnent packets will fail, this failure is
treated as an error of the sending host, then the error counter is
incremented and carpdemote is incremenated. I think this is not
correct because the failure
27 matches
Mail list logo
