Working on -e trace

[Dmitry V. Levin]

On Wed, Feb 17, 2016 at 04:56:39PM +0530, haris iqbal wrote:
> On Sun, Feb 14, 2016 at 5:54 AM, Dmitry V. Levin wrote:
> > On Thu, Feb 11, 2016 at 09:04:56PM +0530, haris iqbal wrote:
[...]
> >> Another thing. If I did not miss any step above then I can start thinking
> >> about the new category to be added.
> >
> > What category seems the most promising so far?
> 
> Ok,  I did a little research to find out the system calls that are
> missing a group. And I found some calls that can be made into groups.
> They are as follows.
> 
> 1) Timer and Clock type. This group will include all the system calls
> that create per-process timers, and the ones that work on clocks.
> Example : timer_* and clock_*. May be others also.
> 
> 2) Another one that can be added, which Dmitry suggested in the
> beginning was all system calls dealing with uid and gid.
> 
> 3) The last one which I noticed that can be added are the system calls
> which deal with scheduler. sched_* system calls.
> 
> NOTE: If there are any suggestions, please feel free to comment. :)

There are at least three directions to look for potential syscall groups:

- Different syscalls from the same family, e.g. io_*, *xattr, *timer*,
  clock_*, sched_*, *uid, *gid, mq_*, NUMA-related (get_mempolicy, mbind,
  migrate_pages, move_pages, set_mempolicy), etc.

- Small groups of similar syscalls, often pairs where one syscall is
  a predecessor of another, e.g. open/openat and similar *at pairs,
  accept/accept4, dup2/dup3, epoll_create/epoll_create1, eventfd/eventfd2,
  inotify_init/inotify_init1, pipe/pipe2, pselect/pselect6,
  rename/renameat/renameat2, umount/umount2, etc.
  On newer architectures older syscalls are not available, so it might be
  a good idea from portability PoV.  For example, a group of open-like
  syscalls could be used instead of trace=open,openat to do a more
  portable tracing across different architectures.

- Small groups of syscalls that are almost the same but called
  differently between architectures, e.g. newfstatat/fstatat64, or have
  very subtle differences, like LFS vs non-LFS editions of syscalls.
  In such cases, there is no simple rule to find out the right syscall
  name(s) on a given architecture, so having a way to specify, e.g.
  all fstatat-like syscalls might be a good idea from portability PoV.

If we are going to have so many different syscall groups, it's time to
think about a naming policy.  I think that all new syscall group names
should start with a non-alphanumeric symbol (e.g. "%" or "@") to avoid
collisions with syscall names.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20160218/cae35270/attachment.bin>