netdev - Re: [PATCH net-next 01/12] net: homa: define user-visible API for Homa

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <6467b078-4ee9-ecb2-6174-825c3a2d5007@gmail.com>
Date: Fri, 8 Nov 2024 22:02:27 +0000
From: Edward Cree <ecree.xilinx@...il.com>
To: John Ousterhout <ouster@...stanford.edu>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net-next 01/12] net: homa: define user-visible API for
 Homa

On 08/11/2024 17:55, John Ousterhout wrote:
> This leaves open the question of where these
> declarations should go once the userland library is upstreamed. Those
> library methods are low-level wrappers that make it easier to use the
> sendmsg kernel call for Homa; users will probably think of them as if
> they were system calls. It feels awkward to require people to #include
> 2 different header files in order to use Homa kernel calls; is it
> considered bad form to mix declarations for very low-level methods
> like these ("not much more than kernel calls") with those for "real"
> kernel calls?

include/uapi/ does sometimes contain 'static inline' wrappers.  But
 declarations for actual functions that need linkage are avoided AFAICT.
The expectation normally is that userland application code will #include
 a library header, which takes care of #including any necessary kernel
 uAPI headers, ideally packaged separately from the kernel rather than
 just taking the include/uapi/ directory of whatever kernel is currently
 running.  (Back in the day there were some classic Linus rants[1]
 warning against the latter.)
Then both the helper functions and their declarations live in the
 library, where they can be linked into the application, and not mixed
 in with the kernel headers.

> Do you know of other low-level kernel-call wrappers in
> Linux that are analogous to these? If so, how are they handled?

The closest analogy that comes to mind is the bpf system call and libbpf.
libbpf lives in the tools/lib/bpf/ directory of the kernel tree, but is
 often packaged and distributed independently[2] of the kernel package.
If there is a reason to tie the maintenance of your wrappers to the
 kernel project/git repo then this can be suitable.

But I'm not an expert on this, so I hope someone with more experience
 around uAPI stuff will chime in.  Might be worth CCing linux-api[3] on
 the next version of this patch.

HTH,
-ed

[1]: https://yarchive.net/comp/linux/kernel_headers.html#23
[2]: https://github.com/libbpf/libbpf
[3]: https://www.kernel.org/doc/man-pages/linux-api-ml.html