Thank you for doing this! When moving from the linux headers we moved from the linux types to the standard C types but some leftover BSD types were still being used. These changes actually fix some hidden bugs.

I see @dchagin committed something closely related to current!

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.