| 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
| ||
|
Message-Id: <20070502135336.6d6d3569.akpm@linux-foundation.org> Date: Wed, 2 May 2007 13:53:36 -0700 From: Andrew Morton <akpm@...ux-foundation.org> To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> Cc: Christoph Hellwig <hch@...radead.org>, Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org, rusty@...tcorp.com.au, wfg@...c.edu Subject: Re: 2.6.22 -mm merge plans On Wed, 2 May 2007 16:36:27 -0400 Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> wrote: > * Christoph Hellwig (hch@...radead.org) wrote: > > On Wed, May 02, 2007 at 09:47:07AM -0700, Andrew Morton wrote: > > > > That doesn't constitute using it. > > > > > > Andi, there was a huge amount of discussion about all this in September last > > > year (subjects: *markers* and *LTTng*). The outcome of all that was, I > > > believe, that the kernel should have a static marker infrastructure. > > > > Only when it's actually useable. A prerequisite for merging it is > > having an actual trace transport infrastructure aswell as a few actually > > useful tracing modules in the kernel tree. > > > > Let this count as a vote to merge the markers once we have the infrastructure > > above ready, it'll be very useful then. > > Hi Christoph, > > The idea is the following : either we integrate the infrastructure for > instrumentation / data serialization / buffer management / extraction of > data to user space in multiple different steps, which makes code review > easier for you guys, or we bring the main pieces of the LTTng project > altogether with the Linux Kernel Markers, which would result in a bigger > change. > > Based on the premise that discussing about logically distinct pieces of > infrastructure is easier and can be done more thoroughly when done > separately, we decided to submit the markers first, with the other > pieces planned in a near future. > > I agree that it would be very useful to have the full tracing stack > available in the Linux kernel, but we inevitably face the argument : > "this change is too big" if we submit all LTTng modules at once or > the argument : "we want the whole tracing stack, not just part of it" > if we don't. > > This is why we chose to push the tracing infrastructure chunk by chunk : > to make code review and criticism more efficient. > I didn't know that this was the plan. The problem I have with this is that once we've merged one part, we're committed to merging the other parts even though we haven't seen them yet. What happens if there's a revolt over the next set of patches? Do we remove the core markers patches again? We end up in a cant-go-forward, cant-go-backward situation. I thought the existing code was useful as-is for several projects, without requiring additional patching to core kernel. If such additional patching _is_ needed to make the markers code useful then I agree that we should continue to buffer the markers code in -mm until the use-markers-for-something patches have been eyeballed. In which case we have: atomich-add-atomic64-cmpxchg-xchg-and-add_unless-to-alpha.patch atomich-complete-atomic_long-operations-in-asm-generic.patch atomich-i386-type-safety-fix.patch atomich-add-atomic64-cmpxchg-xchg-and-add_unless-to-ia64.patch atomich-add-atomic64-cmpxchg-xchg-and-add_unless-to-mips.patch atomich-add-atomic64-cmpxchg-xchg-and-add_unless-to-parisc.patch atomich-add-atomic64-cmpxchg-xchg-and-add_unless-to-powerpc.patch atomich-add-atomic64-cmpxchg-xchg-and-add_unless-to-sparc64.patch atomich-add-atomic64-cmpxchg-xchg-and-add_unless-to-x86_64.patch atomich-atomic_add_unless-as-inline-remove-systemh-atomich-circular-dependency.patch local_t-architecture-independant-extension.patch local_t-alpha-extension.patch local_t-i386-extension.patch local_t-ia64-extension.patch local_t-mips-extension.patch local_t-parisc-cleanup.patch local_t-powerpc-extension.patch local_t-sparc64-cleanup.patch local_t-x86_64-extension.patch For 2.6.22 linux-kernel-markers-kconfig-menus.patch linux-kernel-markers-architecture-independant-code.patch linux-kernel-markers-powerpc-optimization.patch linux-kernel-markers-i386-optimization.patch markers-add-instrumentation-markers-menus-to-avr32.patch linux-kernel-markers-non-optimized-architectures.patch markers-alpha-and-avr32-supportadd-alpha-markerh-add-arm26-markerh.patch linux-kernel-markers-documentation.patch # markers-define-the-linker-macro-extra_rwdata.patch markers-use-extra_rwdata-in-architectures.patch # some-grammatical-fixups-and-additions-to-atomich-kernel-doc.patch no-longer-include-asm-kdebugh.patch Hold. - 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/
Powered by blists - more mailing lists