Re: CVS commit: src
> Date: Sun, 22 Dec 2019 10:24:01 +0100 > From: Maxime Villard > > You, Martin Christos and Taylor, are trying to change subject, find > excuses, and are sending me irrelevant responses vaguely insinuating that > I should revert my change only without addressing the additional concerns > expressed repeatedly. I fail to see whether I should take these as official > core answers. > > If they are, please clearly say so. Please revert your filemon deletion and leave the existing mitigation in place for the moment pending discussion. We can address the additional concerns afterward. Thanks, -Riastradh, on behalf of core
Re: CVS commit: src/sys/sys
On 23.12.2019 01:54, Roy Marples wrote: > On 22/12/2019 22:24, Andrew Doran wrote: >> NetBSD 9.99.29 - struct mount changed. > > Just curious - does our build software cope with 3 digit for the last > number? > > Roy At least from the __NetBSD_Version__ point of view there are 4 digits unused, but it is more valuable to branch -10 earlier than going to 3-digit patchlevel. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys/sys
Roy Marples wrote: > On 22/12/2019 22:24, Andrew Doran wrote: > > NetBSD 9.99.29 - struct mount changed. > > Just curious - does our build software cope with 3 digit for the last number? https://twitter.com/needydev/status/1205585787095519234?s=20 -- Alex
Re: CVS commit: src/sys/sys
On 22/12/2019 22:24, Andrew Doran wrote: NetBSD 9.99.29 - struct mount changed. Just curious - does our build software cope with 3 digit for the last number? Roy
Re: CVS commit: src/sys/sys
On 22.12.2019 23:27, Andrew Doran wrote: > On Sat, Dec 21, 2019 at 05:23:23PM +, Alexander Nasonov wrote: > >> 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 ;-) > > There are quite a few people using modules and I don't want to screw them > over. We got into the MP game properly with NetBSD 5.0 but we're lagging > badly and as someone else observed we've been in need of many of these > changes for 10 years now. > > Andrew > Great work! Personally, I am looking forward to NUMA support, it is today in ARM embedded/servers and we are pretty marginalized. In larger x86 it is a standard for a long time now. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys/sys
On Sat, Dec 21, 2019 at 05:23:23PM +, Alexander Nasonov wrote: > 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 ;-) There are quite a few people using modules and I don't want to screw them over. We got into the MP game properly with NetBSD 5.0 but we're lagging badly and as someone else observed we've been in need of many of these changes for 10 years now. Andrew
Re: CVS commit: src/sys
Hi Joerg, On Sun, Dec 22, 2019 at 01:27:44AM +0100, Joerg Sonnenberger wrote: > 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. I missed this last night, oops. Rev 1.7 of src/sys/dev/acpi/acpi_srat.c should fix. Cheers, Andrew
Re: CVS commit: src
Le 21/12/2019 à 23:48, Christos Zoulas a écrit : 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 appears you didn't read correctly the line of mine you just quoted. 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. "If". Except that I haven't received any formal email from core. Why can't core just send a simple official email to say whether yes, or no, they are fine with me reverting secteam's change, in addition to mine? I have accepted core's ruling, but have since pointed out additional serious deficiencies with how filemon was dealt with, hence the concern on how to proceed. Core, however, has been unwilling to provide an answer and to work with the community. It's been two days of this, and I fail to see where the difficulty is. You, Martin Christos and Taylor, are trying to change subject, find excuses, and are sending me irrelevant responses vaguely insinuating that I should revert my change only without addressing the additional concerns expressed repeatedly. I fail to see whether I should take these as official core answers. If they are, please clearly say so. Maxime
