• 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.

For the record: after discussing with Li-Wen Hsu, it has been suggested to wait until after the 12.1 EOL, and I am actually fine with that.

In D26817#601100, @imp wrote:

In D26817#601097, @pfg wrote:

First of all: thanks!

I should mention this was actually for a hacked linux binary-based intel compiler.

There exists a native FreeBSD [[ https://software.intel.com/content/www/us/en/develop/tools/system-studio/freebsd.html | Intel System Studio ]]compiler that claims to be GCC compatible which may just work (I tihnk it may be based on clang, but I am not sure).

I keep hearing rumors of this item, but never have been able to get a copy through my friends at Intel. I'll have to send a few emails out to see if I can see if I can get access to one, though it's a fairly low propriety. I suspect, based on a lot of things, that this doesn't actually exist, but I'll poke and prod anyway.

First of all: thanks!

Re-state krb524

Update with cy's feedback.
This will be committed about a week after 12.2 is released.

Thanks, will update soon.

Merge latest current