Re: CVS commit: src

[Mateusz Guzik <mjguzik%gmail.com@localhost>]

On 12/18/19, maya%netbsd.org@localhost <maya%netbsd.org@localhost> 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>