All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Alex Goltsev <sasha.goltsev777@gmail.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: add sock_open() for unified socket creation
Date: Fri, 19 Jun 2026 17:34:21 +0100	[thread overview]
Message-ID: <20260619163421.GD2636677@ZenIV> (raw)
In-Reply-To: <CAEKmD4JfM5GWSiRMUn6NK+kKFeyXA8i3A9gthDz3hVKFcR1YDA@mail.gmail.com>

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.

  reply	other threads:[~2026-06-19 16:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-18 13:06 [PATCH] net: add sock_open() for unified socket creation Alex Goltsev
2026-06-18 21:12 ` Al Viro
2026-06-19 10:35   ` Alex Goltsev
2026-06-19 16:34     ` Al Viro [this message]
2026-06-19 17:54       ` Alex Goltsev
2026-06-21 11:05 ` [PATCH v2] net: add sock_open() with flags for " Alex Goltsev
2026-06-21 12:57   ` David Laight
2026-06-21 13:59     ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260619163421.GD2636677@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sasha.goltsev777@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.