Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756589AbcDGOra (ORCPT ); Thu, 7 Apr 2016 10:47:30 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:34644 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756455AbcDGOr1 convert rfc822-to-8bit (ORCPT ); Thu, 7 Apr 2016 10:47:27 -0400 MIME-Version: 1.0 In-Reply-To: <5701E99F.5030102@collabora.co.uk> References: <1457537342-678-1-git-send-email-emilio.lopez@collabora.co.uk> <1457537342-678-2-git-send-email-emilio.lopez@collabora.co.uk> <56F92196.6040604@collabora.co.uk> <5701E99F.5030102@collabora.co.uk> Date: Thu, 7 Apr 2016 15:47:25 +0100 Message-ID: Subject: Re: [RFC PATCH v1 1/9] selftest: sync: basic tests for sw_sync framework From: Emil Velikov To: =?UTF-8?Q?Emilio_L=C3=B3pez?= Cc: Shuah Khan , devel@driverdev.osuosl.org, Daniel Stone , Daniel Vetter , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel , Riley Andrews , linux-kselftest@vger.kernel.org, Gustavo Padovan , John Harrison Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2948 Lines: 70 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