[PATCH v6 0/3] fuse: compound commands

[Horst Birthelmer]

In the discussion about open+getattr here [1] Bernd and Miklos talked
about the need for a compound command in fuse that could send multiple
commands to a fuse server.

This can be used to reduce the number of switches from user to kernel
space but also to define atomic operations that the fuse server can
process as one command even though they are multiple requests combined.

After various dscussions in the previous versions I have added an
automatic sequencialization in case the fuse server does not know
the compound. In this case the kernel will call the requests one
after the other.

In case the requests have interdependent args there is the possibility
to add an arg conversion function that has to be provided which 
can handle the filling of the args right before the request is called.
This function has access to the whole compound, so basically to all the
requests that came before including their results.

The series contains an example of a compound that was already discussed
before open+getattr.
    
The pull request for libfuse is here [2]
That pull request contains a patch for handling compounds 
and a patch for passthrough_hp that demonstrates multiple ways of
handling a compound. Either calling the helper in libfuse to decode and 
execute every request sequencially or decoding and handling it in the
fuse server itself.

[1] https://lore.kernel.org/linux-fsdevel/CAJfpegshcrjXJ0USZ8RRdBy=e0MxmBTJSCE0xnxG8LXgXy-xuQ@xxxxxxxxxxxxxx/
[2] https://github.com/libfuse/libfuse/pull/1418

Signed-off-by: Horst Birthelmer <hbirthelmer@xxxxxxx>
---
Changes in v6:
- got rid of the count in the compound header
- added the automatic calling of the combined request if the fuse
server doesn't process the compound and the implementation allows it
- due to the variable max operations in the compounds request struct 
fuse_compound_free() had be brought back
- Link to v5: https://lore.kernel.org/r/20260210-fuse-compounds-upstream-v5-0-ea0585f62daa@xxxxxxx

Changes in v5:
- introduced the flag FUSE_COMPOUND_SEPARABLE as discussed here
- simplify result parsing and streamline the code
- simplify the result and error handling for open+getattr
- fixed a couple of issues pointed out by Joanne
- Link to v4: https://lore.kernel.org/r/20260109-fuse-compounds-upstream-v4-0-0d3b82a4666f@xxxxxxx

Changes in v4:
- removed RFC 
- removed the unnecessary 'parsed' variable in fuse_compound_req, since
  we parse the result only once
- reordered the patches about the helper functions to fill in the fuse
  args for open and getattr calls
- Link to v3: https://lore.kernel.org/r/20260108-fuse-compounds-upstream-v3-0-8dc91ebf3740@xxxxxxx

Changes in v3:
- simplified the data handling for compound commands
- remove the validating functionality, since it was only a helper for
  development
- remove fuse_compound_request() and use fuse_simple_request()
- add helper functions for creating args for open and attr
- use the newly createn helper functions for arg creation for open and
  getattr
- Link to v2: https://lore.kernel.org/r/20251223-fuse-compounds-upstream-v2-0-0f7b4451c85e@xxxxxxx

Changes in v2:
- fixed issues with error handling in the compounds as well as in the
  open+getattr
- Link to v1: https://lore.kernel.org/r/20251223-fuse-compounds-upstream-v1-0-7bade663947b@xxxxxxx

---
Horst Birthelmer (3):
      fuse: add compound command to combine multiple requests
      fuse: create helper functions for filling in fuse args for open and getattr
      fuse: add an implementation of open+getattr

 fs/fuse/Makefile          |   2 +-
 fs/fuse/compound.c        | 308 ++++++++++++++++++++++++++++++++++++++++++++++
 fs/fuse/dir.c             |  26 ++--
 fs/fuse/file.c            | 137 +++++++++++++++++----
 fs/fuse/fuse_i.h          |  49 +++++++-
 fs/fuse/ioctl.c           |   2 +-
 include/uapi/linux/fuse.h |  52 ++++++++
 7 files changed, 541 insertions(+), 35 deletions(-)
---
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
change-id: 20251223-fuse-compounds-upstream-c85b4e39b3d3

Best regards,
-- 
Horst Birthelmer <hbirthelmer@xxxxxxx>