From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752111AbdJPJdU (ORCPT ); Mon, 16 Oct 2017 05:33:20 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:51622 "EHLO mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751358AbdJPJdQ (ORCPT ); Mon, 16 Oct 2017 05:33:16 -0400 X-Google-Smtp-Source: AOwi7QA4Z4HbjmvoufzEZKnm6F6qC2UV3FzQZ0E22pcsTmCPn3VlGQl1D1d5/MmCoCrZIy0hS01Scg== From: =?utf-8?Q?Javier_Gonz=C3=A1lez?= Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D7A71A7E-B051-4371-8918-FC1CBAF031B8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] linux/types.h: Restore the ability to disable sparse endianness checks Date: Mon, 16 Oct 2017 11:33:12 +0200 In-Reply-To: <1507311801.2602.12.camel@wdc.com> Cc: Christoph Hellwig , "torvalds@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "mst@redhat.com" To: Bart Van Assche References: <20171006172353.16758-1-bart.vanassche@wdc.com> <20171006173538.GA4106@lst.de> <1507311801.2602.12.camel@wdc.com> X-Mailer: Apple Mail (2.3273) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Apple-Mail=_D7A71A7E-B051-4371-8918-FC1CBAF031B8 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On 6 Oct 2017, at 19.43, Bart Van Assche wrote: > > On Fri, 2017-10-06 at 19:35 +0200, Christoph Hellwig wrote: >> On Fri, Oct 06, 2017 at 10:23:53AM -0700, Bart Van Assche wrote: >>> The purpose of patch "linux/types.h: enable endian checks for all >>> sparse builds" was to encourage driver authors to annotate >>> endianness correctly in their drivers. However, since that patch >>> went upstream no endianness annotations in drivers have been fixed. >>> I think that this shows that the followed approach does not work, >>> probably because several driver authors do not use sparse. Restore >>> the ability to disable sparse endianness checks such that it >>> becomes again easy to review other sparse diagnostics for people >>> who want to analyze drivers they are not the author of. >> >> So how do we get people to do it? Out of the sparse checks endianess >> warnings are the most useful, together with __user and __iomem. > > Hello Christoph, > > That's an excellent question. Do you think it would help if the zero-day > kernel testing infrastructure would check whether kernel patches introduce > new sparse complaints and if this is the case post these as a reply to the > e-mail with the patch that introduced the new sparse warnings? > +1 to this. Javier --Apple-Mail=_D7A71A7E-B051-4371-8918-FC1CBAF031B8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm1mT7zen+vs9+T8kYx8FO3WZGMoFAlnkfNgACgkQYx8FO3WZ GMqJSBAAqAV/E1zraV4nV9Z+dialbVVFXZgouJX5xgppLqPUyskbuqpGz+fPyTTb 4UM1IFNyNwPL5Y7EkYrZtfcPRocsUyLjfyDMpNRqe6Nsa0Jr1NJCCqDrCIVmrEfY 8dIPlm5phk+01x3gMIFlohVKZHFyGLWKg34j5Tx8dd5Alo3X7yF1C9ytTxUsqcDk o7mRyEg4cc3k+g6/v2HGBsUQb7372ivhlwlrT0wXeKI/7DJQLkLbI8u29aAZMtGI 3WswgNl0saSVxkVjnV6rSHwIPqU7THBgQV4s7uJISI47RiKCALXhOElWY2b6vJzT Iqf2joQUnLj2cmPsPPH0okgCDTZXFCXMTenuFHmNC7EMUm3YOVEVqRojmHCWzhNN dicYKlQBZtTB+HtJT0SnEN3Y2h3I55IqegWtS51a++aITfEh8bzLdn5qTMyNZOZI ZHPlKKYS3bL8Xw6VlwV4n3zvtOwS1Uc4phCcBSzrSXKyidAyZSyiQfXnPQXqhvrY OQUIOVJhggsOi2hd/+N6x+BftHABt120/sI3f/BSbGYSQKzx9AIn5lKKVShqYLsd 6U2amF8r66p3bmP3vq/FgojCeyyi3QEMJNakrTTeZ35TJwV2WcJ86QRlXHXgDBn6 QuCvWCM7Ihdlc12u5l5BMJSm/1p3ZkAXM0je6EIzAM79N7OdNEM= =wGyR -----END PGP SIGNATURE----- --Apple-Mail=_D7A71A7E-B051-4371-8918-FC1CBAF031B8--