As a sidenote: one file in bhyve has no license. This is a problem.

I agree with other reviewers: The SPDX changes should be split.

Looks good to me

For the record, his patch first appeared in PR 217560, it's unrelated to the Bug, so I asked for an independent CR.
I will take care of it.

Approved.
Hoping someone else can do the honors though .. I did somethig dumb with my partition table.

There is little interest on this.

In D14193#297843, @fsu wrote:

I am more prefer to initialize stack variables immediately after declaration, but, seems like it is not so perfect practice.
Ok.

Fix compilation.

In D10035#297350, @brooks wrote:

At a glance this seems fine. Is it stalled for review or abandoned?

This is small enough that shouldn't affect upstream merging (also the code is very FreeBSD-specific).
It also respects the general objective of the code.

In D13964#293442, @fsu wrote:

In D13964#293380, @pfg wrote:

In D13964#293266, @fsu wrote:

In D13964#293256, @pfg wrote:

Hmm.. it seems like we are getting to a rather complete ext4 implementation, which is positive. On the downside the code is diverging from UFS. We just can't have both I guess.

There are another features like RO_COMPAT_QUOTA, INCOMPAT_INLINE_DATA, etc, but from my current point of view, it is not so, important, if it will be required to implement it. I think it a not a problem.
The only feature, which will be difficult to implement is RO_COMPAT_BIGALLOC, but I hope it will be not widely used by linux.

I haven't looked at ext4 for a while but most of those features seem to require some obscure collaboration from the kernel, that is out of the scope of the driver. There's also the issue that most of the interesting enhancements in linux assume there is journalling.

I am not sure, that journal feature is required for non-native file system, also it will be difficult to test it.

In D13964#293266, @fsu wrote:

In D13964#293256, @pfg wrote:

Hmm.. it seems like we are getting to a rather complete ext4 implementation, which is positive. On the downside the code is diverging from UFS. We just can't have both I guess.

There are another features like RO_COMPAT_QUOTA, INCOMPAT_INLINE_DATA, etc, but from my current point of view, it is not so, important, if it will be required to implement it. I think it a not a problem.
The only feature, which will be difficult to implement is RO_COMPAT_BIGALLOC, but I hope it will be not widely used by linux.

A sidenote: I just noticed META_BG is supported on ext3 too.

Hmm.. it seems like we are getting to a rather complete ext4 implementation, which is positive. On the downside the code is diverging from UFS. We just can't have both I guess.
In any case , let me mention that EXT4F_RO_INCOMPAT_SUPP was created as a dirty hack: to workaround for features that we were not planning to support at all but that we needed to fake in order to read the partition.
We should remove EXT4F_RO_INCOMPAT_SUPP as it has fulfilled its purpose.

For the record: the changes were committed by parts in a series of commits from r328016 to r328026.