On 4 April 2016 at 05:12, Emilio López emilio.lopez@collabora.co.uk 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@collabora.co.uk Signed-off-by: Emilio López emilio.lopez@collabora.co.uk
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