On Thu, Feb 18, 2016 at 2:51 PM, haris iqbal <haris.p...@gmail.com> wrote: > On Thu, Feb 18, 2016 at 8:07 AM, Dmitry V. Levin <l...@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@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
Hello, A little help is needed here. I could understand that for the -e option, one uses the combination of sysent_vec[][].sys_flags and the macros TRACE_FILE and others, which sets the proper flag in qual_vec. Now that qual_vec is used by qual_flg in the tcb struct (correct me if something is wrong). But what I could not find is where those flag is used to print only the syscalls that are needed (like only file related). I searched and followed the flow of execution and found trace_syscall_entering() through trace_syscall() in trace(). There is a function calles get_scno(), I guess its where this syscall filtering is happening but not sure. Can someone please point me in the right direction. NOTE: 1) I am looking at the -e option closely to come up with a POC for the idea "Fault injection for syscalls". 2) Waiting for a reply for the naming policy so that I can start working to add the sched_* and the *uid *gid ones to the -e option. -- With regards, Md Haris Iqbal, Placement Coordinator, MTech IT NITK Surathkal, Contact: +91 8861996962 ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
