Re: CVS commit: src/sys
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
Re: CVS commit: src
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
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
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/sys/sys
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/uvm
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/sys/uvm
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
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.
