From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AB3B3C43331 for ; Thu, 26 Mar 2020 04:13:51 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6BD6420714 for ; Thu, 26 Mar 2020 04:13:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6BD6420714 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=vt.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.92.3) (envelope-from ) id 1jHJtL-0006D9-Uw; Thu, 26 Mar 2020 00:13:15 -0400 Received: from omr1.cc.ipv6.vt.edu ([2607:b400:92:8300:0:c6:2117:b0e] helo=omr1.cc.vt.edu) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jHJtK-0006D3-I0 for kernelnewbies@kernelnewbies.org; Thu, 26 Mar 2020 00:13:14 -0400 Received: from mr1.cc.vt.edu (inbound.smtp.ipv6.vt.edu [IPv6:2607:b400:92:9:0:9d:8fcb:4116]) by omr1.cc.vt.edu (8.14.4/8.14.4) with ESMTP id 02Q4DCxa030981 for ; Thu, 26 Mar 2020 00:13:13 -0400 Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by mr1.cc.vt.edu (8.14.7/8.14.7) with ESMTP id 02Q4D7tO022935 for ; Thu, 26 Mar 2020 00:13:12 -0400 Received: by mail-qt1-f197.google.com with SMTP id t6so4033475qtj.12 for ; Wed, 25 Mar 2020 21:13:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:content-transfer-encoding:date:message-id; bh=UtGPrkoWsuPyqyahigWA3cw0UVRh+w8fklnsB+vE9mQ=; b=guMV1oVUfztbOwndSSAXGM4WvyoUKOjby6FFx79O6E3CYnTrJamngsmcV+yje99Pwn szOnFM0+TC2HTDZmNNR07Tyym8R4rFjXJWH2ScXEmOlXZBricLCzZnDcGMkc7aAzJztq zPFC4mRFMiTV8LJlM2DaN1R6AIp1shPCWgCkSXkMf4VSrqz7vEKclV9ywYp38V30BeUz sjUiWiutd6dxxG4U261wL2d5cHRavONPE9lLsG6gVYRCeMfjC/pHkYEj6r3a5zZJ/gQT a/WOs9WW2kgn4HW7QXvkCm22U0EFj4SntLUSorYScScpxGKp5xwIn/gf0DMcJiVC0ypK 5Pnw== X-Gm-Message-State: ANhLgQ3uf9utg+l81rBD9e8pybaiQ+8QidIa4VqdC2VL/F8pOJ25+np1 KObRl2mDgtvYOvSpoQ4TZ16RHFGdIkWqEgq2v52ZjUJbrH/hdy8imDn4S+sbHPnUaYtLrJK+Jpt uiIapSw7mo73M85TjoobvXZG0lF97C4g6Mk8Nnao= X-Received: by 2002:a37:b041:: with SMTP id z62mr6126459qke.487.1585195987092; Wed, 25 Mar 2020 21:13:07 -0700 (PDT) X-Google-Smtp-Source: ADFU+vu3d43uwmEUNunoE/UTLG+M7XHjtLGSbjWxcNRC20ZNFpENfgoOMqI4dMtFb4szzja/d4xSug== X-Received: by 2002:a37:b041:: with SMTP id z62mr6126443qke.487.1585195986595; Wed, 25 Mar 2020 21:13:06 -0700 (PDT) Received: from turing-police ([2601:5c0:c001:c9e1::359]) by smtp.gmail.com with ESMTPSA id p9sm785801qtu.3.2020.03.25.21.13.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Mar 2020 21:13:05 -0700 (PDT) From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Google-Original-From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev To: Tomek The Messenger Subject: Re: linux kernel coding style and checkpatch.pl script In-Reply-To: References: Mime-Version: 1.0 Date: Thu, 26 Mar 2020 00:13:04 -0400 Message-ID: <98202.1585195984@turing-police> Cc: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7295459113843972065==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============7295459113843972065== Content-Type: multipart/signed; boundary="==_Exmh_1585195984_88639P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --==_Exmh_1585195984_88639P Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 25 Mar 2020 10:36:08 +0100, Tomek The Messenger said: > There is checkpatch.pl script To borrow from Pirates of the Carribean, =22They're not exactly rules, th= ey're more like... suggestions...=22 Checkpatch flags *possible* code style problems, but it's not perfect. Th= ere's often good reason to ignore them. For example: > However can I ignore warning message? > WARNING: quoted string split across lines > =23974: FILE: fpgax67-core.c:974: > + dev_err(&pdev->dev, =22registration not done, driver is= already =22 > + =22registered= =5Cn=22); > > If I don't split line I will have another warning that 80 characters is= > exceeded. Blech. Ick. Don't split literal strings, it means that grepping the source tree for =22already registered=22 fails. Making grep for a string work is more imp= ortant than shutting up checkpatch. > For sure I can ignore warnings about: > WARNING: struct should normally be const > =23998: FILE: fpgax67-core.c :998: This one you actually need to look at what the routine says. The object = is *usually* a const - but might not be. Figure out what it actually does. Always keep in mind that it's a perl script, and just doing regex matchin= g. It has no clue what the code actually does. Hopefully you have more understa= nding of the code than the perl script does... > For sure all errors must be fixed like: > const char* tmp -> change to -> const char *tmp; > if(=A0 =3D> if (=A0 =A0=23insert space If this is new code you're writing, you should fix it before you submit t= he patch adding the code. (Unless of course, checkpatch is wrong about a variable needing to be a const, or similar) If you're doing major changes to existing code anyhow, a cleanup patch fi= rst is often appropriate. If you're just fixing checkpatch warnings for the sake of fixing checkpat= ch warnings, keep in mind that many maintainers won't accept patches that ju= st clean up checkpatch, for several reasons: First, if it's code that's been static for a while (years, sometimes), th= ere's always a danger that a patch breaks something. No reason to touch stable= code. If it's code that somebody else is working on, your patch can cause merge= errors with the other person's (which is why only the person doing the ot= her work should do cleanup patches - they won't conflict with their own work)= . Also, it messes up the git history - consider a patch that changes an 'if( foo && =21bar) =7B' to 'if( foo && =21baz)=7B' to fix a bug whe= re the wrong variable was being tested. You then submit a patch to fix the space. Now a 'git blame' on the file shows your patch rather than the one that fixes the bug. However, I have it on good authority that Greg KH will cheerfully accept checkpatch fixes for anything under 'drivers/staging', because that code is usually in such bad shape that fixups are needed. :) Personally, I do kernel builds with sparse and extra gcc warnings, and su= bmit patches only after applying some thought and concluding things like =22Ye= s, sparse and/or gcc were correct, the variable *should* be static so it can= 't be accessed from another module due to a namespace collision=22. In other words, the patch should *never* be =22Fix a checkpatch/sparse/gc= c complaint=22. It should always be =22Make an objective improvement to the= code that happened to be pointed out by static analysis tools=22. --==_Exmh_1585195984_88639P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Comment: Exmh version 2.9.0 11/07/2018 iQIVAwUBXnwrzwdmEQWDXROgAQI8EA//YXsbdy6mo89bFBmcziC9Qq4L863QfHar d11NPBXAhcuU1hQOt6Wze4Hgu+dMIjmUoGymiKA0oN2vnygesxfKfgxlpWx3OxPV Xy1Cn3Tv+6RumdGFrpo8pzHm58HB/NKgALk2Z1d79XzhgQoxfcoDYIWgjRP2OdG8 JwXJLUC1eEYRBaCLHxrVvdNBEUyAVtmphOvp3uQ5LB7Qdp5EM1eGzhhmpxq3vFu7 xiJ5AduuoQvNEOQoYcbp23E1iJtFcVPiton5NRe0tHNcuXRkSGrDFAeVfv22bx2U 8R/SS0oapluloCgRqXJKKkgaGX93++MNm43rHzOZE6pqb5RA0Q5vMiCq4fJl0mBl pQapMzLyUkSVR8sLx1YP122KDAxxpfb2Is7XNu9sK9FYV6cpMz9TVJEFMM+YKstU pVmrc5b8KqHs7JPJtQi1oKu7wxiIod6AvslUMaJ5BS6wbAVmRaoPNo+RAMlnew3s 5AhLq77hY9UtWMdvI60yqYOM56fcs9ROuhjLb2Z6BTS90RwGa268+ENFkn5k9/Tj UDZDRW6hipm9bqnMKV8qS1ABv+sMGt4aHqIhNx1ZUpnsO3uOttlUuwL18ylFWDmQ B1byZQdgmDDsDUZXzpeK2jfeCAZjJIYVCv6tpQ2VcgWb2xAiVAUoxjI9MElWUHrR la5OmTPinHQ= =p+1O -----END PGP SIGNATURE----- --==_Exmh_1585195984_88639P-- --===============7295459113843972065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============7295459113843972065==--