tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposal: Remove filemon(4); switch make meta to ktrace



> Date: Mon, 13 Jan 2020 06:09:20 -0500 (EST)
> From: Mouse <mouse%Rodents-Montreal.ORG@localhost>
> 
> > - What instead?  The attached patch (patch set make-meta-v2.patch;
> >   combined diff make-meta-v2.diff) replaces make's use of
> >   /dev/filemon by ktrace, in meta mode.
> 
> How does this interact with someone ktracing a make run?  If it that
> breaks make, I think this is a very bad idea; if it breaks the user's
> ktrace, I think it is a moderately bad idea.  (I haven't had to ktrace
> make very often, but when I have there hasn't been much else that would
> be suitable.)

Like filemon(4), ktrace does not currently nest -- if a process being
ktraced to /tmp/foo issues ktrace(2) to /tmp/bar, then /tmp/foo stops
getting ktrace output from it.

In principle this could be changed -- by allowing a process to be
ktraced many times and broadcasting events to all of them -- and we do
maintain and regularly exercise ktrace so perhaps it's less likely to
have security and correctness issues than filemon(4).

In practice I don't know how important this is.  This affects only
make _meta_ mode, which you have to turn on explicitly anyway, and
which does some additional automatic dependency recording (based on
the command invocation so that it will (e.g.) pick up changes to
CFLAGS, and based on syscalls so that it will pick up dependencies you
missed).

If you use make meta mode _and_ you want to ktrace a make recipe, you
could either stop turning make meta mode on, or use ktrace(1) directly
in the recipe itself.  If neither of those work, then maybe we should
adapt ktrace to support many simultaneous ktraces of a single process,
but I don't want to commit more resources to maintaining that unless
we have a real need.


Home | Main Index | Thread Index | Old Index