linux-kernel - Re: [PATCH 0/2] utrace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080903120927.3C1FF154228@magilla.localdomain>
Date:	Wed,  3 Sep 2008 05:09:27 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] utrace

> I hope my original mail was clear that I'm not principially against
> utrace.  I think having a generic trace even dispatcher is a good thing
> if it is a) not overly complicated (see Alexeyús mails for that) and b)
> actually has a user.  A better debugger interface as the ntrace idea
> would be the prime candidate for that.

Thanks for that clarification.  From what you've said in many of your
postings, it has been easy to get the impression that you are against
everything.

I sympathize with caution about a new API that needs users to iron out
its kinks.  Here is the difficulty I've been having.

I have spent a lot of time keeping the patch series up to date,
rebasing, etc.  This has sunk all the time that I'd like to have been
spending working on higher-level pieces such as the ntrace idea.

(This will be much better now that all the tracehook work is in 2.6.27.
I know you don't buy the rationale I've explained for that work.  But I
am confident that having this in is a substantial and immediate boon to
the ease and efficiency of getting more work done sooner in this area.)

At the same time, many of the people who have asked me about the state
of the effort say things to the effect that they would like to try
writing some features based on such an API once it's been merged in.

It was my hope that having it merged in and available as a non-default
option for those who select CONFIG_EXPERIMENTAL would encourage more
people to actually get going on experiments with new features.  Several
actual users beating on it is of course what's necessary to iron out
the API and the low-level code.

Since I finally no longer expect to spend much more time myself on arch
code or rebasing hassles given what's already merged, I look forward to
soon having time to work on some higher-level stuff that makes this all
get interesting.  Whatever I produce won't be all things to all people,
and it might not be to your taste at all.  It's certain that others who
tried could come up with some other things faster.  Having the schedule
of merging utrace contingent on having some things using it that people
consider ready to be merged won't delay me working on such a thing, but
I get the impression it might deter others.

The motivating principle of utrace is that it is the lowest level and
least overhead at which multiple disparate things can be tried, without
clobbering each other, and easily enough that many kernel hackers can
find it easier to whip up something useful than to write horrible bugs
while trying.  The idea of merging it after review and revision on its
own merits is to get more of us active in making and disagreeing about
concrete things using it and whether they merit being merged.

Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/