"git rm" drops the file from the repo, and should appear somehow in the diff. But if you already did it and it doesn't appear I guess it's OK.

Removed most of the stuff that was stale already, specially since the removal of the X11 drivers from the tree.
This remains only as a reference, it is not intended to be committed.

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.

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