From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id ADC1CC83F1A for ; Fri, 18 Jul 2025 06:22:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D4746B00BA; Fri, 18 Jul 2025 02:22:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 284D76B00BB; Fri, 18 Jul 2025 02:22:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1744D6B00BD; Fri, 18 Jul 2025 02:22:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0688C6B00BA for ; Fri, 18 Jul 2025 02:22:36 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7902A14031F for ; Fri, 18 Jul 2025 06:22:35 +0000 (UTC) X-FDA: 83676391470.12.1CE65FE Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf30.hostedemail.com (Postfix) with ESMTP id 73D548000D for ; Fri, 18 Jul 2025 06:22:33 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=pgW4XT1V; dkim=pass header.d=linutronix.de header.s=2020e header.b=26bpvT2r; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf30.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752819753; a=rsa-sha256; cv=none; b=5GgZDJlGRdn+qCksI9fKdgHtO9xmHPZ72jxHaEysmRiUMOGZLoYjEPlmHWYTQMSscHDiJg ODjR7cWbW1ZQAfTLoCwzwG3fGyxhFzbpvyRieZbKZ+5KOdURVipfB0gJinQehVM5F1zPjh V34qjktSl4/NInoZLX42qJK6Nbm5SLY= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=pgW4XT1V; dkim=pass header.d=linutronix.de header.s=2020e header.b=26bpvT2r; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf30.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752819753; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=r15MXxvdvuJjkg2dcxT5OmMbq5ijcwE+26Y6C9Smhh8=; b=OjmtwpezVIxnP+WrkScIDgcjneBAHnkAMnW+/leZ+7CGoPrls8Ibr4MAg75ssraRb0/4bv RHst1bj+WzIrY4kgjNETlwUA8MiXtd5Fab7CAkKj2MHagZXwvJQ8i9Of2DUZYihC46/TDv gCRaq04210nAgegyMFxiGalVhtNjz8s= Date: Fri, 18 Jul 2025 08:22:26 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1752819750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=r15MXxvdvuJjkg2dcxT5OmMbq5ijcwE+26Y6C9Smhh8=; b=pgW4XT1VmFV5nWy0E58ydruyYpt1gnI1VRPiYxoBNM5pJxEII+vO0ZJSLj31AAOU1a0V4X hC2kuGioG9WquczLzyVQ34xvvyXs3bZX4pyvei4WuKKFlqjb6F5MhZiAQrBxJ3iEm+rjzR E2dpnPABOqx7JndQXnwJPDbRJxDedZD7dUjeEJh3/ipMh/jjvHA/xsg8PWyBEmgntKsrQH LIwRN1hsH27w4Qyz5OkkWzPxepT0Df3WbRpAVMNLvzJWeGyiEaGCdKfUvctio5K2p/w1lF 5Lv7lQTkeYARXuEWZ7ytGwdxzHbG8nYF/X73l3B1wu2SljbX7Dwt8WFmW0m8Nw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1752819750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=r15MXxvdvuJjkg2dcxT5OmMbq5ijcwE+26Y6C9Smhh8=; b=26bpvT2r5Gg6wqblcqwvNsj8QyQRBJSt2YcdRWznzsotPK6Oh5ANbFa38/u4eDdO80CSXT 9372IrTxpC1ydzAg== From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= To: Christoph Hellwig Cc: Masahiro Yamada , Nathan Chancellor , Andrew Morton , Willy Tarreau , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Brendan Higgins , David Gow , Rae Moar , Shuah Khan , Jonathan Corbet , Nicolas Schier , Kees Cook , Alexander Viro , Christian Brauner , Jan Kara , Luis Chamberlain , Christophe Leroy , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com, linux-doc@vger.kernel.org, workflows@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v5 00/15] kunit: Introduce UAPI testing framework Message-ID: <20250718073743-d4a1f713-f81b-4e89-b3f8-7eed838798e6@linutronix.de> References: <20250717-kunit-kselftests-v5-0-442b711cde2e@linutronix.de> <20250717132259.GA25835@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250717132259.GA25835@lst.de> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 73D548000D X-Stat-Signature: mu85jam5qc9id4koyoeu8imp86thmffs X-HE-Tag: 1752819753-989283 X-HE-Meta: U2FsdGVkX1/T/ndUOkCf9vBh70rOUBRkjs+kzDjH3yoPxSwYc5aCjLV/xlZPkjYNpvpX+vTRBhguQqDFyaQ/TQSXl/rHlAncAFcdzxIDqtffLjzHZe8awbeMAV9k4yH5W65PhOdLqmh2/mf+P9XCzL4cH9/BUihN4oZSDivPXn7sELfLbn0xbVzM9PAhFTcmVeEiG5Bqn2bV8JwgYFDFvezmYNWW261RzORMQhL9Tc5o4nW2hWNp9G/4lo7cquSRSyJim4gzuV8ZTkMJImIaFHxgoy8nnx/q1k2n7NF4mqaSaaorsuQIm+Y11E06maWoLXoc4Djig0UZzBN4dL64Oq2O2dI68ZvylklXdSO5yiRVsIGVVjMWENQn9vs+QpmcZOZLg53FuWtPH8sAfcXffy1OXU39N2i/DhIwb0UuI6G1Q/eaRPM26pKnnZjH6Nrk/DPRsnwAXDLXS7cAARsP11R89wBvZxlG//wMe6T+caKRRAIFg55Rgec9dCtVThFOfeuIBOD7MQi4Zc+scWpWNp5Al3laIqxE22FnwIOaJ6FAnDtpvQ/96MEPozcuk95f+5lg+SmOqPnxyUFaHi5Mtv6bOCc+kWP4pUsiRw1FfFRznofLMtPTqZOvi6tmR4eFP8fDHme6GhjL3i1qaWpsjKMwefM5v81uIDHwG77ZDtHRNh+4GiIQDr3P4cUkRyNzh6keEsJvVYWaTlWyMb2fSSUxxu5aadBAmCNs5fWKZ9/c27TfGDqkwZkxVQ+yJAaXgb2/7H9eLjyaZyExxaLfkGua/OQV8HBuEVfFjJPaeN68lvTlM7vZPRG8IhJJBaHTD1drVTFonN2QjscqL1y/C5SEJ6tfVBnVFJ4iV1pBiN7e0eWKuABVAG4jGjMn3ksJS0rbpFdFvKIapWe+7Vbfj8Kf1tjoKnOWBACDGaJrmGe/H6bf8sa9Zr5rW+vI2/0CHVjJ9Go8YUGOZYosig5 3qTpup6G PdgiDxuqsob3FLqpAtt1WXn1IAgkG8xwCx9tQ1qwQV1+rzsn9Bui7WoBvApZz5sFR84T98gI9fMsUsWwu/PA44y0fSI/fOiNiby7e/WxJJ00nhlnt9k+vlihhookTQQYk/TYms+emch+8ebjSLFu7vdv8Zq4Q7ql6b4A/U8zaOD97Mr9jm1iO5CuO6fFc/tI17wbY4lldVG6T4upw8ZnUF39z/hXsfzjqPQibIVL+B4xkyFM/b1QYA5Y/cIt1/9/L5nxrDg3WILst6vIrfVscS5kM3+ozIUbff5pppsa2bdt6TVsluZozJ1QTUCkDgOZvD7bzREZp63l+/1qEzVvYH+zymrajNLfd/svY69R4CuX1PFLihTCEVwO0jokLRPVQRhzOWtGbHMKvvNGWZyW/TMoNCHyZPEXbxRwYJqkeIJODOFZr/9BIBusaiQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jul 17, 2025 at 03:23:00PM +0200, Christoph Hellwig wrote: > On Thu, Jul 17, 2025 at 10:48:02AM +0200, Thomas Weißschuh wrote: (...) > > This series aims to combine kselftests and kunit, avoiding both their > > limitations. It works by compiling the userspace kselftests as part of > > the regular kernel build, embedding them into the kunit kernel or module > > and executing them from there. (...) > I had my own fair share of problems with kselftests, > mostly because of the lack of structure and automated way to run them, How did you overcome these issues? Why does everbody need to reinvent the wheel here? KUnit already exists and provides a lot of structure and tooling. > but adding them to the kernel (or a module) is overshooting the target > by far. That's a subjective statement without any reasoning I can engange with. I would be happy to do so, but for now I can only say that I disagree. The patches have been on the testing-related lists for some time and so far nobody had an issue with this aspect. > > If the kernel toolchain is not fit to > > produce userspace because of a missing libc, the kernel's own nolibc can > > be used instead. > > Is nolibc enough to run all the selftests? It is not and most probably won't ever be. The maintainers of each testcase will decide which libc to use. Like it is in tools/testing/selftests/ today. Some use glibc, some nolibc and some can do both. > If so we should just do it unconditionally, but linking to different > libraries by availability seems a bit problematic. Agreed. But as mentioned above it will be the maintainers decision. Only the preinit executable will need to support all configurations so needs the availability check. For the framework selftest it also makes sense to support as many configurations as possible. For the example test, any configuration is fine. (...) While having this discussion, can we also work on dealing with the symbol exports, as discussed before? Thomas