Message ID | 20230916-nolibc-initramfs-v1-0-4416ecedca6d@weissschuh.net |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp1544390vqi; Sat, 16 Sep 2023 01:16:55 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFpd77WajPNqxqWRGD9w065a1ooNMjkxdtquQx6YHs8GfObB9YNO0deZ8+5tn/YSqxwCE7u X-Received: by 2002:a17:902:6806:b0:1c3:7628:fcb5 with SMTP id h6-20020a170902680600b001c37628fcb5mr3718445plk.62.1694852215060; Sat, 16 Sep 2023 01:16:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694852215; cv=none; d=google.com; s=arc-20160816; b=i7pD9XvGS4GWiRWo4Euq+LJ2upkoSHqLM3xVSqKQ1h3YS7Vq4C26WiNOEhVrAS14au HEMFU9la5AUzCqdxEYZnQnIHvgobVEJAxxfus0nQ5MVWfOHEmp33cPFMp0KiyDwqbQIW SHSgjoa8MgskEFT3zg1yBdRFYU+LzHf65Kyhy1CIsLmpN2FocK4WB8H6iZVuypF9x+Ss sAIG7kmhvVtajBXQHMRlPsSTwaXHEjbXkd4TQfrTLNein7vReQt4D2zZvdMCAcmiCZjT P4/y7+zeWXVtMEH3VVDud9J/q1I3Onb3rt3Z/KHO+iIVjzKPq3tj0APSKJg4l3C6CiNC UJvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:content-transfer-encoding:mime-version :message-id:date:subject:from:dkim-signature; bh=qn6NlpCVDELjGtYtWbx8L1vHBwfKNBzzEn/aUXZpa3c=; fh=1RJOXoR66dTpI6bZFe2nJ1z8thLy2iHoPKQ+QSstjLw=; b=rLp0y5E/uuua5L6wGWJtVhIfh0+d9isFZTd0DRk9jd/6ZohvyDhvjCbSNrJ0CyQHJe uAIG8sORmWuMJE7MD+Qo9OJqMwH0lGUKbqBVfF8q47ir/aSkow/KqIMqzm0xnOXg41fM sqCLTCxIPuB3m4tM9SW74z8y7vv+O3VuNTPY+yxnyFw7BwDbWHpdFq0LUit7grNVuiQ1 mQskl0BIS5WUXwqItEWXIgEfwEjCMuVMMWKZzw/5BmRnZM6Uj3pIXPwEdlFw8W0aEO8P vnEdyQpoj534onYbLJExO4ywtzu8bDfUapNmC4wy+4LvNUppa3ly6LJy0N8QxsJGxOuv asxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@weissschuh.net header.s=mail header.b=hiQi+BpB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id o6-20020a170902d4c600b001beef8ccd05si4982940plg.489.2023.09.16.01.16.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Sep 2023 01:16:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; dkim=pass header.i=@weissschuh.net header.s=mail header.b=hiQi+BpB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 3783585391B1; Sat, 16 Sep 2023 00:17:04 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238426AbjIPHN4 (ORCPT <rfc822;toshivichauhan@gmail.com> + 27 others); Sat, 16 Sep 2023 03:13:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231889AbjIPHNw (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 16 Sep 2023 03:13:52 -0400 Received: from todd.t-8ch.de (todd.t-8ch.de [IPv6:2a01:4f8:c010:41de::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F3060173C; Sat, 16 Sep 2023 00:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=weissschuh.net; s=mail; t=1694848422; bh=iHI+Ng0xOmJAxN0+mPX7GStvN8y9ccAlkUVs7+5qX3I=; h=From:Subject:Date:To:Cc:From; b=hiQi+BpBnZ8kPBTlIqzCwZ3pmNBG8TIbXV1RBc4WCaFChP7NK0t0VmCWKVaGJh3ga bIeeKEVuEiOz+Zpk0w21o75bfdu4QdvOyedWgtIiZcqiSa3Q2dz1fqy+O3uOCRDepV xwkPMb/mcx/LdeJx9A0K1gM083TxT0lZNWGNx6iA= From: =?utf-8?q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net> Subject: [PATCH RFC 0/3] selftests/nolibc: avoid spurious kernel relinks Date: Sat, 16 Sep 2023 09:13:26 +0200 Message-Id: <20230916-nolibc-initramfs-v1-0-4416ecedca6d@weissschuh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-B4-Tracking: v=1; b=H4sIAJdVBWUC/6tWKk4tykwtVrJSqFYqSi3LLM7MzwNyDHUUlJIzE vPSU3UzU4B8JSMDI2MDS0Mz3bz8nMykZN3MvMySosTctGJdk7QUA4PUxGRjI1MzJaC2gqLUtMw KsJHRSkFuzkqxtbUAgu8RgmcAAAA= To: Masahiro Yamada <masahiroy@kernel.org>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Nicolas Schier <nicolas@fjasle.eu>, Willy Tarreau <w@1wt.eu>, Shuah Khan <shuah@kernel.org> Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, =?utf-8?q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net> X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1694848421; l=986; i=linux@weissschuh.net; s=20221212; h=from:subject:message-id; bh=iHI+Ng0xOmJAxN0+mPX7GStvN8y9ccAlkUVs7+5qX3I=; b=sUv4z12Dh7mUB7bLVdXUjCr2wq4+MyXq09xDjB9ezFZmrUf8ENrBTdXe4zwQBinS8U84CBbpo XzAnGLsItcXBtIDZNLeKhuZz7uIjGvvmwgirD83UirRykpF5S+6KQRd X-Developer-Key: i=linux@weissschuh.net; a=ed25519; pk=KcycQgFPX2wGR5azS7RhpBqedglOZVgRPfdFSPB1LNw= X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Sat, 16 Sep 2023 00:17:04 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777181356169927861 X-GMAIL-MSGID: 1777181356169927861 |
Series |
selftests/nolibc: avoid spurious kernel relinks
|
|
Message
Thomas Weißschuh
Sept. 16, 2023, 7:13 a.m. UTC
Currently the nolibc testsuite embeds the test executable into a kernel
image with CONFIG_INITRAMFS_SOURCE.
This forces a full kernel relink everytime the test executable is
updated.
This relinking step dominates the test cycle.
It is slower than building and running the test in qemu together.
With a bit of Makefile-shuffling the relinking can be avoided.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
Thomas Weißschuh (3):
kbuild: add toplevel target for usr/gen_init_cpio
selftests/nolibc: don't embed initramfs into kernel image
selftests/nolibc: drop target "rerun"
Makefile | 4 +++
tools/testing/selftests/nolibc/Makefile | 50 +++++++++++++++------------------
2 files changed, 27 insertions(+), 27 deletions(-)
---
base-commit: 3f79a57865b33f49fdae6655510bd27c8e6610e0
change-id: 20230916-nolibc-initramfs-4fd00eac3256
Best regards,
Comments
On Sat, Sep 16, 2023 at 09:13:26AM +0200, Thomas Weißschuh wrote: > Currently the nolibc testsuite embeds the test executable into a kernel > image with CONFIG_INITRAMFS_SOURCE. > This forces a full kernel relink everytime the test executable is > updated. > > This relinking step dominates the test cycle. > It is slower than building and running the test in qemu together. > > With a bit of Makefile-shuffling the relinking can be avoided. That's pretty nice as indeed it still takes a while to relink it into the kernel. I agree that for running nolibc-test in qemu we don't need a unified image. However I've seldom used it on real hardware and I find it significantly more convenient to use as a single image in this case. Maybe we should just rename targets so that everything qemu-related just uses two distinct images while a "unified-image" (or anything else) still assembles the image into the kernel (BTW the help on the "kernel" target still mentions initramfs). Note that we don't need to modify anything in the build system to create an initrd, I usually make them by hand using "cpio -o -H newc", we don't need anything else here. Regarding rerun, I'd rather keep it for the sole reason that I've used it to check for randomly failing errors (typically the timing-based ones). It's convenient to run the same image 100 times if needed. I'm not strongly attached to it, but if "make run" is slower, then we can keep it. However if you really want to drop it, it also needs to be dropped from the help message ;-) Cheers, Willy
On 2023-09-17 05:22:19+0200, Willy Tarreau wrote: > On Sat, Sep 16, 2023 at 09:13:26AM +0200, Thomas Weißschuh wrote: > > Currently the nolibc testsuite embeds the test executable into a kernel > > image with CONFIG_INITRAMFS_SOURCE. > > This forces a full kernel relink everytime the test executable is > > updated. > > > > This relinking step dominates the test cycle. > > It is slower than building and running the test in qemu together. > > > > With a bit of Makefile-shuffling the relinking can be avoided. > > That's pretty nice as indeed it still takes a while to relink it into > the kernel. I agree that for running nolibc-test in qemu we don't need > a unified image. However I've seldom used it on real hardware and I > find it significantly more convenient to use as a single image in this > case. Maybe we should just rename targets so that everything qemu-related > just uses two distinct images while a "unified-image" (or anything else) > still assembles the image into the kernel (BTW the help on the "kernel" > target still mentions initramfs). Sounds good, "unified-image" is a bit close to "unified kernel image" (UKI) which is similar but different. What about kernel-standalone? > Note that we don't need to modify anything in the build system to create > an initrd, I usually make them by hand using "cpio -o -H newc", we don't > need anything else here. I'd like to keep the build self-contained. But actually the kernel build will always build a minimal initramfs if CONFIG_BLK_DEV_INITRD is set. This config is needed for the nolibc testsuite in any case. The fact that the initrd is always build means that usr/gen_init_cpio is also always build. So we can add "kernel" as a prerequisite to "initramfs.cpio" and everything should work out without any buildsystem modifications. > Regarding rerun, I'd rather keep it for the sole reason that I've used > it to check for randomly failing errors (typically the timing-based > ones). It's convenient to run the same image 100 times if needed. I'm > not strongly attached to it, but if "make run" is slower, then we can > keep it. However if you really want to drop it, it also needs to be > dropped from the help message ;-) Fine for me, let's keep it :-)