linux-kernel - Re: [PATCH 00/23] tracehook

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: <20080721095932.B409A15421D@magilla.localdomain>
Date:	Mon, 21 Jul 2008 02:59:32 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/23] tracehook

Ingo said very well what I think the intrinsic value is.  Indeed, I
think it is of use even if utrace were never merged.  Anyone who
decides tomorrow that my crap is useless and whips up a different
plan instead of utrace, will benefit from reading all the kerneldoc
in tracehook.h.

The practical value of the patch series right now is that it makes
life easier for merging and patch juggling.  The new utrace patches
are indeed coming too, and I'm expecting some vigorous feedback.
Different versions are likely to bounce around for a while.
Meanwhile, there are some people trying to track latest+utrace via
GIT or patching.  The tracehook series makes it so that the utrace
patches proper touch very little core code and few files, so merge
and patch conflicts are rare.  I can tell you from doing it a lot
that there are frequently niggling conflicts to fix up in rebasing
the tracehook patches after miscellaneous core kernel changes.
Things requiring changes to tracehook.h are unlikely, but unrelated
changes textually near the tracehook calls that foul automatic patch
merging are common.

I'll do another few days of polish on utrace first too, but one main
reason I posted tracehook alone first was to see how much shrapnel I
took in the face just for this, before getting to the substantive
bits.  If this much is accepted, that's enough to make it possible
for utrace or another new thing to be added as a config option.  

The new utrace has internal differences from the first version, but
the more essential point here is that it's entirely optional at
config time.  Whatever traits utrace has, it's only a new
non-default config option marked EXPERIMENTAL.  Once the tracehook
series is accepted, then relative to that, no utrace patches will do
anything at all if CONFIG_UTRACE is not chosen.

Another value is for arch folks.  I know at least a few arch
maintainers are interested in adding this support.  The generic
tracehook series sets a base on which all the arch support can be
finished up and ready to enable utrace or something different,
whatever it is.  If this base is in a canonical shared tree to be
merged into, then any interested arch people can fully complete this
work and push it to their arch's users.  This lets people experiment
on utrace (or a replacement) without also juggling arch patches.

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/