From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6890474322769477632 X-Received: by 2002:adf:c08c:: with SMTP id d12mr22686108wrf.399.1619444428969; Mon, 26 Apr 2021 06:40:28 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:fb47:: with SMTP id c7ls1809171wrs.0.gmail; Mon, 26 Apr 2021 06:40:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyEIcHSl+V4SuaanR7z5QA3PbYe1TcAXRusixhRWc07HTWgqA6LAGDV4iB3FqjOdg+W09D+ X-Received: by 2002:adf:e907:: with SMTP id f7mr14665781wrm.86.1619444428125; Mon, 26 Apr 2021 06:40:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619444428; cv=none; d=google.com; s=arc-20160816; b=dVBz/N+Iona2P2WpHggI/iRYGBGlI2nH2x+zCgm2t706/ujPCOAFBWTvJcyzIGDCLo ZZWtFzMN8ZvujfyFTHztOhiO5D9UJBGPZdE7AQXaxNzkJ3ftMcorb6JhM35fSO3+cWVK ftM4tfk8HJmRFy3uLVZ7URWYo55csehIRagmaT+lrNPpaYFWZmK3RJcIVtydQJuIEW+r c71n547x5Uu2Y5OV4pWprPhlrOls4wjkYVUBF3Ua3PczsKS8/HSmprqoKmjNMyBFGz4h S6D3B9c0Pa84qyVSVQn2Ag/8KR39+QQ4c+wC5hotUcF/83TYjuZRrFEXQnhvmZIqGC8a kq9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=4sGxprdO2/7pSHfznhoQdQSnwwYIbAgw3+7hpFpPKyY=; b=byEsvI0HBVXfrYIYjs1ecS7iQYDKm3Og2BiEA4yW77xWeI2gTXiS2yHPUtgZHJTNcb BM4mOWKqJp9ExYNtrOm6GgImofaHv0F/8Poge2g5vH2YuoyiJPg+QJl3g5WBPj3ymLXy XPlWDu80vCkGUNQbRsLt09ETn83PwRd5eVGJbLFmPiTdff/bEQLXi4jJL8XhOmK0e6TC 1j0xHzNkZc1en4gbC5qo3P109NWIDBc0qgyJLr+beZ1ntNFoUyZ5swCwezk99KqzaaF8 XYJgxnr03m0Wf5NeNvnu+wxh1uTtvSmpgB9t5WlgCtusMhoF6HBygJgtBC+mK+EBTV4n qWYA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id a4si1344026wrc.0.2021.04.26.06.40.27 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 26 Apr 2021 06:40:28 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 13QDeOMJ015392 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 26 Apr 2021 15:40:27 +0200 Date: Mon, 26 Apr 2021 15:40:24 +0200 From: Baurzhan Ismagulov To: isar-users Subject: Re: [PATCH v4] Add recipe for linux kselftest Message-ID: <20210426134024.GW5391@yssyq.m.ilbers.de> Mail-Followup-To: isar-users References: <20201104214447.25133bb0@md1za8fc.ad001.siemens.net> <20201106143821.6ac5acc8@md1za8fc.ad001.siemens.net> <3ac621cc-0006-7d1a-0a7d-5886143a372e@ilbers.de> <3cfa4810-eeb3-4a66-9558-bbd52b89731cn@googlegroups.com> <20210210112146.511b395a@md1za8fc.ad001.siemens.net> <20210215151609.GT20742@yssyq.m.ilbers.de> <96f074be-a70e-43d7-9eab-e74be12ed444n@googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: 5UC1FFz72WdF Hello Vijai Kumar, On Tue, Mar 30, 2021 at 02:41:08PM +0530, vijai kumar wrote: > Just had a look at that series. Seems like we backport the necessary > patches for the particular kernel version. > This might be hard here, since the changes might me more. > > The original intention to have this package as a separate recipe is to > provide means to use the latest kernel > kselftest testcases. Those seem to be more mature than one available > in lower kernel versions like 4.19. > > The changes might be too much to backport making the approach more complicated. > > In our usecase we are using the cip kernel, and if someone feels like > some testcases needs to be backported, > it needs to be done in the cip-kernel project and not it ISAR. But > there is no strong requirement from the users > for that, they are just okay with using the version that is available > in the latest kernel. This recipe just makes them > achieve that. So, this is a trade-off. On one hand, architecturally it would make sense to bundle all binary packages in the same source package. The advantages would be avoiding code duplication, avoiding fetching different kernel sources in case the two are different (better build time and space efficiency). On the other hand, separate tool recipes allow shipping the latest tools also for older kernels. The advantages are independent kernel and tool versions if different ones are used, avoiding building the kernel if it isn't needed (better build time and space efficiency). Personally, I could live with this implementation until we have a better one. We will play with it and let you know. That said, I still think that in general, we should strive for "one source -- one recipe" implementation and find a good way to refactor this one. Supporting older kernel versions is an important feature; we should be looking how to support newer ones without creating a mess. If necessary, maybe we could split the include file into epoch-specific ones (linux-4.19+.inc, linux-5.4+.inc, etc.). I don't mind if we override upstream packaging mechanisms in part or even fully for the old versions; for the newer ones, I agree that we should at least try submitting our changes upstream. Regarding partial builds, maybe we could have a var choosing which components to build if e.g. the kernel itself is not necessary. With kind regards, Baurzhan.