Let me rephrase - this is the only explanation I'm going to provide:
_I_ am not going to remove it. If others feel so strongly that they
would rather remove existing functionality (as ugly as it is), then
_they_ can do the deed.
On Sat, 9 Jan 2016, Wolfgang Solfrank wrote:
Hi,
We all
On Fri, Jan 08, 2016 at 07:08:19AM +, David Holland wrote:
> On Thu, Jan 07, 2016 at 07:34:33AM +0800, Paul Goyette wrote:
> > Based on internal implementation of filemon(4), there is an ordering
> > requirement imposed on the sequence of events that occur when a process
> > using
On Sat, Jan 09, 2016 at 08:25:05AM +0100, Mateusz Guzik wrote:
> On Sat, Jan 09, 2016 at 02:25:02PM +0800, Paul Goyette wrote:
> > On Sat, 9 Jan 2016, Mateusz Guzik wrote:
> >
> > >While I don't know all the details, it is clear that the purpose would
> > >be much better served by ktrace and I
On Sat, Jan 09, 2016 at 02:25:02PM +0800, Paul Goyette wrote:
> On Sat, 9 Jan 2016, Mateusz Guzik wrote:
>
> >While I don't know all the details, it is clear that the purpose would
> >be much better served by ktrace and I would argue efforts should be
> >spent there.
>
> filemon's purpose is
avail_start/avail_end are used to keep track of the range used for
"managed pages" - PAGE_SIZE'ed pages that are added to free list and
allocated from there. Managed pages are initially added after kernel
reserves its internal, bootstrap memory region (.text, .data, ...).
In some cases kernel
Hi,
We all agree that filemon(4) is an ugly hack. It probably should never
have gotten committed. But it is there now, and there are a (very) few
use-cases. So we don't want to remove it without having a replacement
implementation.
Well, can you explain? Why would we not want to remove it
