On 4 April 2016 at 05:12, Emilio López <emilio.lopez@xxxxxxxxxxxxxxx> wrote: > Hi, > > El 28/03/16 a las 10:48, Emil Velikov escribió: > >>>>> These tests are based on the libsync test suite from Android. >>>>> This commit lays the ground for future tests, as well as includes >>>>> tests for a variety of basic allocation commands. >>>>> >>>>> Signed-off-by: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx> >>>>> Signed-off-by: Emilio López <emilio.lopez@xxxxxxxxxxxxxxx> >>>>> --- >>>>> >>>> >>>>> tools/testing/selftests/sync/sync.h | 119 ++++++++++++++++++ >>>> >>>> >>>> Admittedly I know nothing about the kernel selftests although copying >>>> the UAPI header, seems to defeat the purpose of this exercise. >>>> Shouldn't one reuse the existing header ? It would even cause issues >>>> as the interface gets updated (iirc Gustavo changed the ioctl numbers >>>> and/or header name with latter series). >>> >>> >>> >>> The problem is that one cannot use the system header without having built >>> and installed the kernel first, which is rather problematic for eg. >>> crosscompiling or virtualization. I discussed this with Gustavo and we >>> agreed that the best way forward would be to copy the interfaces, as >>> suggested by kernelnewbies' wiki[0]: >>> >> In the case of using a system header one can just `make >> headers_install' without building the kernel, as mentioned in the very >> same page ;-) Although I wasn't thinking that one should be using the >> header already available in tree. After all this series is not >> supposed to land before Gustavo's work, is it ? >> >> From a quick skim though the selftests, I cannot see cases where UAPI >> headers are copied/duplicated. >> >>> """ >>> The correct way to address this problem is to isolate the specific >>> interfaces that you need, e.g. a single header file that is patched in a >>> new >>> kernel providing the ioctl numbers for a character device used by your >>> program. In your own program, add a copy of that source file, with a >>> notice >>> that it should be kept in sync with new kernel versions. >>> """ >> >> My understanding of the article is that it refers to building user >> space programs that do _not_ live in the same tree as the kernel. Am I >> missing something ? > > > When I tried using the header directly from the kernel tree, the compiler > told me not to do that and pointed me to that kernelnewbies page; I could > try overriding the check like I see memfd does[0] but I don't know if that's > the way to go. Shuah, what's your thoughts on this? > Afaics the warning comes up, as the uapi header gets picked up prior to the normal one (in include/). Thus by reordering the includes things should work. One could even do a similar thing for memfd and drop the hack(?). Then again, not sure what's the policy on any of this is. I'm thinking that it should be documented somewhere, but I could not find anything :-\ Regards, Emil _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
