On 12/18/19, m...@netbsd.org <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 <mjguzik gmail.com>
