Received: by 2002:ac8:678b:0:b0:405:464a:c27a with SMTP id b11csp7159qtp; Tue, 1 Aug 2023 11:58:45 -0700 (PDT) X-Google-Smtp-Source: APBJJlEaHm6oD7IbyP9XPTpB9fm04v9IjrhTHzQalQgFt2B6hMTmMgzy6uYhAhQ6ob2gXCt5phNr X-Received: by 2002:a05:6a00:1ac9:b0:668:6445:8931 with SMTP id f9-20020a056a001ac900b0066864458931mr17573161pfv.29.1690916325076; Tue, 01 Aug 2023 11:58:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690916325; cv=none; d=google.com; s=arc-20160816; b=fY6Lq7+vbUeG7AOPusm54wSRBIx4S1EPMJhVQC7ofjr2ujexs3AXrFItTRcltNepf/ p+M9d9ceT7bEW9Ge6hrUYcTEPelL0ikFdUUk1LaABNG13I9jVxIBmluxGeuV/gN7H5u1 W09+oJFr1ItEI8qURxaJtXahFZqNmcWbCIdg6NX8/5SSkO9hFC6fVpGFtYiPdk1QpBg+ mL+RfpW7pcWwUauY/rmRqbMzEXV0Fe5BAB1N+l0PvVvPsoIzqU6Z+gvHLanug3IJtnjc Q6JX2sgLhsfMECvHVJj3eYExveh3LDx/MvUSTWYvUe3cCtIk8LW4+U95wR+4W+AYi808 dICQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=KI7aWHvSDXmhxzHfaalEHg4CqR1G5kysSfQhkQhMeeQ=; fh=Z8ki5Y40HW1Cj4LTSUUzezOiTJ0KadqB9ku6XsqDfAM=; b=xD7W31+6QhHb0D+0+JTh5DLdM5Lfm6irnemCa1Iip3LSO1oXiEbcdLBPS2sjagzqs6 ILhbRMfgSsZYoJMmqOaXNjEMdJaizAkN8I97QH59XBNtOO8qMh4N3KmqWfRzJ4Gc55f7 EiH1vv5xwZruL4aZ6mhWc1HMwfeD7jshTgOvy5TN/dVwfjkmHNK5qw1NZO2RNMDq8te1 QPitIDGf65qUMUhjiiTgx+U64NBMdPjuCnLwpis5UlyCwt+LKt0dkbnS2nay3fwhwerI CN70woVrf0QE47nJnAxCdiwz3pyIa+AXK2NOeTUanMyI2bMTisBlB+8Hqyq4dC5hSPCo CJEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=qLtl8QrL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m134-20020a633f8c000000b0055c92ea1f29si9372263pga.145.2023.08.01.11.58.32; Tue, 01 Aug 2023 11:58:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=qLtl8QrL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234488AbjHARWP (ORCPT + 99 others); Tue, 1 Aug 2023 13:22:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234485AbjHARWM (ORCPT ); Tue, 1 Aug 2023 13:22:12 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 634E7213E; Tue, 1 Aug 2023 10:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: MIME-Version:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type: Content-ID:Content-Description:In-Reply-To:References; bh=KI7aWHvSDXmhxzHfaalEHg4CqR1G5kysSfQhkQhMeeQ=; b=qLtl8QrLHzZR3bYK8L7GyySX8I ui/iPrQEaxDZ2ZfzYU1SSMTdWMhYkH2FZalEJBLrDXxNFoxLyiD+GaUFKCZtShgsGlroNSM1mewkz +K/5Jr4SSllO2UPuk94IptV+69fj7W5EzAdX/LSLm+iTyTRDAoc9qtXJQ+EMnVvG7gkK9vU9FkQ0r NaOSrDyin3BImtyOJRNdcR2ARCfAsk+XaJq0t65rk7g31lgKcxWP7BClvjbC1USYJoOzx2Bkv7Jqb s/Fj+GkFQtVxuKUX/FEtRMkAUM2OUYp0VnZF8342fy2gBxlRZw8VAauLrGHX/slpc1KmP7X/xB17c 1PuKU2JQ==; Received: from 2a02-8389-2341-5b80-39d3-4735-9a3c-88d8.cable.dynamic.v6.surfer.at ([2a02:8389:2341:5b80:39d3:4735:9a3c:88d8] helo=localhost) by bombadil.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1qQt4P-002uSp-2j; Tue, 01 Aug 2023 17:22:06 +0000 From: Christoph Hellwig To: Jens Axboe Cc: "Darrick J. Wong" , Andrew Morton , Matthew Wilcox , Christian Brauner , linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: allow building a kernel without buffer_heads v3 Date: Tue, 1 Aug 2023 19:21:55 +0200 Message-Id: <20230801172201.1923299-1-hch@lst.de> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED autolearn=no 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: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, This series allows to build a kernel without buffer_heads, which I think is useful to show where the dependencies are, and maybe also for some very much limited environments, where people just needs xfs and/or btrfs and some of the read-only block based file systems. It first switches buffered writes (but not writeback) for block devices to use iomap unconditionally, but still using buffer_heads, and then adds a CONFIG_BUFFER_HEAD selected by all file systems that need it (which is most block based file systems), makes the buffer_head support in iomap optional, and adds an alternative implementation of the block device address_operations using iomap. This latter implementation will also be useful to support block size > PAGE_SIZE for block device nodes as buffer_heads won't work very well for that. Note that for now the md software raid drivers is also disabled as it has some (rather questionable) buffer_head usage in the unconditionally built bitmap code. I have a series pending to make the bitmap code conditional and deprecated it, but it hasn't been merged yet. This series is against Jens' for-6.6/block branch. Changes since v2: - fix handling of a negative return value from blkdev_direct_IO - drop a WARN_ON that can happen when resizing block devices - define away IOMAP_F_BUFFER_HEAD to keep the intrusions to the iomap code minimal (even if that's not quite my preferred style) Changes since v1: - drop the already merged prep patches - depend on FS_IOMAP not IOMAP - pick a better new name for block_page_mkwrite_return