Re: CVS commit: src/sys/uvm

2019-12-21 Thread Andrew Doran
On Sat, Dec 21, 2019 at 03:08:18PM +0100, Christoph Badura wrote:

> On Sat, Dec 21, 2019 at 12:58:26PM +, Andrew Doran wrote:
> > Modified Files:
> > src/sys/uvm: uvm_extern.h uvm_page.c
> > Log Message:
> > Add uvm_free(): returns number of free pages in system.
> 
> Can you rename this to a more descriptive name? Say uvm_free_pages() or
> something.
> 
> Also, we traditionally use xxx_free() to actually free some object and not
> return statistics.  It would be nice to spare future readers the
> confusion.

Yes that's fair enough, I see your point.  May not be today but I'll come
back to it soon.

Andrew


Re: CVS commit: src

2019-12-21 Thread maya
On Fri, Dec 20, 2019 at 06:34:31PM -0800, John Nemeth wrote:
>  I don't wish to get embroiled in this debate (even if I did
> start it by requesting the reversion).  I just want to point out
> that there is a relatively simple way disable the autoloading of
> a module.  From module(9):
> 
>The directory from which the module is loaded will be searched for
>a file with the same name as the module file, but with the suffix
>``.plist''.  If this file is found, the prop_dictionary it contains
>will be loaded and passed to the module's modcmd() routine.  If
>this prop_dictionary contains a ``noautoload'' property which is
>set to ``true'' then the system will refuse to load the module.
> 
> The simplest way to do the above is:
> 
> modload -p -b noautoload=true > .plist
> 
> }-- End of excerpt from Maxime Villard

The first proposed change was to create a .plist file.
I liked it because it didn't require running postinstall to get the fix.

It provoked a bit of disgruntled voices, a continuation tech-kern bikeshed
about the correct way to disable module auto-loading in a per-module
basis.
Not installing the module allowed to avoid having to commit changes in a
debated topic (even though I was just using the existing method).
I was feeling rushed that we didn't commit something because of the excess
discussion.

I was hoping to have something fixing the current problem and to make
the module disable method discussion continue in public.


Re: CVS commit: src/sys/uvm

2019-12-21 Thread Christoph Badura
On Sat, Dec 21, 2019 at 12:58:26PM +, Andrew Doran wrote:
> Modified Files:
>   src/sys/uvm: uvm_extern.h uvm_page.c
> Log Message:
> Add uvm_free(): returns number of free pages in system.

Can you rename this to a more descriptive name? Say uvm_free_pages() or
something.

Also, we traditionally use xxx_free() to actually free some object and not
return statistics.  It would be nice to spare future readers the
confusion.

--chris


Re: CVS commit: src

2019-12-21 Thread Maxime Villard

Le 21/12/2019 à 10:50, m...@netbsd.org a écrit :

On Fri, Dec 20, 2019 at 06:34:31PM -0800, John Nemeth wrote:

  I don't wish to get embroiled in this debate (even if I did
start it by requesting the reversion).  I just want to point out
that there is a relatively simple way disable the autoloading of
a module.  From module(9):

The directory from which the module is loaded will be searched for
a file with the same name as the module file, but with the suffix
``.plist''.  If this file is found, the prop_dictionary it contains
will be loaded and passed to the module's modcmd() routine.  If
this prop_dictionary contains a ``noautoload'' property which is
set to ``true'' then the system will refuse to load the module.

The simplest way to do the above is:

modload -p -b noautoload=true > .plist

}-- End of excerpt from Maxime Villard


The first proposed change was to create a .plist file.
I liked it because it didn't require running postinstall to get the fix.

It provoked a bit of disgruntled voices, a continuation tech-kern bikeshed
about the correct way to disable module auto-loading in a per-module
basis.
Not installing the module allowed to avoid having to commit changes in a
debated topic (even though I was just using the existing method).
I was feeling rushed that we didn't commit something because of the excess
discussion.


I see. So you unilaterally pushed a controversial change in an expeditious
move, without any form of actual public discussion and approval.

Maxime


Re: CVS commit: src

2019-12-21 Thread Maxime Villard

Le 21/12/2019 à 00:05, Taylor R Campbell a écrit :

Security-team is not perfect.  We're happy to discuss a better way to
disable filemon provisionally, and/or how to better address the
existing users if we are to delete it -- after you do as core asked
you to do to resolve the interim dispute by restoring the tree.

This is a social process.  We can work together to make it better for
everyone, but you have to be willing to work with the community,
including accepting rulings by core to resolve disputes.


I'm afraid you, Taylor, don't have a monopoly on representing the community.

It just so happens that I, too, as a regular member and also as a main
kernel developer, represent the community; and I don't think the community
is really happy with how secteam disabled filemon without discussion. The
community is likely even less happy with how it was disabled, considering
that a quick discussion has already highlighted two apparent better ways
to disable it.

It appears that core and secteam failed to work properly with the
community.

To resolve this dispute, I have proposed to revert both my removal, and
secteam's broken disabling. This gives a clear basis to start a discussion
on what to do with filemon exactly.

Is core fine with that? Or are there double standards at play here?

Maxime


Re: CVS commit: src

2019-12-21 Thread Christos Zoulas
In article <15520611-7273-9567-33a4-ff2490b2e...@m00nbsd.net>,
Maxime Villard   wrote:
>Le 21/12/2019 à 00:05, Taylor R Campbell a écrit :
>> Security-team is not perfect.  We're happy to discuss a better way to
>> disable filemon provisionally, and/or how to better address the
>> existing users if we are to delete it -- after you do as core asked
>> you to do to resolve the interim dispute by restoring the tree.
>>
>> This is a social process.  We can work together to make it better for
>> everyone, but you have to be willing to work with the community,
>> including accepting rulings by core to resolve disputes.
>
>I'm afraid you, Taylor, don't have a monopoly on representing the community.

He does represent the community since he represents core. If you
are unhappy with core@ talk to board@. If you are unhappy with
core@ and board@, get the community to vote for you in the next
elections, or get signatures to impeach them. They are the elected
leadership of the project.

>It just so happens that I, too, as a regular member and also as a main
>kernel developer, represent the community; and I don't think the community
>is really happy with how secteam disabled filemon without discussion. The
>community is likely even less happy with how it was disabled, considering
>that a quick discussion has already highlighted two apparent better ways
>to disable it.
>
>It appears that core and secteam failed to work properly with the
>community.

See above.

>To resolve this dispute, I have proposed to revert both my removal, and
>secteam's broken disabling. This gives a clear basis to start a discussion
>on what to do with filemon exactly.
>
>Is core fine with that? Or are there double standards at play here?

Core has been very clear. They've asked you to revert your commits, not
other commits. If they had been unhappy with other commits they would
have asked the committers of the other commits to revert them.

christos



Re: CVS commit: src/sys/sys

2019-12-21 Thread Alexander Nasonov
Andrew Doran wrote:
> Log Message:
> NetBSD 9.99.28 - cpu_data & UVM changes.

Wow, you bump versions faster than I compile new releases. At this
pace, we'll get to 9.99.99 in a month or two ;-)


-- 
Alex


Re: CVS commit: src/sys

2019-12-21 Thread Joerg Sonnenberger
On Fri, Dec 20, 2019 at 09:05:34PM +, Andrew Doran wrote:
> Module Name:  src
> Committed By: ad
> Date: Fri Dec 20 21:05:34 UTC 2019
> 
> Modified Files:
>   src/sys/arch/aarch64/aarch64: cpu.c cpufunc.c
>   src/sys/arch/arm/arm32: arm32_boot.c cpu.c
>   src/sys/arch/macppc/macppc: cpu.c
>   src/sys/arch/mips/mips: cpu_subr.c
>   src/sys/arch/x86/x86: cpu.c cpu_topology.c identcpu.c
>   src/sys/kern: kern_cpu.c
>   src/sys/sys: cpu.h cpu_data.h sched.h
> 
> Log Message:
> Some more CPU topology stuff:
> 
> - Use cegger@'s ACPI SRAT parsing code to figure out NUMA node ID for each
>   CPU as it is attached.

My build system panics on boot with this due to zero sized allocations
in acpisrat_refresh.

Joerg