Thread (9 messages) 9 messages, 3 authors, 2021-11-08

Re: [PATCH v0 42/42] notifier: Return an error when callback is already registered

From: Borislav Petkov <bp@alien8.de>
Date: 2021-11-08 21:19:42
Also in: alsa-devel, intel-gfx, linux-alpha, linux-arm-kernel, linux-clk, linux-crypto, linux-edac, linux-hyperv, linux-iio, linux-leds, linux-mips, linux-pm, linux-remoteproc, linux-renesas-soc, linux-s390, linux-scsi, linux-sh, linux-staging, linux-tegra, linux-um, linux-usb, linuxppc-dev, lkml, netdev, rcu, sparclinux, xen-devel

On Mon, Nov 08, 2021 at 03:59:26PM -0500, Alan Stern wrote:
Is there really any reason for returning an error code?  For example, is 
it anticipated that at some point in the future these registration calls 
might fail?

Currently, the only reason for failing...
Right, I believe with not making it return void we're leaving the door
open for some, *hypothetical* future return values if we decide we need
to return them too, at some point.

Yes, I can't think of another fact to state besides that the callback
was already registered or return success but who knows what we wanna do
in the future...

And so if we change them all to void now, I think it'll be a lot more
churn to switch back to returning a non-void value and having the
callers who choose to handle that value, do so again.

So, long story short, keeping the retval - albeit not very useful right
now - is probably easier.

I hope I'm making some sense here.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help