[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQJfyfbpEVHnBy2DDGEJvUm8K25b9NHCzu08Uv96OS8NaA@mail.gmail.com>
Date: Mon, 18 Dec 2023 17:48:32 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Linus Torvalds <torvalds@...uxfoundation.org>
Cc: Jakub Kicinski <kuba@...nel.org>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, Christian Brauner <brauner@...nel.org>,
Network Development <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
Kernel Team <kernel-team@...com>
Subject: Re: pull-request: bpf-next 2023-12-18
On Mon, Dec 18, 2023 at 5:11 PM Linus Torvalds
<torvalds@...uxfoundation.org> wrote:
>
> I literally see complete garbage like tghis:
>
> ..
> __u32 btf_token_fd;
> ...
> if (attr->btf_token_fd) {
> token = bpf_token_get_from_fd(attr->btf_token_fd);
>
> and this is all *new* code that makes that same bogus sh*t-for-brains
> mistake that was wrong the first time.
Point taken.
We can do s/__u32 token_fd/__u64 token/
and waste upper 32-bit as flags that indicate that lower 32-bit is an FD
or
are you ok with __u32 token that is 'fd + 1'.
zero - invalid
one - FD==0
two - FD==1
?
Naming is hard. 'token_handle' maybe?
Powered by blists - more mailing lists