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 445DEC83F1A for ; Mon, 21 Jul 2025 07:10:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D769F6B008A; Mon, 21 Jul 2025 03:10:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D4E526B0095; Mon, 21 Jul 2025 03:10:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C64996B0096; Mon, 21 Jul 2025 03:10:14 -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 B49DF6B008A for ; Mon, 21 Jul 2025 03:10:14 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 574DE80629 for ; Mon, 21 Jul 2025 07:10:14 +0000 (UTC) X-FDA: 83687397948.09.0112EBC Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf19.hostedemail.com (Postfix) with ESMTP id E4D511A0004 for ; Mon, 21 Jul 2025 07:10:09 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de; dmarc=pass (policy=none) header.from=lst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1753081812; a=rsa-sha256; cv=none; b=EvSSJHZij2P19SQT0s3qyOGLp7kDDgZIjne+CbZ1oP9URMGz44T3+H7lS17xy+QcB3Stqx cwOZvx2tFgHM8DnVGf0/vQz0KWr1gt9OQY9lwGgJWCTWWGIFusF50L9b1IIGE9jtCdH54/ bF8eq4oh2DQ5s9sTsUxYqjhdnPngS3E= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de; dmarc=pass (policy=none) header.from=lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1753081812; 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; bh=Nyt6q5MmF0EwBThHEJyG1Xj51zSpmAV/6IggbYApCiA=; b=WHdW1a0crB+dUjI1xrxi5u8rJijDaKUMN2yYpUn4xn7pQOLNDx5KWFS/+hKzVoEvt9+s/7 lYgX0aDUPd4khXQneWfzcUs7inkTnp9eX0R8uQU1fxTspUWue0Ts33vH6in3vXOkJf0ROo 3aQD3pz7q6Id0t6Y5RMlG3+fW2pv9pU= Received: by verein.lst.de (Postfix, from userid 2407) id C0F0168B05; Mon, 21 Jul 2025 09:09:58 +0200 (CEST) Date: Mon, 21 Jul 2025 09:09:58 +0200 From: Christoph Hellwig To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: Christoph Hellwig , Masahiro Yamada , Nathan Chancellor , Andrew Morton , Willy Tarreau , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , 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: <20250721070958.GA29367@lst.de> References: <20250717-kunit-kselftests-v5-0-442b711cde2e@linutronix.de> <20250717132259.GA25835@lst.de> <20250718073743-d4a1f713-f81b-4e89-b3f8-7eed838798e6@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250718073743-d4a1f713-f81b-4e89-b3f8-7eed838798e6@linutronix.de> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: E4D511A0004 X-Stat-Signature: urfc6zis3x9jgrcnwjt9rd5qi6yr7mao X-Rspam-User: X-HE-Tag: 1753081809-800510 X-HE-Meta: U2FsdGVkX19lA5UsUlt3Cdf0jKN9pQDLSd4RCmZSUfhk0b2EwJGHPSUgP0uNGPjxRjUmZ6MNEwEjUVt7yBbkL0Wi0j1DjXuMIRCBWs92PGn5FuzWhtwQkIEH7B5Omdt1EeqCLzXDHej8Jb3tDp5RsTYYYYK+a3doD1vXtIzaEHJdTKPwDv7OfAvMbPB5zkJsS7bJLcYRyOzyZokbsTVpdDT4mdP1BOYYUs/8h0Kwd8/Qg3fjaXVPH9JgIeDQ88Dd/0IK4TM2cmQNzZcOymJy1um9Ww2Ps+XzBaqPEovATe4gT9IcqPJ4Ts2l1gmSYdx5cHH4lZhdQkV1DCFNvY/AStI2fR+kPBkxSsqKfu1j7+IfL4cy8OC9RRu6gcI5uv/gZsML1BihkHcPCtT4fKhy211CqjxowqBN6oAUVcCOflBskMs1FotofIrDVpsxn3jIL9+T2sBapbpzBfjzGNGB61DRoMNhEhiUA/z2m2l/i6F7YRM+etlR/8UVmS2tVSPI5+OJEY/bl+5ROmnmj+7VHroQYZL4iwsVufh6nToWNEPqvcdUlvgnAF/c8Jr5nqoMqo5UZc0+9ubZNCCop65jsRQk/mTu5bzjXvq9AHwSh9PtBeQasVGtNdRhuvI+tDyNAJMijFZ2uXip79Tj+V9/f42j8ZGKJ4Fu34hYNwuLPFkTmIJPWqCWTQYdQCe/NThjl+GCy17Px+FDK1ySxaYa8shfhS8X7Vf5wC3a9QuYODhGn55nx1wJy0ep4avZodtEMwK7asLxN+1PEY5Nj90xy/nj9RKYnNy6EQx6v4rScS37g/bvRtXIoA8Bj5fuIml2Nxj6NWuA3JY2acRhaeEe9fyznYcmX6jdmZDtVCrw8mhsj1xuawO9xS5cauPFaTW2dPNkbpLRggjYJuh27HpLqAh2IuVLEBtcIEHnknudWLnzz/F/12/eIDwVOXw67T9f+8ZfPrIkmn3EWdaPukr clWDHUE+ OUyk/Ekd93vROGsGtuS7vA6/qP0pyWBDaP+yW/w0+1XKD0JZPvmnbiOvJd9Ox25beERfSdmo8h9CHtgo3swglz4ZntbJccttjYjXNdyif6qKZBp57ZNLnEa+mcg== 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 Fri, Jul 18, 2025 at 08:22:26AM +0200, Thomas Weißschuh wrote: > > 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? Told people to use everything remotely file system related to use xfstests instead, and either ignore or suffer from the rest. > KUnit already exists and provides a lot of structure and tooling. That's great. Let's reuse it without having to drive running userspace programs from kernel code. > > 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. Well, then we're done here if you can't engage. > 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. Has anyone actually chimed in and said "it's great that we bloat the kernel to run userspace tests", or have people just mostly ignored it like most things? > > > 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. So why do you want to use it here? And how is is related to the rest of the series? > While having this discussion, can we also work on dealing with the symbol > exports, as discussed before? Well, the scope of the entire series makes it pretty clear that this series as is simply should not go in. You present running pure userspace tests as the solution to a problem you don't even explain, or rather just state very highlevel. Yes, kselftests suck as most people will agree. But the answer is not to add a lot of kernel bloat to treat userspace integration tests like kernel units tests. How about you just fix kselftests, preferably by reusing well known and teststed userland code?