On Sat, Sep 03, 2022 at 06:12:16PM +, Klemens Nanni wrote:
> The current text is badly formatted and incomplete as to which optional
> parts can be omitted in which way
>
> The file specification used is of the form:
> promdev:partition/filename options
> where:
On Sat, Sep 03, 2022 at 05:33:01PM -0500, Scott Cheloha wrote:
> On Sat, Sep 03, 2022 at 10:37:31PM +1000, Jonathan Gray wrote:
> > On Sat, Sep 03, 2022 at 06:52:20AM -0500, Scott Cheloha wrote:
> > > > On Sep 3, 2022, at 02:22, Jonathan Gray wrote:
> > > >
> > > > ???On Fri, Sep 02, 2022 at
On 2022/09/03 21:37, Marcus Glocker wrote:
> On Sat, Sep 03, 2022 at 05:43:25PM +0200, Caspar Schutijser wrote:
>
> > Hi,
> >
> > On Sat, Sep 03, 2022 at 05:00:00PM +0200, Stefan Hagen wrote:
> > > This is a better version of an earlier attempt to make my wacom tablet
> > > work. I have the
> On 3 Sep 2022, at 23:47, Alexander Bluhm wrote:
>
> Hi,
>
> The next small step towards parallel network stack is to use shared
> netlock in soreceive(). The UDP and IP divert layer provide locking
> of the PCB. If that is possible, use shared instead of exclusive
> netlock in soreceive().
Hello tech@,
commit r1.9 removed the rc_exec call in iked's rc_pre. Because of that,
the exit code of rc_pre is that of the && list. In the case of
sasyncd_flags=NO, this means that rc_pre fails and triggers the break
in the while true loop in rc_cmd start case. I solved this using the
same
On Sat, Sep 03, 2022 at 10:37:31PM +1000, Jonathan Gray wrote:
> On Sat, Sep 03, 2022 at 06:52:20AM -0500, Scott Cheloha wrote:
> > > On Sep 3, 2022, at 02:22, Jonathan Gray wrote:
> > >
> > > ???On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> > >> dv@ suggested coming to the
On Sat, Sep 03, 2022 at 10:29:14PM +0300, Vitaliy Makkoveev wrote:
> The last one.
>
> As for the previous PRU_SOCKADDR, introduce in{,6}_peeraddr() and use it
> for inet and inet sockets, except tcp(4).
>
> Also remove *_usrreq() handlers. This makes diff bigger, but I guess we
> don't want to
> On 4 Sep 2022, at 00:56, Alexander Bluhm wrote:
>
> On Sat, Sep 03, 2022 at 11:20:17PM +0200, Hrvoje Popovski wrote:
>> with this diff while booting I'm getting this witness trace
>
> It is not related to soreceive() diff, but TCP diff I commited
> before. I forgot a mutex initalization
On Sat, Sep 03, 2022 at 11:20:17PM +0200, Hrvoje Popovski wrote:
> with this diff while booting I'm getting this witness trace
It is not related to soreceive() diff, but TCP diff I commited
before. I forgot a mutex initalization which is fatal with witness.
Fix below.
bluhm
Index:
On 3.9.2022. 22:47, Alexander Bluhm wrote:
> Hi,
>
> The next small step towards parallel network stack is to use shared
> netlock in soreceive(). The UDP and IP divert layer provide locking
> of the PCB. If that is possible, use shared instead of exclusive
> netlock in soreceive(). The PCB
On Sat, Sep 03, 2022 at 08:42:53PM +, Job Snijders wrote:
> Found a small todo item in proc_parser() to free the entries in the auth
> and crl trees.
Reworked the diff to retain RB_GENERATE_STATIC() scope
OK?
Index: cert.c
===
Hi,
The next small step towards parallel network stack is to use shared
netlock in soreceive(). The UDP and IP divert layer provide locking
of the PCB. If that is possible, use shared instead of exclusive
netlock in soreceive(). The PCB mutex provides a per socket lock
against multiple
Found a small todo item in proc_parser() to free the entries in the auth
and crl trees.
OK?
Kind regards,
Job
Index: cert.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/cert.c,v
retrieving revision 1.88
diff -u -p -r1.88 cert.c
---
The last one.
As for the previous PRU_SOCKADDR, introduce in{,6}_peeraddr() and use it
for inet and inet sockets, except tcp(4).
Also remove *_usrreq() handlers. This makes diff bigger, but I guess we
don't want to commit code like below:
rip_usrreq(struct socket *so, int req, struct mbuf *m,
On Sat, Sep 03, 2022 at 05:43:25PM +0200, Caspar Schutijser wrote:
> Hi,
>
> On Sat, Sep 03, 2022 at 05:00:00PM +0200, Stefan Hagen wrote:
> > This is a better version of an earlier attempt to make my wacom tablet
> > work. I have the tablet here in Bad Liebenzell if you want to give it a
> >
The current text is badly formatted and incomplete as to which optional
parts can be omitted in which way
The file specification used is of the form:
promdev:partition/filename options
where: “promdev” is an optional Open Firmware device name (such as “hd”
or
Theo de Raadt wrote:
> In this version of the diff, the kernel manages to mark immutable most of
> the main binary, and in the shared-binary case, also most of ld.so. But it
> cannot mark all of the ELF mapping -- because of two remaining problems (RELRO
> in .data, and the malloc.c
On Sat, Sep 03, 2022 at 02:32:55PM +, Klemens Nanni wrote:
> The softraid(4) example could also use
> echo 'raid 1m-* 100%' | disklabel -wAT/dev/stdin wd1
>
> but that's not as clear as
> echo 'RAID 1M-* 100%' > template
> disklabel -wAT template wd1
>
> Feedback? OK?
>
On Sat, Sep 03, 2022 at 08:55:51AM +, Mikolaj Kucharski wrote:
> Hi,
>
> I tried to address what jmc@ mentioned below. I don't really know
> mdoc(7) and English is not my native language, so I imagine there is
> place for improvement in the wg(4) diff.
>
hi.
after looking again, i think
Hi,
On Sat, Sep 03, 2022 at 05:00:00PM +0200, Stefan Hagen wrote:
> This is a better version of an earlier attempt to make my wacom tablet
> work. I have the tablet here in Bad Liebenzell if you want to give it a
> spin (on my or on your machine).
>
> Comments? OK?
I don't feel entirely
The softraid(4) example could also use
echo 'raid 1m-* 100%' | disklabel -wAT/dev/stdin wd1
but that's not as clear as
echo 'RAID 1M-* 100%' > template
disklabel -wAT template wd1
Feedback? OK?
Index: sbin/disklabel/disklabel.8
On Fri, Sep 02, 2022 at 07:03:54PM +0200, YASUOKA Masahiko wrote:
> The diff already considers that situation.
You explanation makes sense.
> > I am running regress test with diff right now, we will see if it
> > still works.
Regress passes.
OK bluhm@
> >> Index: sys/net/pf.c
> >>
On Sat, Sep 03, 2022 at 03:39:00AM +0300, Vitaliy Makkoveev wrote:
> Since we are not the special case where we have no resource allocation
> in runtime, because all required resources are pre-allocated by design,
During packet processing we do not wait, but drop the packet.
Network semantics
ok yasuoka
On Fri, 2 Sep 2022 14:44:29 +0200
Alexander Bluhm wrote:
> + now = READ_ONCE(tcp_now);
> +
> /*
>* Determine length of data that should be transmitted,
>* and flags that will be used.
> @@ -228,7 +231,7 @@ tcp_output(struct tcpcb *tp)
>* to send, then
On Sat, Sep 03, 2022 at 01:08:35PM +, Job Snijders wrote:
> RPKI Trust Anchors (self-signed root certificates) MAY NOT contain
> 'inherit' elements in their RFC 3779 resource extensions according to
> RFC 6490 section 2.2.
>
> We could check way earlier on in the validation process whether
RPKI Trust Anchors (self-signed root certificates) MAY NOT contain
'inherit' elements in their RFC 3779 resource extensions according to
RFC 6490 section 2.2.
We could check way earlier on in the validation process whether the TA
certificate conforms to this constraint. The below changeset moves
> On Sep 3, 2022, at 07:37, Jonathan Gray wrote:
>
> On Sat, Sep 03, 2022 at 06:52:20AM -0500, Scott Cheloha wrote:
On Sep 3, 2022, at 02:22, Jonathan Gray wrote:
>>>
>>> On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
dv@ suggested coming to the list to request
On Sat, Sep 03, 2022 at 06:52:20AM -0500, Scott Cheloha wrote:
> > On Sep 3, 2022, at 02:22, Jonathan Gray wrote:
> >
> > On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> >> dv@ suggested coming to the list to request testing for the pvclock(4)
> >> driver. Attached is a patch
On Fri, Aug 26, 2022 at 09:12:59AM +, Klemens Nanni wrote:
> installboot(8) runs newfs_msdos(8) via system(3) but only checks failures
> of the function itself, always returning zero no matter what newfs_msdos
> returned.
>
> This is bad for regress tests relying on correct return codes.
On Sat, Sep 03, 2022 at 01:49:27AM +0200, Moritz Buhl wrote:
> Here is an updated version of the kernel part for sendmmsg.
OK bluhm@
> Index: sys/kern/syscalls.master
> ===
> RCS file:
> On Sep 3, 2022, at 02:22, Jonathan Gray wrote:
>
> On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
>> dv@ suggested coming to the list to request testing for the pvclock(4)
>> driver. Attached is a patch that corrects several bugs. Most of
>> these changes will only matter in
After these changes, OpenBSD VMware guest's clock is galloping into the
future like this:
Aug 31 02:42:18 build ntpd[55904]: adjusting local clock by -27.085360s
Aug 31 02:44:26 build ntpd[55904]: adjusting local clock by -116.270573s
Aug 31 02:47:40 build ntpd[55904]: adjusting local clock by
On Sat, Sep 03, 2022 at 01:27:03PM +0200, Theo Buehler wrote:
> On Sat, Sep 03, 2022 at 01:18:13PM +0200, Claudio Jeker wrote:
> > This diff adds the parentid to struct cert. The parentid is the id of the
> > repository the cert lives in. This information will be used to track the
> > parent
On Sat, Sep 03, 2022 at 01:18:13PM +0200, Claudio Jeker wrote:
> This diff adds the parentid to struct cert. The parentid is the id of the
> repository the cert lives in. This information will be used to track the
> parent repository in the repositories list/tree.
>
> The naming is confusing and
This diff adds the parentid to struct cert. The parentid is the id of the
repository the cert lives in. This information will be used to track the
parent repository in the repositories list/tree.
The naming is confusing and I'm happy for better suggestions.
--
:wq Claudio
Index: cert.c
Already had an OK dv@ for a slightly older version, but I found a issue
with reloading after and would like to give other people a chance to
give their input.
To test simply put the agentx keyword in both snmpd.conf and vm.conf and
walk over mib-2.236 (or in quirky snmp(1) terms mib_2.236)
Hi,
I wanted to rm -rP some files on my disk and didn't notice that
they lacked write permission for the user who executed rm(1)
command.
$ echo foo > file-mode-444.txt
$ chmod 0444 file-mode-444.txt
$ ls -ln file-mode-444.txt
-r--r--r-- 1 5001 5001 4 Sep 3 09:36 file-mode-444.txt
$ rm -vfP
On Sat, Sep 03, 2022 at 11:12:41AM +0200, Claudio Jeker wrote:
> Instead of passing the repo to queue_from_mft() do the lookup in the
> function.
Looks like a simplification missed in a previous refactor.
ok
Instead of passing the repo to queue_from_mft() do the lookup in the
function.
--
:wq Claudio
Index: main.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
retrieving revision 1.218
diff -u -p -r1.218 main.c
--- main.c 2
Hi,
I tried to address what jmc@ mentioned below. I don't really know
mdoc(7) and English is not my native language, so I imagine there is
place for improvement in the wg(4) diff.
Full diff at the very end of this email, below here `diff -wu` to
visualize how minimal ifconfig.c changes are:
|
Diff below makes it possible for ikbd(4) to become the console. This
in turn means it is usable in DDB. This probably needs a little bit
of testing. If you have an (amd64) laptop with ikbd(4), please give
this a go and report whether it still works.
ok?
Index: dev/i2c/ihidev.h
> Date: Sat, 3 Sep 2022 09:31:39 +0200
> From: Marcus Glocker
>
> On Tue, Aug 30, 2022 at 07:17:19AM +0200, Marcus Glocker wrote:
>
> > Periodic transfers on dwctwo(4) work very unreliable today. If I want
> > to use my RPI3B+ as a workstation, the keyboard is working so
> > unreliable, I
On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> dv@ suggested coming to the list to request testing for the pvclock(4)
> driver. Attached is a patch that corrects several bugs. Most of
> these changes will only matter in the non-TSC_STABLE case on a
> multiprocessor VM.
>
>
On Tue, Aug 30, 2022 at 07:17:19AM +0200, Marcus Glocker wrote:
> Periodic transfers on dwctwo(4) work very unreliable today. If I want
> to use my RPI3B+ as a workstation, the keyboard is working so
> unreliable, I can't hardly log-in to X. Playing USB audio isn't fun
> either.
>
> After
On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> dv@ suggested coming to the list to request testing for the pvclock(4)
> driver. Attached is a patch that corrects several bugs. Most of
> these changes will only matter in the non-TSC_STABLE case on a
> multiprocessor VM.
>
>
On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> dv@ suggested coming to the list to request testing for the pvclock(4)
> driver. Attached is a patch that corrects several bugs. Most of
> these changes will only matter in the non-TSC_STABLE case on a
> multiprocessor VM.
>
>
46 matches
Mail list logo
