Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> So if the patch series can be split up into a prep-phase that doesn't
> change any user-visible semantics (including the security side), but
> that uses the fs_context internally and allows the filesystems to be
> converted to the new world order, than that would make merging the
> early work much easier (and then my worry about the later phases would
> probably be much less too).
As a first go, I've rebased the patches to v4.19 (which required no other
changes), folded in some small bugfixes (fix error handling in remount, fix
incorrect user_ns in proc and mqueue) and split the set up.
There are now three branches in my git tree:
(*) mount-api-core. These are the internal-only patches that add the
fs_context, the legacy wrapper and the security hooks and make certain
filesystems make use of it.
(*) mount-api-uapi. This is mount-api-core with the UAPI-visible patches
stacked thereon.
(*) mount-api. This is the original patchset.
"git diff mount-api mount-api-uapi" shows no differences.
Note that the commit "vfs: Implement logging through fs_context" appears in
both sets. I was just going to leave it as macros that just wrap pr_notice(),
but I think it might be wiser to pull it out of line (as will be required
later) and make it produce messages at different levels.
The git tree in question is at:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
David
