Re: CVS commit: src
Answering quickly: Le 18/12/2019 à 21:24, Taylor R Campbell a écrit : Module Name:src Committed By: maxv Date: Wed Dec 18 07:37:19 UTC 2019 Log Message: Retire filemon, discussed on tech-kern@. Please refrain from taking unilateral actions such as things you don't like without reasonable discussion. I think you meant to say "REMOVING things you don't like". I removed it after quick discussion, and taking into account the fact that filemon was completely killed by secteam with no discussion either. - Nobody skimming tech-kern by subject line would reasonably expect that a thread titled `[filemon] CVS commit: htdocs/support/security' is the place to find a proposal of deletion on 18h notice. See below - Nothing in the thread was actually a proposal for discussion -- just an announcement that you have taken a unilateral decision to remove it. The first paragraph of the first email of this thread is literally a question I'm asking to other people. "announcement of unilateral decision" is about as dishonest and mischaracterizing as it can get. Disappointing, but not unexpected. - And since the module is gone and the pseudo-device is disabled by default, no unilateral emergency action is warranted, even it turns out under discussion that there is community consensus that filemon should be removed from the tree. Maybe it could have occurred to you that it is precisely because this feature has been completely killed already that I moved forward and deleted it, after very quick discussion indeed? But see below Please revert the filemon deletion and ensure the tree builds within the next 24h. I have reverted the bmake change, because Maya's concern (about diff against FreeBSD) is legitimate, at least for the time being. If you want to see filemon deleted, you can raise the subject _after_ you have reverted the commits. You mean like, following the removal procedure core has already failed to abide by in the past? In fact, maybe we should agree once and for all on the actual procedure, and ALL accept to abide by it, INCLUDING core. What do you think? In the meantime, I have absolutely no intent to reinstate filemon. You can reinstate it if you want, but it should come as no surprise to you in the near future that filemon, after whatever "necessary" discussion or different forms of bureaucratic idiocy you want to throw at it, will be deleted almost as fast as it came back from the attic. Especially considering the emails sent from the other people since I proceeded. Maxime
Re: CVS commit: src/usr.bin/crunch/crunchgen
On Wed, Dec 18, 2019 at 03:51:21PM -, Christos Zoulas wrote: > In article <20191218152113.ga7...@bec.de>, > Joerg Sonnenberger wrote: > >On Tue, Dec 17, 2019 at 09:16:04PM -0500, Christos Zoulas wrote: > >> Module Name: src > >> Committed By: christos > >> Date: Wed Dec 18 02:16:04 UTC 2019 > >> > >> Modified Files: > >>src/usr.bin/crunch/crunchgen: crunchgen.1 crunchgen.c > >> > >> Log Message: > >> Also disable ssp and fortify by default. > > > >Why? > > Size reduction on install media. There are flags to turn it on. Not all users of crunchgen are space constrained, so this seems like a bad default to me. Joerg
Re: CVS commit: src
> Module Name:src > Committed By: maxv > Date: Wed Dec 18 07:37:19 UTC 2019 > > Log Message: > Retire filemon, discussed on tech-kern@. Please refrain from taking unilateral actions such as things you don't like without reasonable discussion. - Nobody skimming tech-kern by subject line would reasonably expect that a thread titled `[filemon] CVS commit: htdocs/support/security' is the place to find a proposal of deletion on 18h notice. - Nothing in the thread was actually a proposal for discussion -- just an announcement that you have taken a unilateral decision to remove it. - And since the module is gone and the pseudo-device is disabled by default, no unilateral emergency action is warranted, even it turns out under discussion that there is community consensus that filemon should be removed from the tree. Please revert the filemon deletion and ensure the tree builds within the next 24h. If you want to see filemon deleted, you can raise the subject _after_ you have reverted the commits. Thanks, -Riastradh, on behalf of core.
Re: CVS commit: src
On 12/18/19, m...@netbsd.org wrote: > On Wed, Dec 18, 2019 at 06:47:44AM -0500, Christos Zoulas wrote: >> While there was no discussion, it is more efficient to have the >> discussion >> whether we should put it back or not (instead of putting it back first >> and >> having the discussion). Of course we should fix the build first since it >> seems >> to be broken. >> >> The reality of the situation is that the syscall race has been there for >> months >> and nobody has taken responsibility to fix it. The code is in version >> control, >> so someone should fix it first and then we can discuss if we should bring >> it >> back. > > > I'd like to also publicly object to the removal of the code from bmake > (I responded privately at first). > FreeBSD has filemon, and I suspect it has more acceptance there, but > maxv stated he will propose it. > Sharing the code with FreeBSD is more than worth the 200 unused-by-us > lines of code, and it's already optional. > No rush though. Let's wait to see what they say. > > I have no objections to removing the kernel module. > filemon in FreeBSD was significantly reworked to make it stable and reasonably performant, but I would not necessarily refer to it as "accepted". Cursory look suggests many of the bugs which got fixed there still linger in NetBSD's variant. I don't know if the functionality provided for bmake is the right approach to whatever it is used for. Assuming it makes sense, a significantly better pick would be ktrace. Currently it exports more data than bmake requires (and in a different format), but that should be easily fixable. The only time consuming part would be makign ktrace itself scale to multiple CPUs. I think working on that is a much better use of time than beating filemon to production shape. In fact design fixes would make it more ktrace-y (for instance actual per-process state which is strongly tied to their liveness, as opposed to just storing a pid somewhere and looking stuff up). Note the work at hand can be done in a way where it is almost a drop-in replacement. FreeBSD should follow suit. -- Mateusz Guzik
Re: CVS commit: src
On Wed, Dec 18, 2019 at 06:47:44AM -0500, Christos Zoulas wrote: > While there was no discussion, it is more efficient to have the discussion > whether we should put it back or not (instead of putting it back first and > having the discussion). Of course we should fix the build first since it seems > to be broken. > > The reality of the situation is that the syscall race has been there for > months > and nobody has taken responsibility to fix it. The code is in version control, > so someone should fix it first and then we can discuss if we should bring it > back. I'd like to also publicly object to the removal of the code from bmake (I responded privately at first). FreeBSD has filemon, and I suspect it has more acceptance there, but maxv stated he will propose it. Sharing the code with FreeBSD is more than worth the 200 unused-by-us lines of code, and it's already optional. No rush though. Let's wait to see what they say. I have no objections to removing the kernel module.
Re: CVS commit: src/usr.bin/crunch/crunchgen
In article <20191218152113.ga7...@bec.de>, Joerg Sonnenberger wrote: >On Tue, Dec 17, 2019 at 09:16:04PM -0500, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Wed Dec 18 02:16:04 UTC 2019 >> >> Modified Files: >> src/usr.bin/crunch/crunchgen: crunchgen.1 crunchgen.c >> >> Log Message: >> Also disable ssp and fortify by default. > >Why? Size reduction on install media. There are flags to turn it on. christos
Re: CVS commit: src/usr.bin/crunch/crunchgen
On Tue, Dec 17, 2019 at 09:16:04PM -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Wed Dec 18 02:16:04 UTC 2019 > > Modified Files: > src/usr.bin/crunch/crunchgen: crunchgen.1 crunchgen.c > > Log Message: > Also disable ssp and fortify by default. Why? Joerg
Re: CVS commit: src
While there was no discussion, it is more efficient to have the discussion whether we should put it back or not (instead of putting it back first and having the discussion). Of course we should fix the build first since it seems to be broken. The reality of the situation is that the syscall race has been there for months and nobody has taken responsibility to fix it. The code is in version control, so someone should fix it first and then we can discuss if we should bring it back. christos > On Dec 18, 2019, at 4:58 AM, John Nemeth wrote: > > On Dec 18, 7:37am, "Maxime Villard" wrote: > } > } This is a multi-part message in MIME format. > } > } --_--=_1576654639170820 > } Content-Disposition: inline > } Content-Transfer-Encoding: 8bit > } Content-Type: text/plain; charset="US-ASCII" > } > } Module Name:src > } Committed By: maxv > } Date: Wed Dec 18 07:37:19 UTC 2019 > } > } Modified Files: > } src/distrib/sets/lists/base: mi > } src/distrib/sets/lists/comp: mi > } src/distrib/sets/lists/man: mi > } src/etc: MAKEDEV.tmpl > } src/etc/mtree: NetBSD.dist.base > } src/share/man/man4: Makefile > } src/sys/arch/amd64/conf: ALL > } src/sys/arch/i386/conf: ALL > } src/sys/conf: files majors > } src/sys/dev: Makefile > } src/sys/modules: Makefile > } src/usr.bin/make: Makefile compat.c make.1 meta.c > } src/usr.sbin/makemandb: nostem.txt > } Removed Files: > } src/share/man/man4: filemon.4 > } src/sys/dev/filemon: Makefile filemon.c filemon.h filemon_wrapper.c > } mknod-sh > } src/sys/modules/filemon: Makefile filemon.ioconf > } > } Log Message: > } Retire filemon, discussed on tech-kern@. > > What discussion? In a message dated, Tue Dec 17 13:58:19 > 2019, you stated, "I will prepare the removal of filemon." That > doesn't exactly look like a proposal to me. After that, I don't > see any discussion about its removal. > >Please revert this commit, make a proper proposal and allow > for a proper discussion as per the policy for removing features. > > }-- End of excerpt from "Maxime Villard" signature.asc Description: Message signed with OpenPGP
Re: CVS commit: src
On Dec 18, 7:37am, "Maxime Villard" wrote: } } This is a multi-part message in MIME format. } } --_--=_1576654639170820 } Content-Disposition: inline } Content-Transfer-Encoding: 8bit } Content-Type: text/plain; charset="US-ASCII" } } Module Name: src } Committed By: maxv } Date: Wed Dec 18 07:37:19 UTC 2019 } } Modified Files: } src/distrib/sets/lists/base: mi } src/distrib/sets/lists/comp: mi } src/distrib/sets/lists/man: mi } src/etc: MAKEDEV.tmpl } src/etc/mtree: NetBSD.dist.base } src/share/man/man4: Makefile } src/sys/arch/amd64/conf: ALL } src/sys/arch/i386/conf: ALL } src/sys/conf: files majors } src/sys/dev: Makefile } src/sys/modules: Makefile } src/usr.bin/make: Makefile compat.c make.1 meta.c } src/usr.sbin/makemandb: nostem.txt } Removed Files: } src/share/man/man4: filemon.4 } src/sys/dev/filemon: Makefile filemon.c filemon.h filemon_wrapper.c } mknod-sh } src/sys/modules/filemon: Makefile filemon.ioconf } } Log Message: } Retire filemon, discussed on tech-kern@. What discussion? In a message dated, Tue Dec 17 13:58:19 2019, you stated, "I will prepare the removal of filemon." That doesn't exactly look like a proposal to me. After that, I don't see any discussion about its removal. Please revert this commit, make a proper proposal and allow for a proper discussion as per the policy for removing features. }-- End of excerpt from "Maxime Villard"
