On Sat, Jun 28, 2014 at 11:36 PM, Alexei Starovoitov [off-list ref] wrote:

On Sat, Jun 28, 2014 at 6:52 PM, Andy Lutomirski [off-list ref] wrote:

quoted

On Sat, Jun 28, 2014 at 1:49 PM, Alexei Starovoitov [off-list ref] wrote:

quoted

Sorry I don't like 'fd' direction at all.
1. it will make the whole thing very socket specific and 'net' dependent.
but the goal here is to be able to use eBPF for tracing in embedded
setups. So it's gotta be net independent.
2. sockets are already overloaded with all sorts of stuff. Adding more
types of sockets will complicate it a lot.
3. and most important. read/write operations on sockets are not
done every nanosecond, whereas lookup operations on bpf maps
are done every dozen instructions, so we cannot have any overhead
when accessing maps.
In other words the verifier is done as static analyzer. I moved all
the complexity to verify time, so at run-time the programs are as
fast as possible. I'm strongly against run-time checks in critical path,
since they kill performance and make the whole approach a lot less usable.

I may have described my suggestion poorly.  I'm suggesting that all of
these global ids be replaced *for userspace's benefit* with fds.  That
is, a map would have an associated struct inode, and, when you load an
eBPF program, you'd pass fds into the kernel instead of global ids.
The kernel would still compile the eBPF program to use the global ids,
though.

Hmm. If I understood you correctly, you're suggesting to do it similar
to ipc/mqueue, shmem, sockets do. By registering and mounting
a file system and providing all superblock and inode hooks… and
probably have its own namespace type… hmm… may be. That's
quite a bit of work to put lightly. As I said in the other email the first
step is root only and all these complexity just not worth doing
at this stage.

The downside of not doing it right away is that it's harder to
retrofit in without breaking early users.

You might be able to get away with using anon_inodes.  That will
prevent repoening via /proc/self/fd from working (I think), but that's
a good thing until someone fixes the /proc reopen hole.  Sigh.

--Andy