From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D310CC433EF for ; Mon, 8 Nov 2021 21:18:57 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6044761052 for ; Mon, 8 Nov 2021 21:18:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6044761052 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=alien8.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D03386E970; Mon, 8 Nov 2021 21:18:56 +0000 (UTC) Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by gabe.freedesktop.org (Postfix) with ESMTPS id 94C5E6E95A; Mon, 8 Nov 2021 21:18:54 +0000 (UTC) Received: from zn.tnic (p200300ec2f3311007827e440708b1099.dip0.t-ipconnect.de [IPv6:2003:ec:2f33:1100:7827:e440:708b:1099]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id E3BE71EC051F; Mon, 8 Nov 2021 22:18:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1636406333; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=AU7V4fSHGUK4yNvIX3QFWGgL2mpvsQwlJrzk1EYTZE4=; b=HI4wHVqdPFUaTmLfTawRP0YuILjCSvy0XvR7UY6GhjpkLZ7Jcpensq3GPz/wKuSVQPh/ah JjfisFcmsOLL77YybjTfUcF4SOtfsMptjoCY2iNpL/QAVX8IlmhT4tll2zqUciAF4fFC2q GhOxoJIWWV9UKbtfg9ziQ2wDV7UERPU= Date: Mon, 8 Nov 2021 22:18:47 +0100 From: Borislav Petkov To: Alan Stern Message-ID: References: <20211108101157.15189-1-bp@alien8.de> <20211108101157.15189-43-bp@alien8.de> <20211108205926.GA1678880@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211108205926.GA1678880@rowland.harvard.edu> Subject: Re: [Intel-gfx] [PATCH v0 42/42] notifier: Return an error when callback is already registered X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ALSA Development Mailing List , the arch/x86 maintainers , Linux-sh list , linux-iio@vger.kernel.org, "open list:REMOTE PROCESSOR \(REMOTEPROC\) SUBSYSTEM" , linux-hyperv@vger.kernel.org, "open list:BROADCOM NVRAM DRIVER" , netdev , Ayush Sawal , sparclinux , linux-clk , linux-leds , linux-s390 , scsi , Rohit Maheshwari , linux-staging@lists.linux.dev, Geert Uytterhoeven , openipmi-developer@lists.sourceforge.net, bcm-kernel-feedback-list , "open list:TENSILICA XTENSA PORT \(xtensa\)" , Arnd Bergmann , Linux PM list , Intel Graphics Development , Vinay Kumar Yadav , linux-um , Steven Rostedt , rcu@vger.kernel.org, Linux Fbdev development list , xen-devel@lists.xenproject.org, linux-tegra , Thomas Gleixner , intel-gvt-dev@lists.freedesktop.org, Linux ARM , linux-edac@vger.kernel.org, Parisc List , Greg Kroah-Hartman , USB list , LKML , Linux-Renesas , Linux Crypto Mailing List , alpha , linuxppc-dev Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" 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