On Tue, Sep 22, 2020 at 10:03:29PM +0200, Klemens Nanni wrote:
> We have never been able to remove an rtable; until claudio moved them
> explicitly with rtable_l2set() in if_loop.c:loop_clone_destroy(), i.e.
>
> revision 1.90
> date: 2020/01/08 09:09:10; author: claudio; state:
On Tue, Sep 22, 2020 at 08:54:31PM +0200, Klemens Nanni wrote:
> It's handy and otherwise easily missed when reading up on routing
> domains and tables; wording taken from netstat(1) as is.
>
> Not listing pgrep(1)'s `-T' because examples don't have to be exhaustive
> and ps(1) is already
On Tue, Sep 22, 2020 at 08:54:31PM +0200, Klemens Nanni wrote:
> It's handy and otherwise easily missed when reading up on routing
> domains and tables; wording taken from netstat(1) as is.
>
> Not listing pgrep(1)'s `-T' because examples don't have to be exhaustive
> and ps(1) is already
We have never been able to remove an rtable; until claudio moved them
explicitly with rtable_l2set() in if_loop.c:loop_clone_destroy(), i.e.
revision 1.90
date: 2020/01/08 09:09:10; author: claudio; state: Exp; lines: +6 -2;
In loop_clone_destroy() reset the rdomain
It also lacks SENSOR_UNUSEDFEATURES.
No.
Paul de Weerd wrote:
> Hi all,
>
> While browsing sensorsd.c for inspiration for a small project I'm
> working on, I noticed that both src/usr.sbin/sensorsd/sensorsd.c and
> src/sbin/sysctl/sysctl.c have a 'print_sensor' function that
> returns/prints
It's handy and otherwise easily missed when reading up on routing
domains and tables; wording taken from netstat(1) as is.
Not listing pgrep(1)'s `-T' because examples don't have to be exhaustive
and ps(1) is already demonstrated; same for top(1) users which more
likely come across its `t' and
Hello,
I couldn't but notice that the requirements on softraid level 1 in
base OpenBSD are actually lower than what the current user interface
returns.
The proposed patch does two things :
- It relaxes the check for number of chunks for raid level 1 in the kernel
- it allows building a level 1
> Date: Tue, 22 Sep 2020 10:37:40 +0200
> From: Martin Pieuchot
>
> On 22/09/20(Tue) 10:20, Mark Kettenis wrote:
> > > Date: Tue, 22 Sep 2020 09:15:00 +0200
> > > From: Martin Pieuchot
> > >
> > > Spell inline correctly, also reduce the diff with NetBSD for uvm_amap.c
> > > and uvm_fault.c.
>
On 22/09/20(Tue) 10:20, Mark Kettenis wrote:
> > Date: Tue, 22 Sep 2020 09:15:00 +0200
> > From: Martin Pieuchot
> >
> > Spell inline correctly, also reduce the diff with NetBSD for uvm_amap.c
> > and uvm_fault.c.
> >
> > ok?
>
> In general, yes. This might interfere with the diff that
> Date: Tue, 22 Sep 2020 09:15:00 +0200
> From: Martin Pieuchot
>
> Spell inline correctly, also reduce the diff with NetBSD for uvm_amap.c
> and uvm_fault.c.
>
> ok?
In general, yes. This might interfere with the diff that guenther@
did a while ago to lock amaps and unlock more of uvm. Now
> Date: Tue, 22 Sep 2020 09:51:03 +0200
> From: Martin Pieuchot
>
> Allocations in the various pmap_enter(9) are done with uvm_pagealloc(9),
> which sets the UVM_PLA_NOWAIT flag, and/or with pool_get(9) w/ PR_NOWAIT.
>
> So the comment below seems outdated to me, ok to kill it?
This matches my
ok mvs
> On 22 Sep 2020, at 10:15, Martin Pieuchot wrote:
>
> Spell inline correctly, also reduce the diff with NetBSD for uvm_amap.c
> and uvm_fault.c.
>
> ok?
>
> Index: uvm/uvm_addr.c
> ===
> RCS file:
Allocations in the various pmap_enter(9) are done with uvm_pagealloc(9),
which sets the UVM_PLA_NOWAIT flag, and/or with pool_get(9) w/ PR_NOWAIT.
So the comment below seems outdated to me, ok to kill it?
Index: uvm/uvm_fault.c
===
Spell inline correctly, also reduce the diff with NetBSD for uvm_amap.c
and uvm_fault.c.
ok?
Index: uvm/uvm_addr.c
===
RCS file: /cvs/src/sys/uvm/uvm_addr.c,v
retrieving revision 1.28
diff -u -p -r1.28 uvm_addr.c
--- uvm/uvm_addr.c
14 matches
Mail list logo
