Minimal changes, otherwise LGTM.

LGTM, and pretty clever to take a boolean to panic.

Thanks!
The printf vs dtrace call choice is not easy but yes as long as the filesystem is still in usable condition I think we should prefer the dtrace call.
You may want to send a diff to @mckusick syncing the UFS change. FWIW, I think UFS should also embrace DTrace ;).

LGTM

I think this is the first time I have seen a char string return value. Can we keep the same coding style as in ext2_check_direntry() ?
That is .. assigning error_msg within the function instead of returning it.

While I agree with the sentiment that panicing is a rather extreme measure, it is better to keep consistency between UFS and ext2.

Hmm.. we should keep consistency with UFS .. and that means panic in ext2_dirbad(). My guess is that for this case you shouldn' t call ext2_dirbad().

LGTM

In D35771#811866, @yikong_google.com wrote:

Can you please commit this for me? Thanks.

• LGTM

LGTM

LGTM, especially since we were not handling the case.

We should probably use PR ## instead of URLs in comments but there is no project policy on that.
LGTM, except for the minor comment issue.

LGTM

I appreciate this effort going on. Getting good implementations of these functions is tough.,

LGTM

LGTM

I will admit I don't like this. Does linux do the same?

Interesting ... I don't see the old protocol described upstream

In D31383#707337, @arichardson wrote:

In D31383#707328, @pfg wrote:

Good.

Please also take a look at NetBSD's change 1.23, "Avoid undefined behavior in fread(3)".

Ah nice, that avoids the branch inside the loop. Should I apply the NetBSD change instead?

Please also take a look at NetBSD's change 1.23, "Avoid undefined behavior in fread(3)".

Remove deprecated unlocking, pointed out by kib

Duh ! I see now.

In D30548#686179, @kib wrote:

In D30548#686034, @pfg wrote:

In D30548#686024, @kib wrote:

In principle, the optimization is perhaps useful for unbuffered consumers.

The locking in your patch is incompatible with the FreeBSD implementation. Test the patch in multithreaded program.

Bah .. you are right, I am quite rusty on FreeBSD and I just copy-pasted. This shouldn't have compiled.

It should compile fine, but it cannot work.

What you need to do is to remove the wrong unlock line.

In D30548#686024, @kib wrote:

In principle, the optimization is perhaps useful for unbuffered consumers.

The locking in your patch is incompatible with the FreeBSD implementation. Test the patch in multithreaded program.

In D29917#672452, @danfe wrote:

@miguel_gocobachi.dev wrote:

Thank you. I will go for the name BeFS because I noticed other things using this name

Yes please. BFS is way too generic and we had experienced name clashes in the past because they were too short. Even better if it could be done consistently, i.e. applied to macros like BFS_OS_NAME_LENGTH and BFS_SUPER_BLOCK_MAGIC1.

We don't have the naming conflict here, but befs is OK.
FWIW, there is a fuse version which would be useful before considering a kernel version.

While the ext_time_t approach is valid and it also consistent with UFS2, it is usually faster to use 32bit values so you *could* use casts. Either way is valid so I won't object.

LGTM, but ultimately cem@ is the local expert.

Using all uppercase messages is bad, unless there is a panic.
Otherwise, LGTM.

LGTM

Do not touch inode.h.

Minor knits, otherwise LGTM.

FWIW, I'd like to see OpenBFS (haiku OS) supported some day on FreeBSD, so this support is welcome.

FWIW ....
I read gcov, but sys/gnu/gcov survived. Perhaps it was meant to be gprof?

LGTM, but gad is the expert.

FWIW, I got the BSD-1-Clause License approved by OSI, Approval is not terribly important as we only use it for a couple of files in the tree.
OTOH the very simplistic license would be useful to adopt for source header files (*.h).

Wow, I should have dropped it by accident: it was surely my intention to keep couchdb in services.

In D26966#618725, @yuripv wrote:

Looks like export is only ever used in export_pam_environment(), where its return value is ignored.