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] [day] [month] [year] [list]
Message-ID: <YYmUN69Y7z9xITas@zn.tnic>
Date:   Mon, 8 Nov 2021 22:18:47 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Arnd Bergmann <arnd@...db.de>,
        Ayush Sawal <ayush.sawal@...lsio.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rohit Maheshwari <rohitm@...lsio.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Vinay Kumar Yadav <vinay.yadav@...lsio.com>,
        ALSA Development Mailing List <alsa-devel@...a-project.org>,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
        Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
        intel-gvt-dev@...ts.freedesktop.org,
        alpha <linux-alpha@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        linux-edac@...r.kernel.org,
        Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
        linux-hyperv@...r.kernel.org, linux-iio@...r.kernel.org,
        linux-leds <linux-leds@...r.kernel.org>,
        "open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
        Parisc List <linux-parisc@...r.kernel.org>,
        Linux PM list <linux-pm@...r.kernel.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        "open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM" 
        <linux-remoteproc@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        linux-s390 <linux-s390@...r.kernel.org>,
        scsi <linux-scsi@...r.kernel.org>,
        Linux-sh list <linux-sh@...r.kernel.org>,
        linux-staging@...ts.linux.dev,
        linux-tegra <linux-tegra@...r.kernel.org>,
        linux-um <linux-um@...ts.infradead.org>,
        USB list <linux-usb@...r.kernel.org>,
        "open list:TENSILICA XTENSA PORT (xtensa)" 
        <linux-xtensa@...ux-xtensa.org>, netdev <netdev@...r.kernel.org>,
        openipmi-developer@...ts.sourceforge.net, rcu@...r.kernel.org,
        sparclinux <sparclinux@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        xen-devel@...ts.xenproject.org
Subject: Re: [PATCH v0 42/42] notifier: Return an error when callback is
 already registered

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ