Re: [PATCH] net: add sock_open() for unified socket creation

[Alex Goltsev]

> 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.


This function solves the problem of actual API fragmentation:
currently, there are

three nearly identical functions (sock_create, sock_create_kern,

sock_create_lite) with slightly different signatures. If new variants

are added in the future, this will turn into a “zoo,” similar to what

happened with `kmalloc` before it was unified. I propose unifying this

now, while maintaining backward compatibility (all three existing

functions will remain unchanged).


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.


I’m also aware that in `sock_open`, the first argument passed to the
`sock_create_kern` branch is not safe; I’ve placed it there as a
placeholder and am considering how to elegantly pass the `struct net`
to the `sock_create_kern` branch.