Working on -e trace

[haris iqbal]

On Thu, Feb 18, 2016 at 8:07 AM, Dmitry V. Levin <ldv at altlinux.org> wrote:
> 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.

Well, this is the direction that I took, to find potential new syscall
groups. And there are a plenty that can be considered. The ones that I
was particularly interested in (since they are not included in any of
the groups) are sched_*, *uid and *gid and *timer* and clock_*.

>
> - 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.

Ok, I feel if we use this way, there will be too less number of
syscalls in the new group we create. And, if it is too small then
won't it be easier to trace using the specific name like -e
trace=pipe, pipe2.

It can though serve the purpose of covering similar syscalls for
different architectures that will be good for portability.

>
> - 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.

This would need a thorough information of all syscalls of all
architectures to get it right. I can start working on this by manually
mapping each syscall of every architecture to the task it performs and
then checking the intersection of those mappings.

>
> 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.

That is a good idea. Can't we start with something more simple like
g_file, which would stand for group of all syscalls related to files.
Special symbols might make it a little complicated.

>
>
> --
> ldv
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Strace-devel mailing list
> Strace-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/strace-devel
>

I would like to start working on the sched_* and the *uid *gid ones.

-- 

With regards,

Md Haris Iqbal,
Placement Coordinator, MTech IT
NITK Surathkal,
Contact: +91 8861996962