Re: [PATCH 00/10] convert the majority of file systems to mmap_prepare
Christian Brauner <[email protected]>
| Newsgroups | gmane.comp.file-systems.ecryptfs.general,gmane.linux.block,gmane.linux.kernel,gmane.comp.freedesktop.xorg.drivers.intel,gmane.comp.video.dri.devel,gmane.linux.file-systems,gmane.linux.kernel.aio.general,gmane.linux.file-systems.union,gmane.linux.kernel.mm,gmane.comp.file-systems.btrfs,gmane.comp.file-systems.ceph.devel,gmane.comp.file-systems.coda.general,gmane.comp.file-systems.ext4,gmane.linux.file-systems.f2fs,gmane.linux.uml.devel,gmane.linux.drivers.mtd,gmane.linux.nfs,gmane.comp.file-systems.nilfs.user,gmane.linux.hardware.karma.devel,gmane.linux.kernel.cifs,gmane.network.samba.internals |
|---|---|
| Message-ID | <20250617-ansetzen-mathematik-08f6d9b51f3d@brauner> |
On Mon, Jun 16, 2025 at 04:11:11PM -0700, Andrew Morton wrote: > On Mon, 16 Jun 2025 20:33:19 +0100 Lorenzo Stoakes <[email protected]> wrote: > > > I am basing this on the mm-new branch in Andrew's tree, so let me know if I > > should rebase anything here. Given the mm bits touched I did think perhaps > > we should take it through the mm tree, however it may be more sensible to > > take it through an fs tree - let me know! > > It's more fs/ than mm/ purely from a footprint point of view. But > there any expectation that there will be additional patches which build > on this? > > I'll scoop it into mm-new for now, see what happens. I'm going to carry this in the vfs-6.17.mmap_prepare branch after fixing up the various minor issues spotted in the series.