Andi > > Also to be honest I'm not sure that's something really worth > testing. At some point i386 might get vsyscalls too and then > it will just be a normal segfault. Also we're relatively sure > that for the in kernel fallback the EFAULT return path works and it's > unlikely to regress because the code is very simple @) I was thinking i386 code will change and code will be extended to cover more error checks, but if it is moving vsyscall way I dont think there is any scope for error checking. I will remove this test > > More interesting would be to test on more CPUs for example, > as in extending getcpu1 to cycle through all CPUs. I Dont understand, why we should keep a test like that. This test case is arbitrarily assigns the cpu id of the maximum number, of on line cpu, and test that with the return value of getcpu() I am not understanding what we are trying to achieve by testing on all online CPUs. > Also measuring how long the data stays valid and error out > if it's too long, but that would be likely not quite trivial > to test. Can you explain more on this
I had this question, if we are moving to vsyscall will node_id will still be returned by the i386 code or will it go x86_64 way Thanks Sharyathi N ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
