On Sat, Jun 28, 2014 at 6:52 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Sat, Jun 28, 2014 at 1:49 PM, Alexei Starovoitov <ast@xxxxxxxxxxxx> wrote: >> >> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
