On Tue, Jul 26, 2022 at 09:18:47PM -0500, Scott Cheloha wrote:
> A few improvements I want to make to the sleep(1) manpage.
>
> DESCRIPTION
>
> - "for a minimum of" is better said "for at least".
>
hi.
i can;t really distinguish between one form being better than the other.
"until at least" is
A few improvements I want to make to the sleep(1) manpage.
DESCRIPTION
- "for a minimum of" is better said "for at least".
- The seconds argument can be zero, so say "non-negative".
- Specify that the number (the whole thing) is decimal to exclude
e.g. hex numbers. It then follows that the o
On Fri, Jul 22, 2022 at 01:38:16PM -0500, Scott Cheloha wrote:
> Hi,
>
> As promised, here is the timeout.9 manpage rewrite I've been sitting
> on. I am pretty sure jmc@ (and maybe schwarze@) read an earlier
> version of this. It has drifted a bit since then, but not much.
No general mandoc iss
On Sun, Jul 24, 2022 at 10:34:04AM -0700, Andrew Hewus Fresh wrote:
> On Sun, Jul 24, 2022 at 09:14:30AM -0700, Andrew Hewus Fresh wrote:
> > On Sun, Jul 24, 2022 at 10:01:26AM -0600, Theo de Raadt wrote:
> > > Jonathan Gray wrote:
> > >
> > > > On Sun, Jul 24, 2022 at 08:05:26AM -0600, Theo de R
On Tue, Jul 26, 2022 at 11:19:27PM +0200, Mark Kettenis wrote:
> > Date: Tue, 26 Jul 2022 18:11:01 +0200
> > From: Alexander Bluhm
> >
> > On Fri, Jul 22, 2022 at 06:13:04PM +0200, Alexander Bluhm wrote:
> > > But I am fine with committing ifmedia, gem(4) and bge(4) now. Then
> > > we can decide
> Date: Tue, 26 Jul 2022 18:11:01 +0200
> From: Alexander Bluhm
>
> On Fri, Jul 22, 2022 at 06:13:04PM +0200, Alexander Bluhm wrote:
> > But I am fine with committing ifmedia, gem(4) and bge(4) now. Then
> > we can decide on a per driver basis. As long kernel lock is not
> > removed from the if
Thank you so very much!! that was very insightful about looking at the source
for fstat. I Have code the checks for the correct ino_t and dev_t now thanks to
you.
Here's what I'm doing for those interested in seeing:
https://github.com/time-killer-games/xproc/commit/03a643a7d33e679994f4896acfca7
On Fri, Jul 15, 2022 at 12:27:04PM -0400, Dave Voutila wrote:
> The following diff adds in formalization around mmio assists for nested
> page/ept faults on Intel and AMD vmm(4) hosts. It provides what little
> information is available to userland in terms of either the instruction
> bytes (on AMD)
On Tue, Jul 26, 2022 at 06:11:01PM +0200, Alexander Bluhm wrote:
> On Fri, Jul 22, 2022 at 06:13:04PM +0200, Alexander Bluhm wrote:
> > But I am fine with committing ifmedia, gem(4) and bge(4) now. Then
> > we can decide on a per driver basis. As long kernel lock is not
> > removed from the ifmed
ok by me
> On 26 Jul 2022, at 19:11, Alexander Bluhm wrote:
>
> On Fri, Jul 22, 2022 at 06:13:04PM +0200, Alexander Bluhm wrote:
>> But I am fine with committing ifmedia, gem(4) and bge(4) now. Then
>> we can decide on a per driver basis. As long kernel lock is not
>> removed from the ifmedia
On Tue, Jul 26, 2022 at 07:04:36PM +0200, Claudio Jeker wrote:
> This is what I have in mind for that.
Yep, same here.
ok
>
> --
> :wq Claudio
>
> ? obj
> Index: kroute.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/kroute.c,v
> retr
On Tue, Jul 26, 2022 at 05:35:47PM +0200, Theo Buehler wrote:
> On Tue, Jul 26, 2022 at 05:17:23PM +0200, Claudio Jeker wrote:
> > On Tue, Jul 26, 2022 at 03:51:40PM +0200, Theo Buehler wrote:
> > > On Tue, Jul 26, 2022 at 03:09:37PM +0200, Claudio Jeker wrote:
> > > > This is another step in the e
On Fri, Jul 22, 2022 at 06:13:04PM +0200, Alexander Bluhm wrote:
> But I am fine with committing ifmedia, gem(4) and bge(4) now. Then
> we can decide on a per driver basis. As long kernel lock is not
> removed from the ifmedia layer, this diff is not strictly necessary.
> I want to commit it anyw
This diff puts more fields of struct vnode under splbio(). splbio()
looks necessary with the fields that are modified through the buffer
cache because the access can happen in an interrupt context.
Wrapping LIST_EMPTY() with splbio() is probably overzealous.
However, the added splbio() calls might
On Tue, Jul 26, 2022 at 05:17:23PM +0200, Claudio Jeker wrote:
> On Tue, Jul 26, 2022 at 03:51:40PM +0200, Theo Buehler wrote:
> > On Tue, Jul 26, 2022 at 03:09:37PM +0200, Claudio Jeker wrote:
> > > This is another step in the epic kroute rework.
> > >
> > > Interfaces (kif) come with a list of k
On Tue, Jul 26, 2022 at 03:51:40PM +0200, Theo Buehler wrote:
> On Tue, Jul 26, 2022 at 03:09:37PM +0200, Claudio Jeker wrote:
> > This is another step in the epic kroute rework.
> >
> > Interfaces (kif) come with a list of kroutes attached to them which are
> > only used to track the interface st
On Tue, Jul 26, 2022 at 03:09:37PM +0200, Claudio Jeker wrote:
> This is another step in the epic kroute rework.
>
> Interfaces (kif) come with a list of kroutes attached to them which are
> only used to track the interface state and to fiddle with nexthop states.
> Now these lists are not really
This is another step in the epic kroute rework.
Interfaces (kif) come with a list of kroutes attached to them which are
only used to track the interface state and to fiddle with nexthop states.
Now these lists are not really needed. One can just validate the nexthops
without losing any relevant in
On Tue, Jul 26, 2022 at 12:44:20PM +0100, Stuart Henderson wrote:
> I tried looking for a command to do this and completely failed
> hence the ugly ps command. Do we want something like this?
I think it's useful. There's also netstat(1)' -R but that just dumps
everything without indication where
from bugs@
On 2022/07/26 13:07, Theo Buehler wrote:
> On Tue, Jul 26, 2022 at 11:49:09AM +0100, Stuart Henderson wrote:
> > On 2022/07/25 23:41, mgra...@brainfat.net wrote:
> > > >Description:
> > > This change adds the \% argument to the ksh process of the prompt. This
> > > will
> > > cause th
On Mon, Jul 25, 2022 at 07:10:25PM -0600, Theo de Raadt wrote:
> How does it hurt you?
It hasn't hurt me yet, so far eui64 is just a preference.
> Who will choose this option?
>
> Basically noone, right?
On 2022/07/25 20:08, Samuel Venable wrote:
> I have a suggestion on how to get the current executable path in OpenBSD that
> might be reliable enough and not too costly that it might be accepted for a
> future OpenBSD version.
>
> Even if it won't be accepted, I need a little help completing the
22 matches
Mail list logo
