A quick question: most of the patches seem good to be submitted to the upstream. Is there a plan to do so?

In D54230#1238960, @lwhsu wrote:

A quick question: most of the patches seem good to be submitted to the upstream. Is there a plan to do so?

Yes — upstreaming is definitely the goal, and thank you for pointing that out.

Several of the patches in this series are already clean portability fixes (headers, API usage, format issues) and should be good upstream candidates as-is. A few others are more FreeBSD-oriented stopgaps for now (e.g. stubs or feature reductions where Linux-only APIs were used), and I’d like to refine those further before proposing them upstream so they’re acceptable and maintainable on all platforms.

This is the same approach I’ve been taking with sysutils/slurm-wlm: first get things building and usable on FreeBSD, then iterate and push the cleaned-up patches upstream once they’re in a good shape.

I do plan to submit the relevant patches upstream, and I’m very happy to adjust or split them further if that makes upstreaming easier.

Upstream PR opened: hpc/mpifileutils#664 (https://github.com/hpc/mpifileutils/pull/664)
It contains the portability patchset (xattr/fiemap/sysinfo guards + getdents fallback), keeping Linux behavior unchanged and using the static bz2 path on non-Linux.

I've left some comments mostly geared towards trying to shape the patches into something that can be upstreamed- IMO we should probably avoid stylistic changes, and it's a good idea to consider up-front what the upstream project may want to see if one were to consider shedding the patches in their direction.