Thanks. One more query: I'm not able to see any usage of "link" syscall in tests subdir. Although, covecov is highlighting "link" syscall in green, which I presume indicates test for that syscall is covered. What am I missing here?
On Sat, Mar 12, 2016 at 9:20 PM, Dmitry V. Levin <[email protected]> wrote: > On Sat, Mar 12, 2016 at 01:37:20PM +0530, Jay Joshi wrote: >> On Sat, Mar 12, 2016 at 7:53 AM, Dmitry V. Levin wrote: >> > On Fri, Mar 11, 2016 at 11:22:23PM +0530, Jay Joshi wrote: >> > > >> > > This is my first attempt to add test for syscall (here, chdir). Any >> > > suggestion, comment, criticism is welcomed. >> > >> > chdir is already well covered, see >> > $ git grep chdir tests >> > >> > You must have missed my recommendation to check current coverage report >> > at https://codecov.io/github/strace/strace before adding new tests. >> > >> > I think you'd rather take something that's not tested at all. >> >> Thanks. I couldn't understand coverage structure properly. Is coverage >> calculated manually, semi-automatically or automatically? > > It's fully automatic, see travis-ci.sh script. > >> > > +#if defined __NR_chdir >> > >> > Why do you think that libc wrapper for chdir syscall is not suitable? >> >> Syscall should only be used when glibc wrapper function for that >> syscall is not available. Please correct me if I'm wrong. > > Either not available or implemented using different system call(s). > >> If so, what >> is the advantage of using syscall function for, say "chmod"? Please >> help me understand where to use what. > > Some recently added architectures (see e.g. linux/32/syscallent.h and > linux/64/syscallent.h) provide no "chmod" syscall; on these architectures, > "chmod" libc wrapper uses "fchmodat" syscall. > > This is certainly not the case for "chdir"; there seems to be no other way > to implement "chdir" besides calling "chdir" syscall. > >> > > + if (errno == ENOSYS) { >> > > + printf("chdir(\"%s\") = -1 ENOSYS (%m)\n", sample_dir); >> > >> > chdir failing with ENOSYS? Really? >> >> Not sure. Where can I find whether system would have surely >> implemented a particular system call? In other words, would never >> throw ENOSYS. > > Besides syscalls marked with NF flag > (see git grep -Fw NF linux/*/syscallent*.h), there is no single place that > would give you an answer for this question, which is just a special case > for a more general question how a particular system call works on > different architectures and kernel versions. > > manual page usually answers the question whether the function implemented > by syscall is mandatory and when the system call was introduced in the > kernel. > > linux/*/syscallent*.h answers the question whether the syscall is hooked > up in all architectures. > > General understanding of linux kernel helps to find out alternative > syscalls or prove their absense. > > > -- > ldv > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 > _______________________________________________ > Strace-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/strace-devel > ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 _______________________________________________ Strace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/strace-devel
