> Thank you for the patch acceptance. > Is the following list of open system calls complete ? It is based on > reply that function calls that returns new file descriptor > > 1) mq_open > 2) openat > 3) perf_event_open > 4) open_by_handle_at > 5) memfd_create > 6) epoll_create1 > 7) dup > 8) dup3 > 9) fcntl64 > 10) timerfd_create > 11) socket > 12) accept > 13) pipe2 As Dmitry reminded me, there are two interpretations; the one is quite narrow — different architectures have both open/openat syscalls or only one of them; %open may be used in order to track both (as old code tends to use old one, moder uses openat and you ca never be sure). The other one is quite wide — all syscalls that return new fd (as I previously suggested), and in my mind the idea was to track all new descriptors. But in this latter case, the question arises, whether some unortodox (but quite utilised) ways of obtaining new fds, like recvfrom or ioctl(NS_GET_PARENT, ...) or bpf(BPF_MAP_CREATE, ...) should be covered. In my opinion, it makes the filter too complicated, but event not considering them, there are also at least timerfd_create, eventfd/eventfd2, inotify_init, signalfd, fanotify_init.
-- Eugene Syromyatnikov mailto:evg...@gmail.com xmpp:esyr@jabber.{ru|org} ------------------------------------------------------------------------------ Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary content that is easy and intuitive to access. Sign up for an account today to start using our lexical data to power your apps and projects. Get started today and enter our developer competition. http://sdm.link/oxford _______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
