linux-kernel - Re: [PATCH 1/3] i2c: convert SMBus alert setup function to return an ERRPTR

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200215091139.0311bc7b@endymion>
Date:   Sat, 15 Feb 2020 09:11:39 +0100
From:   Jean Delvare <jdelvare@...e.de>
To:     Wolfram Sang <wsa@...-dreams.de>
Cc:     Wolfram Sang <wsa+renesas@...g-engineering.com>,
        linux-i2c@...r.kernel.org,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Phil Reid <preid@...ctromag.com.au>,
        Robert Richter <rrichter@...vell.com>,
        George Cherian <gcherian@...vell.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] i2c: convert SMBus alert setup function to return
 an ERRPTR

On Sat, 15 Feb 2020 07:50:18 +0100, Wolfram Sang wrote:
> On Sat, Feb 15, 2020 at 07:20:20AM +0100, Jean Delvare wrote:
> > Hi Wolfram,
> > 
> > On Mon, 10 Feb 2020 18:29:25 +0100, Wolfram Sang wrote:  
> > > Only few drivers use this call, so drivers and I2C core are converted at
> > > once with this patch. By simply using i2c_new_client_device() instead of
> > > i2c_new_device(), we easily can return an ERRPTR for this function as
> > > well. To make out of tree users aware that something changed, the
> > > function is renamed to i2c_install_smbus_alert().  
> > 
> > I wouldn't bother renaming the function. Chances that there actually
> > are out-of-tree users of this function are pretty small, and if that is
> > the case, they can adjust their code easily in a way that is still
> > compatible with old kernels.  
> 
> Agreed, it is easy. But they need to *know* that they need to adjust.
> Build error makes it obvious. Otherwise, the code will compile and
> silently not work anymore, I am afraid.

The code will keep working as long as there is no error, which is a
rare situation. If/when it happens, they'll get a very visible error
message in their kernel log.

I understand that this makes them discover the problem later. But we
are talking about a case which most likely does not exist. On the other
hand, renaming makes compatibility harder to achieve for them in the
long term (#ifdefs needed forever), and it makes the work of the
distribution kernel maintainers harder.

I don't think we should make our lives harder to help people who keep
their kernel drivers out of tree. If they are not happy, they know what
they should do.

Just my 2 cents anyway, your call.

-- 
Jean Delvare
SUSE L3 Support