lkml.org 
[lkml]   [2020]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2020-02-15 09:13    [W:0.053 / U:1.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site