From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4876A396579; Fri, 19 Jun 2026 16:34:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.89.141.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781886867; cv=none; b=TAi1HBKnaVzbY8DNCGA3XEpHAtLih9yybVICs0ierRQzPkxGCGBBTcCsxlHomSA+YPINaUO8beaDziQb6qydhGHtoYpRzwkrcxvsTG6o97M6P9IS+4qBGTWwiMpT4+YL+SJppMdl941KqEUskMmN4qByq9xDT3rggu0nAN04QvY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781886867; c=relaxed/simple; bh=umIpAGwG08ccehpImsnotu3Acx+eUIrj9V5Rh7uit+8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lnlv5+8uC5gezHNT0utqxjWDNsc5jJZycTrKq0z7WoFInvFz7RKiat4ku2rb7m+T6W1Ikm+IrUuWFHWI+VEMzXio0DMKNo1i+H5fAk5lsSZPlHFzPY6Dx0xh7pgD81q8sv/rkXQWtTS8zQScVhm2fY9peE6d5E2//HraiATlj9I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk; spf=none smtp.mailfrom=ftp.linux.org.uk; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b=BSCYrreJ; arc=none smtp.client-ip=62.89.141.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ftp.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b="BSCYrreJ" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description; bh=JtrPcPWLxvfUB56XuxdAYk3VgQ7KQnW4bFFt7AsAsb8=; b=BSCYrreJf9QDrwXWaqltFWeG+r +yLW9bJJHQQM9/N8j57Xgp5JnyQ5l0oSWIa9DTU7DcMHy3GuwViPQlMSOMOJy1kBzglOcGWONZjN+ h2+Aa3CZ8axXEa0VV2/pzhMV/mQZhLCJEu+dppjUre+hn32dKGRil1WSGMxIQWMxNSO+HCS2Im6Kk Px7FO9nu7UmuIdd1Xz4p9r70JDkFgvTksXZIZMXevfIpz7pgURyPoeS28H6cxvnqKkDCQ6GQf9CTn e4yc96M04G48Ui4cv4ZZMsvkzRkX4a6wVidCA7zQAo9+lKP/UzMP4t4yM+oPaEz3/kWe57ABLdvMc 17RvNLIg==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.99.4 #2 (Red Hat Linux)) id 1wacAf-0000000EAFP-0WE5; Fri, 19 Jun 2026 16:34:21 +0000 Date: Fri, 19 Jun 2026 17:34:21 +0100 From: Al Viro To: Alex Goltsev Cc: davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net: add sock_open() for unified socket creation Message-ID: <20260619163421.GD2636677@ZenIV> References: <20260618211231.GB2636677@ZenIV> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: Al Viro On Fri, Jun 19, 2026 at 01:35:56PM +0300, Alex Goltsev wrote: > > What's the point (and why not make it inline, while we are at it)? > > > Are there really callers that would pass a non-constant value as the last argument, > > and if so, what are they doing next? > > > As for `inline`: in this case, it would have no practical significance. > > The compiler already treats a simple inline function as a regular > > symbol within the `EXPORT_SYMBOL` context, whereas a static inline > function (the standard > > kernel template for helper functions) would completely break the > export to the LKM. How so? All three underlying primitives are exported, so static inline in whatever include/*/*.h you put it in would work just fine. > As for the last argument, yes, today it is usually a constant, > > but that’s not the point. The purpose of the enumeration is to provide > > a unified, explicit control interface. It’s important that if, in the future, > > someone adds a new type of socket creation, existing calling programs won’t > > panic or throw a compilation error, but will smoothly fall back to > > the default case and return -EINVAL, which is a safe failure mode. Collapsing several functions together is worthless unless the combination can be _used_ other than a (questionable) syntax sugar. kmalloc() can; something that would only result in trading multiple identifiers for functions for multiple identifiers for "which function to call" is not an improvement.