Re: [RFC PATCH v1 1/9] selftest: sync: basic tests for sw_sync framework
Hi Emilio, On 9 March 2016 at 15:28, Emilio López wrote: > 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 > Signed-off-by: Emilio López > --- > > 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). Regards, Emil ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 1/9] selftest: sync: basic tests for sw_sync framework
Hi, El 28/03/16 a las 08:56, Emil Velikov escribió: Hi Emilio, On 9 March 2016 at 15:28, Emilio López wrote: 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 Signed-off-by: Emilio López --- 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]: """ 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. """ Cheers, Emilio [0] http://kernelnewbies.org/KernelHeaders ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 1/9] selftest: sync: basic tests for sw_sync framework
On 28 March 2016 at 13:20, Emilio López wrote: > Hi, > > El 28/03/16 a las 08:56, Emil Velikov escribió: >> >> Hi Emilio, >> >> On 9 March 2016 at 15:28, Emilio López >> wrote: >>> >>> 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 >>> Signed-off-by: Emilio López >>> --- >>> >> >>> 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 ? Regards, Emil ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 1/9] selftest: sync: basic tests for sw_sync framework
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 Signed-off-by: Emilio López --- 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? Thanks, Emilio [0] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/memfd/memfd_test.c#n2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 1/9] selftest: sync: basic tests for sw_sync framework
On 4 April 2016 at 05:12, Emilio López 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 > Signed-off-by: Emilio López > --- > >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 de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
