On Wednesday 19 November 2008 02:56:18 Gilles.Carry wrote: > Mike Frysinger a écrit : > >>> kernel config options change. you also cant assume the kernel location > >>> (diff kernel source, cross-compile, etc...). > >> > >> Of course they change, like the rest of the kernel! > >> When I say "include kernel config headers", I mean copy autoconf.h to > >> ltp before compiling, not include it into LTP source tree. > > > > which doesnt address anything of what i said. when a kernel config gets > > renamed, the tests that refer to it need updating. > > How often do they change anyway? > LTP tests should stick to kernel release. Options should treated with > the same care as APIs or behaviour changes.
i dont agree with that statement at all, and i doubt LKML would agree. plus, how do you handle situations where the config option goes away completely or it never existed in the first place ? do we start adding kernel version checks as well ? what about distros that backported features ? yes, for some things this may all be theoretical, but if we introduce it in one place, it sets a precedence that can easily snowball into crap. > Kernel location: it is the tester's responsibility to provide autoconf.h > wheather by copying it from the kernel source tree or by processing > /proc/config.gz (after all, he's not supposed to have the kernel source) thanks for pointing that out ... for some reason when i read the original e- mail / patch, you said things would be done automatically. i reread things and clearly you never said anything like that. > >>> why not just turn the TFAIL into TCONF when the function returns ENOSYS > >>> in the tests that concern you. > >> > >> Because some might want to check if the functionality is present in the > >> kernel and consider ENOSYS as a failure. This is why it must be > >> optional. > > > > TCONF outputs a message. if you really care, read the output. > > Whatever the method is, people testing have to define a kind of profile > for automated validations. This can be done by post-processing output as > you said or by using my method or a combo. > > > Anyway don't bother answering to this as nobody seems to care. I will > not work and send patches for nothing. I've learned my lesson: I give up. someone always cares, it's just a matter of making them care enough to assist. there is a desire to handle the case you raise: features that are not available at runtime for whatever reason. but no consensus has been reached (or really attempted yet) at how best to tackle this. i dont think LTP has any sort of "TODO" list, nor is it using any of the trackers to this effect ... basically to make sure that these sort of issues exist beyond common developers' memory. -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- 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
