|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2 |
|
| #
5fcbd555 |
| 06-Feb-2025 |
Christoph Hellwig <[email protected]> |
iomap: split bios to zone append limits in the submission handlers
Provide helpers for file systems to split bios in the direct I/O and writeback I/O submission handlers. The split ioends are chain
iomap: split bios to zone append limits in the submission handlers
Provide helpers for file systems to split bios in the direct I/O and writeback I/O submission handlers. The split ioends are chained to the parent ioend so that only the parent ioend originally generated by the iomap layer will be processed after all the chained off children have completed. This is based on the block layer bio chaining that has supported a similar mechanism for a long time.
This Follows btrfs' lead and don't try to build bios to hardware limits for zone append commands, but instead build them as normal unconstrained bios and split them to the hardware limits in the I/O submission handler.
Signed-off-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: "Darrick J. Wong" <[email protected]> Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
|
Revision tags: v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6 |
|
| #
b1992c37 |
| 27-Apr-2024 |
Masahiro Yamada <[email protected]> |
kbuild: use $(src) instead of $(srctree)/$(src) for source directory
Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for checked-in source files. It is merely a convention withou
kbuild: use $(src) instead of $(srctree)/$(src) for source directory
Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for checked-in source files. It is merely a convention without any functional difference. In fact, $(obj) and $(src) are exactly the same, as defined in scripts/Makefile.build:
src := $(obj)
When the kernel is built in a separate output directory, $(src) does not accurately reflect the source directory location. While Kbuild resolves this discrepancy by specifying VPATH=$(srctree) to search for source files, it does not cover all cases. For example, when adding a header search path for local headers, -I$(srctree)/$(src) is typically passed to the compiler.
This introduces inconsistency between upstream and downstream Makefiles because $(src) is used instead of $(srctree)/$(src) for the latter.
To address this inconsistency, this commit changes the semantics of $(src) so that it always points to the directory in the source tree.
Going forward, the variables used in Makefiles will have the following meanings:
$(obj) - directory in the object tree $(src) - directory in the source tree (changed by this commit) $(objtree) - the top of the kernel object tree $(srctree) - the top of the kernel source tree
Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced with $(src).
Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nicolas Schier <[email protected]>
show more ...
|
|
Revision tags: v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4 |
|
| #
ca72d221 |
| 29-Nov-2021 |
Christoph Hellwig <[email protected]> |
iomap: build the block based code conditionally
Only build the block based iomap code if CONFIG_BLOCK is set. Currently that is always the case, but it will change soon.
Signed-off-by: Christoph H
iomap: build the block based code conditionally
Only build the block based iomap code if CONFIG_BLOCK is set. Currently that is always the case, but it will change soon.
Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Dan Williams <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dan Williams <[email protected]>
show more ...
|
|
Revision tags: v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7, v5.14-rc6 |
|
| #
8d04fbe7 |
| 11-Aug-2021 |
Darrick J. Wong <[email protected]> |
iomap: move loop control code to iter.c
Now that we've moved iomap to the iterator model, rename this file to be in sync with the functions contained inside of it.
Signed-off-by: Darrick J. Wong <d
iomap: move loop control code to iter.c
Now that we've moved iomap to the iterator model, rename this file to be in sync with the functions contained inside of it.
Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Dave Chinner <[email protected]>
show more ...
|
|
Revision tags: v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6, v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7, v5.11-rc6, v5.11-rc5, v5.11-rc4, v5.11-rc3, v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4, v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7, v5.9-rc6, v5.9-rc5, v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7, v5.8-rc6, v5.8-rc5, v5.8-rc4, v5.8-rc3, v5.8-rc2, v5.8-rc1, v5.7, v5.7-rc7, v5.7-rc6, v5.7-rc5, v5.7-rc4, v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6, v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3, v5.6-rc2, v5.6-rc1, v5.5, v5.5-rc7, v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1, v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6, v5.4-rc5, v5.4-rc4 |
|
| #
9e91c572 |
| 17-Oct-2019 |
Christoph Hellwig <[email protected]> |
iomap: lift common tracing code from xfs to iomap
Lift the xfs code for tracing address space operations to the iomap layer.
Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Dave Chinner
iomap: lift common tracing code from xfs to iomap
Lift the xfs code for tracing address space operations to the iomap layer.
Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
show more ...
|
|
Revision tags: v5.4-rc3, v5.4-rc2, v5.4-rc1, v5.3, v5.3-rc8, v5.3-rc7, v5.3-rc6, v5.3-rc5, v5.3-rc4, v5.3-rc3, v5.3-rc2 |
|
| #
0ce38c5f |
| 25-Jul-2019 |
Masahiro Yamada <[email protected]> |
iomap: fix Invalid License ID
Detected by:
$ ./scripts/spdxcheck.py fs/iomap/Makefile: 1:27 Invalid License ID: GPL-2.0-or-newer
Fixes: 1c230208f53d ("iomap: start moving code to fs/iomap/") S
iomap: fix Invalid License ID
Detected by:
$ ./scripts/spdxcheck.py fs/iomap/Makefile: 1:27 Invalid License ID: GPL-2.0-or-newer
Fixes: 1c230208f53d ("iomap: start moving code to fs/iomap/") Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v5.3-rc1 |
|
| #
cb7181ff |
| 15-Jul-2019 |
Darrick J. Wong <[email protected]> |
iomap: move the main iteration code into a separate file
Move the main iteration code into a separate file so that we can group related functions in a single file instead of having a single enormous
iomap: move the main iteration code into a separate file
Move the main iteration code into a separate file so that we can group related functions in a single file instead of having a single enormous source file.
Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
show more ...
|
| #
afc51aaa |
| 15-Jul-2019 |
Darrick J. Wong <[email protected]> |
iomap: move the buffered IO code into a separate file
Move the buffered IO code into a separate file so that we can group related functions in a single file instead of having a single enormous sourc
iomap: move the buffered IO code into a separate file
Move the buffered IO code into a separate file so that we can group related functions in a single file instead of having a single enormous source file.
Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
show more ...
|
| #
db074436 |
| 15-Jul-2019 |
Darrick J. Wong <[email protected]> |
iomap: move the direct IO code into a separate file
Move the direct IO code into a separate file so that we can group related functions in a single file instead of having a single enormous source fi
iomap: move the direct IO code into a separate file
Move the direct IO code into a separate file so that we can group related functions in a single file instead of having a single enormous source file.
Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
show more ...
|
| #
56a17898 |
| 15-Jul-2019 |
Darrick J. Wong <[email protected]> |
iomap: move the SEEK_HOLE code into a separate file
Move the SEEK_HOLE/SEEK_DATA code into a separate file so that we can group related functions in a single file instead of having a single enormous
iomap: move the SEEK_HOLE code into a separate file
Move the SEEK_HOLE/SEEK_DATA code into a separate file so that we can group related functions in a single file instead of having a single enormous source file.
Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
show more ...
|
| #
5157fb8f |
| 15-Jul-2019 |
Darrick J. Wong <[email protected]> |
iomap: move the file mapping reporting code into a separate file
Move the file mapping reporting code (FIEMAP/FIBMAP) into a separate file so that we can group related functions in a single file ins
iomap: move the file mapping reporting code into a separate file
Move the file mapping reporting code (FIEMAP/FIBMAP) into a separate file so that we can group related functions in a single file instead of having a single enormous source file.
Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
show more ...
|
| #
a45c0ecc |
| 15-Jul-2019 |
Darrick J. Wong <[email protected]> |
iomap: move the swapfile code into a separate file
Move the swapfile activation code into a separate file so that we can group related functions in a single file instead of having a single enormous
iomap: move the swapfile code into a separate file
Move the swapfile activation code into a separate file so that we can group related functions in a single file instead of having a single enormous source file.
Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
show more ...
|
| #
1c230208 |
| 15-Jul-2019 |
Darrick J. Wong <[email protected]> |
iomap: start moving code to fs/iomap/
Create the build infrastructure we need to start migrating iomap code to fs/iomap/ from fs/iomap.c.
Signed-off-by: Darrick J. Wong <[email protected]> Re
iomap: start moving code to fs/iomap/
Create the build infrastructure we need to start migrating iomap code to fs/iomap/ from fs/iomap.c.
Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
show more ...
|