From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2E8B93AFAE2 for ; Mon, 6 Jul 2026 08:35:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783326958; cv=none; b=FbhfO1kXA0ZzOj29UOE5le+9vA7XgTEXJh8He/qkSubPg8Wi8SelbVrSi4VzKkucDhoP7DXD8heiSipyCKdAQJt1eNHye3LGNu4VafzFwUrCYmswtuXJHb8PHgp4FeV6o5vluZWvW4hAcxkf7cO/37mNQxME2zs2IAe6nMDQQBg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783326958; c=relaxed/simple; bh=N/hXUKDFTtzj092Go8yLO/kZjznf4SO/lsSm3Dn0G9E=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=BZDKIetGBnlh1hDSCUxZe9cvcK9QkbzAxoj7x7dCEZ0MTyDnidIHbfv4cRynZKXy3daT+/TwExFIyg/LTzTYf3diI5qCESHqIKA1J/C8TbExlWk2NkBE3hStanU8Z4AnBsxw0ToGhc+R2B3CekCia8t739iAOedVofXNgJd19W0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=KWSaUzaZ; arc=none smtp.client-ip=209.85.214.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KWSaUzaZ" Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-2cad4170e8eso32485975ad.3 for ; Mon, 06 Jul 2026 01:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783326946; x=1783931746; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=7p60FQdKaKNOxLAc40FMD98dlWIjxkI8C1nOoFeA1CU=; b=KWSaUzaZ5PCnUY5EXybOCyIBq7W2gCpjQygTPADXZaz4rw6C0k0dBCHGccn5LZcsZF XW6gdOMzs7x5suzQg8DGhUoL9xNKsKjpjT93YhrFKAYDjl57nmkaHqDJLA/kRc6hnNa0 k/XqM7eQeLsmtNnMIe17wvlpAZDm+m8ugv3GTlA0hr0ZTlcN5HxNCahtynkq9IL7u6mv B4sCNaZZiPE90d26ESDoxdT/MzQP5Ynm+4H9hVJ7EsI4AtFBUBIECh5T1BUMrjbl4zvq KNNySBHM0bPBYU6GBiVY7Vf8DLIllavfLTDN0+BnvJrPafD34Q1Vy0oVayHDURAoFHey uPnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783326946; x=1783931746; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7p60FQdKaKNOxLAc40FMD98dlWIjxkI8C1nOoFeA1CU=; b=S+W4mDZlhmxxFLwMIO3WrQjnuQWIpN8lqtxyMaZJCiygNha4QELaciCJjSuVh3BqZB SrHDYbswUVe3R7vC2nENowSi2tTDvC2s8IN9sgCNtXeHSrP7GJALPY30eP4nosyGDr9N 4eMwIfg/riiXZIJDulNcjmFflMdrXx1NpAJy8cXz6Z1MIl5gq3tGco7boz5J6klP+1qh Mq96jUNrBwlKm0O5LRg4oXpTbtKLWUlrtI3QMdjD1p1gn6qzXS/G3QWf5OUe7N0nxRaL IZyqPtl3qmqT0dY4UuGBhbXDOegx4kqb7/V26q6tPMawBSJt6UEWPLoEXeaCb3QmjO1j /YJg== X-Gm-Message-State: AOJu0YzO/gbeL0ozX6cEMWSXZoUjJCji0efiiL/sinGpWGA6vFFT+a4I NzlGaiaMYuBbndWDdpE/oz6ESvnL7iCxhmxhtDZVvOD6lXoKOMDyI6Hq X-Gm-Gg: AfdE7ckevHmUbMvnjO7N209+Sg4Oi6WYMfJPSgYca+eaVxTslCiC9yzHW5MPB+y9gMd U9/WKzrcj18JcKrLcUQs6xj7xiZ4gIAhHCrRa2KmMMLuIltA+DOlWjeXS1Yf1exO05t6zzzut/g XsRcE17/OS/5jORo7L5nNQ02K5ek3pr+lIqNAfhzCFxQUjseKao+UIN6HveKHmF446+ZWIDZFZj VMeyo91hGgqRRSIzrE07iJnobezFN8oWQQ34aGGFGW87NXbR+kVvo/GQx8jB+mrI0GuESkTF1HS GoOAUTZ4qPgBIFX13Q42LXAFKqTFfMx5oNpPUIIM2nnoB42W0qWa4/wedq9brCigC93VVDbGN3h lucxWbND/P6zv28UoUvo8GPItFOWSgeUYZCUcpcDSuYRtCe6te4z+8sPkeGlakvo= X-Received: by 2002:a17:903:b10:b0:2ca:bad4:33a2 with SMTP id d9443c01a7336-2cbb9e38d70mr92253795ad.11.1783326946375; Mon, 06 Jul 2026 01:35:46 -0700 (PDT) Received: from nineveh.sos.local ([131.191.24.68]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ccb0e77725sm5109815ad.71.2026.07.06.01.35.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jul 2026 01:35:45 -0700 (PDT) From: Jeremy Bingham To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, brauner@kernel.org, jkoolstra@xs4all.nl, jack@suse.cz, djwong@kernel.org, Jeremy Bingham Subject: [RFC PATCH 0/1] minix: unify itree_v1, itree_v2, and itree_common Date: Mon, 6 Jul 2026 01:35:35 -0700 Message-ID: X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit For as far back as the git history goes and then some, minix's itree functions have been split across three files: itree_v1.c, itree_v2.c, and itree_common.c. The first two of these files had defines, types, static helper functions, and some wrapper functions tailored for version 1 and versions 2 and 3 of the Minix file systems respectively. Each of these files then included itree_common.c. The reason for this odd arrangement is that there are some stark differences between version 1 and versions 2 and 3 of the Minix fs. Version 1 has doubly indirect blocks and 16 bit block pointers, while versions 2 and 3 have trebly indirect blocks and 32 bit block pointers. By having the separate itree_v1.c and itree_v2.c files that then included itree_common.c, DIRECT, DEPTH, block_t, and Indirect could be defined differently for the two broad types of Minix filesystems while sharing the bulk of their code because the same code in itree_common.c would be treated differently by the preprocessor and compiler depending on which file included it. In other words, DEPTH could mean 3 or 4 depending on if it had been included from itree_v1.c or itree_v2.c. This whole thing came up while some patches I submitted recently to move minix over to use iomap were being reviewed. Having the two separate code paths and includes made that task much more difficult, and a reviewer commented at one part about how it was one way to avoid keeping disk geometry information in the superblock info struct. Parts of this code do not seem to have been modified for a very, very long time, possibly since 1991, but that's no reason necessarily to keep it in place. This patch unifies the two code paths previously used for itree functions. Most of it runs the same no matter what version of the filesystem is being used, but in the places where it doesn't version checks, information stored in the superblock, dynamically allocating formerly static arrays, careful pointer casting, and judicious use of accessor functions for more type safety handle the different cases while still keeping the code more contained and hopefully less confusing to others. As this is an RFC patch, there are many more comments explaning my thought processes and what's going on than would usually be found in a kernel patch submission. Depending on how this is received, I will clean out excessive comments before submitting it for real. This file unavoidably lands as one relatively large patch, but it ended up not breaking down well into smaller chunks that would still build a working kernel. Jeremy Bingham (1): minix: unify the v1 and v2/v3 itree code paths fs/minix/Makefile | 2 +- fs/minix/inode.c | 35 +- fs/minix/itree.c | 744 ++++++++++++++++++++++++++++++++++++++++ fs/minix/itree_common.c | 374 -------------------- fs/minix/itree_v1.c | 67 ---- fs/minix/itree_v2.c | 75 ---- fs/minix/minix.h | 26 +- 7 files changed, 774 insertions(+), 549 deletions(-) create mode 100644 fs/minix/itree.c delete mode 100644 fs/minix/itree_common.c delete mode 100644 fs/minix/itree_v1.c delete mode 100644 fs/minix/itree_v2.c -- 2.47.3