linux-next requirements
in [Kernel]
|
Prev: [PATCH] tracing: Remove CONFIG_TRACE_POWER from kernel config
Next: [PATCH -tip 2/5] tracing: fix typo of info text in trace_kprobe.c
From: Pavel Machek on 3 Mar 2010 17:00 > Today's stats, done amongst users who are willing to opt in to the Smolt > daemon: > > x86: 99.7% > powerpc: 0.3% Lies, bad lies, statistics. > And yes, there are millions of ARM (and MIPS) CPUs running Linux as well. > (They are only as present as present their developers are: the users almost > never show up on linux-kernel.) It cuts both ways. Maybe obscure architectures like alpha have more than their marketshare of interested lkml users... > Plus, a kernel subsystem maintainer like me who does lots of kernel > infrastructure work can have a pretty good gut feeling about which > architectures are actively helping out Linux, and which are just hanging on to > the bandwagon. So instead of either fixing those architectures or marking them deprecated, you blame Stephen for too much testing? We are in middle of 'stable series', so regressions are not permitted. You'd like to cause some regressions. Fine, but definitely not Stephen's problem. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 3 Mar 2010 19:50
On Thu, 4 Mar 2010 01:35:43 +0100 (CET) Thomas Gleixner <tglx(a)linutronix.de> wrote: > As a side note: We created checkpatch.pl, to have a tool which helps > us to alert developers about stuff which is deprecated and as a > byproduct the coding style rules. I think it's a useful tool in > general, just the outcome is an utter trainwreck: > > We have hordes of whitespace, spelling and codingstyle cleanup > maniacs, while the hard stuff of replacing deprecated interfaces like > semaphore based mutexes / completions, cleaning up the BKL horror, > etc. is left to a few already overworked people who care. > > What's even worse is it that developers of new code and the > maintainers who are merging it simply ignore its existance for > whatever reasons. I can accept the whitespace argument, but I have no > grasp why deprecation warnings are ignored at will. um, write checkpatch rules to detect new additions of deprecated features. I take patches. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |