On Sun, Jan 24, 2010 at 08:42:13PM -0500, Kyle Moffett wrote: > > Personally I don't give a flying **** about SystemTap; I'm interested > in things like the ability to stack gdb with strace, the RFC gdb-stub > posted a week ago, etc. None of those abilities would be out-of-tree > modules at all, and therefore the "quicksand" analogy is specious. Great. So what should be reviewed is utrace *plus* these other userland interfaces, which may get critiqued and improved, and utrace patches can be reviewed in light of these new features. But be warned.... if it turns out that only 30% of utrace is only needed to support gdb stacking with strace, etc., the other 70% will likely get ejected and the utrace patches streamlined to support these in-tree users. But since you don't give a flying **** about SystemTap, presumably you won't mind, right? > I would be willing to guess that something like 95% of the people > using SystemTap or other tools are doing so on Red Hat Enterprise > Linux or other enterprise supported platforms, and so when something > breaks they go whinge at Red Hat, etc. If I recall correctly Red Hat > and many of the other vendors already heavily fiddle with kernel > patches they apply to provide some amount of binary module > compatibility. Sure, but as out-of-tree modules, the best they can expect is that most kernel developers will pretend that they don't exist. Which is OK, when I tried using SystemTap most of the concerns which I expressed as being critical for kernel developers were largely ignored (as near as I could tell) because the target market was RHEL corporate customers, and they prioritized their resourcing accordingly --- so they shouldn't mind if kernel developers return the favor. But that means that we should only merge those portions of utrace that are needed for these alleged "killer new features", and only if these new features are cool enough that they justify the new code on their own merits. At least, IMNSHO. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
