Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753365AbbDGIfg (ORCPT ); Tue, 7 Apr 2015 04:35:36 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:38539 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750994AbbDGIfc (ORCPT ); Tue, 7 Apr 2015 04:35:32 -0400 Date: Tue, 7 Apr 2015 10:35:27 +0200 From: Ingo Molnar To: Alexander Kuleshov Cc: Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , linux-kernel@vger.kernel.org, Borislav Petkov Subject: Re: [PATCH] x86/boot: use __noreturn instead of directly __attribute__ definition Message-ID: <20150407083527.GA9368@gmail.com> References: <1428311077-32198-1-git-send-email-kuleshovmail@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1428311077-32198-1-git-send-email-kuleshovmail@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3498 Lines: 101 * Alexander Kuleshov wrote: > arch/x86/boot/boot.h defines a couple functions as die and etc..., with > 'noreturn' attribute. Let's use __noreturn macro instead of directly > __attribute__ declaration from the . > > We no need to include to the arch/x86/boot/boot.h, > because boot.h already includes "bitops.h" which already includes > . > > Signed-off-by: Alexander Kuleshov > --- > arch/x86/boot/boot.h | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h > index bd49ec6..3351528 100644 > --- a/arch/x86/boot/boot.h > +++ b/arch/x86/boot/boot.h > @@ -305,7 +305,7 @@ void console_init(void); > void query_edd(void); > > /* header.S */ > -void __attribute__((noreturn)) die(void); > +void __noreturn die(void); > > /* mca.c */ > int query_mca(void); > @@ -314,11 +314,10 @@ int query_mca(void); > int detect_memory(void); > > /* pm.c */ > -void __attribute__((noreturn)) go_to_protected_mode(void); > +void __noreturn go_to_protected_mode(void); > > /* pmjump.S */ > -void __attribute__((noreturn)) > - protected_mode_jump(u32 entrypoint, u32 bootparams); > +void __noreturn protected_mode_jump(u32 entrypoint, u32 bootparams); > > /* printf.c */ > int sprintf(char *buf, const char *fmt, ...); Please don't bother producing and sending me such trivial patches unless they: - fix a real bug (in which case they are not trivial patches anymore) - or are part of a larger (non-trivial!) series that does some real, substantial work on this code that tries to: - fix existing code - speed up existing code - or expand upon existing code with new code The reason I'm not applying your patch is that trivial patches with no substance following them up have more costs than benefits: - they lead to pointless churn: - they take up Git space for no good reason - they slow down bisection of real changes - they take up (valuable!) reviewer bandwidth - they take up maintainer bandwidth there's literally a million pointless cleanup patches that could be done on the kernel, and we don't want to add a million commits to the kernel tree. This applies for this patch but also for other future patches you might intend to send for code that I (co-)maintain. My advice to you is to try to raise beyond newbie patches and write something more substantial that helps Linux: - take a look at the many bugs on bugzilla.kernel.org and try to analyze, reproduce or fix them - go read kernel code, understand it and try to find real bugs. - go test the latest kernels and find bugs in it. The fresher the code, the more likely it is that it has bugs. - go read kernel code and try to expand upon it Fortunately it's not hard to contribute to the kernel: there's literally an infinite amount of work to be done on the kernel, and I welcome productive contributions - but churning out trivial patches with no substantial patches following them up is not productive and in fact they are harmful once you are not a totally fresh newbie kernel developer anymore... Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/