Re: [PATCH 0/2] utrace

[Christoph Hellwig <hch@infradead.org>]

On Wed, Aug 27, 2008 at 07:34:22PM +0400, Alexey Dobriyan wrote:
> On Tue, Aug 26, 2008 at 08:17:12PM -0400, Frank Ch. Eigler wrote:
> > Alexey Dobriyan <adobriyan@gmail.com> writes:
> > 
> > > [...]  And some internal details still horrible and overdesigned
> > > just like at the very beginning.
> > 
> > Please point out specific areas, and I'm sure there will be a reasonable
> > explanation why they turned out this way.
> > 
> > As for whether "struct utrace" should be a member of vs. pointed-to
> > from task_struct, it may come down to the perceived need to avoid
> > penalizing every thread with a hundred-odd bytes extra, whether or not
> > they are being utrace-controlled.
> 
> Yes, that's your price for avoiding more races, more code, more races,
> more tricky code and ultimately more ways to fsckup.
> 
> God, you're in the very tricky Unix subsystem only a few people know
> intimately, and what we see? utrace code is just as tricky.
> 
> When you're confident that interaction with engines part is fine, all
> stupid bugs were fixed, go change struct utrace to pointer. Now it can
> very well be a lie to say less memory is used because slab allocator
> rounds up sizes to certain degree.

Yes.  And btw, the early utrace patches actually moved the ptrace
state into dynamically allocated per engine state, which would almost
cancel out the additional members required for utrace.  I'm not sure
why this went away in the meantime.