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

In D25640#567710, @yuripv wrote:

In D25640#567601, @pfg wrote:

LGTM however, I would recommend an exp-run. Many times before have sed changes caused trouble in the ports tree to be later reverted.

Yep, I was looking at the svn log of usr.bin/sed/ and noticed quite a few backouts. I agree that exp-run should be done, but even if some ports break those would need to be fixed instead of rejecting this change as it's obvious bug (and yes, gsed agrees).

LGTM however, I would recommend an exp-run. Many times before have sed changes caused trouble in the ports tree to be later reverted.

I plan to re-commit this as soon as FreeBSD 12.2 is released, to avoid a limitation of the build system.

In D23259#543516, @fsu wrote:

In D23259#543509, @pfg wrote:

Sorry I meant to approve this:
https://reviews.freebsd.org/D24685

(fsu should have comandeered this one instead of opening a new one)

I did not managed with new diff uploading, diff did not want to attach to this revision.
Seems like, I can attach diffs only to revisions, which were opened by me.
Please correct me if I am wrong or lose something in the Phabricator UI.

Sorry I meant to approve this:
https://reviews.freebsd.org/D24685

In D13209#537057, @trasz wrote:

Ping? What's the status of this?

In D21638#531526, @asomers wrote:

Can we close this review now?