Re: pull-request: bpf-next 2023-12-18

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Of course, and you'll be CC'ed on all the BPF token patches I will
> resend after the holidays.
> 
> And just to be clear for the future, by "core fs semantics" you also
> mean any BPF UAPI FD field, right?

Yes, because ultimately you end up with calling:

fdget()/fdget_raw()/fget()

to turn a userspace handle in the form of an fd and turn it into a
struct file. And that is uniform across the kernel. And therein lies the
beauty of it all imo.

IMHO, a file descriptor is one of the most widely used generic
abstraction we have across all of the kernel. It is almost literally
used everywhere. And everyone has the same contract: a non-negative
integer is a valid fd, a negative one is invalid. It's simple, there
aren't corner cases, there aren't custom semantics.

And it's also arguably one of the most successful ones as we keep
implementing new apis on top of this abstraction (pidfd, seccomp,
process_*(), memfd_*(), endless kvm ioctls etc etc).




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux