Now named with the __ convention and using libc_private (didn't know about it).

Added specialfd. Okay, that doesn't look too bad. I haven't tested intentionally causing problems from userspace, but other syscalls seem to be doing the same thing as here with user structs, I guess everything that could go wrong is handled inside copyin?

Server-class arm64 machines also have SMBIOS data present. Maybe just condition the actual warning print to amd64 | i386 but try it everywhere?

Another thing. That syscall, would it have to be documented? Or would it be okay to pretend that we have the eventfd(2) "system call" when in reality it's a libc function calling into a private specialfd system call?

In D26668#604707, @kib wrote:

So where we are WRT extending syscall to make it reusable for timerfd ?

I think that having one single codebase, fully based on GPL code for fast porting, is a MUCH more important goal than having display output without GPL (/in base).

oops, also ranlib cxxabi

• Update to LLVM 11 and latest wasi-libc
• libc++ now only supports building from the llvm monorepo
• I've integrated the libc++abi build into the libc++ port to avoid extracting the monorepo a whole extra time for the tiny libc++abi build
• Removed version suffix from the libc++ port since it installs into an unversioned ${PREFIX}/share/wasi-sysroot

Address feedback

In D26668#598052, @trasz wrote:

But then the functionality of libc wrapper would have to be reimplemented in the kernel anyway, for the purpose of linuxulator.

In D26668#597986, @trasz wrote:

Or it might be that I'm entirely out of sync with this discussion; if the public interface is compatible with Linux, then I'm happy :-)

In D26668#597813, @trasz wrote:

No, please, let's keep it compatible with the rest of the world (ie Linux). Otherwise we'll only creating more work for Ports folks for no good reason.

In D26668#596865, @kib wrote:

Could we get away with /dev/eventfd, which would return eventfd on open ? Libc wrapper then handles compat for eventfd(2).

Fix mandoc lint

• Cleaned various things up (based on feedback)
• Added kqueue filter data (hopefully the casts are fine)
• Switched constants to O_ native ones
• Changed stat to non-error (same as the impl for kqueue)
• Moved libc extra functions to the gen subdirectory (this was the feedback in D2172)
• Added manpage (written from scratch to avoid licensing issues)
• Added audit stuff
• Added procstat stuff

In D26668#594456, @danfe wrote:

Or we can keep providing our own, well-designed and implemented set of interfaces instead of copying silly syscalls from Linux. I'd much rather fix linuxisms in software than pollute our kernel.

@hselasky ping

Yeah, CK2 has been abandoned for quite some time.

Ideally everyone would keep that kind of stuff in their global gitignore (core.excludesfile) :)

Probably also worth deprecating maybe.

Oh, also, x11-toolkits/libhandy should be added to the list.

Wow, what is devel/meson of all things doing in gnome? (and devel/cmake, devel/ninja in kde, for that matter)

So far, the only thing that doesn't work for me with W^X is GJS..

ping

@andrew ping

ping.. can anyone commit?

In D24255#575592, @mjg wrote:

Hi. Do you need help updating the patch? I can do the necessary changes.

In D25899#574031, @rigoletto wrote:

I just still don't know why the cache was apparently being updated before but this is something I can investigate later.

No, no, please read this carefully again:

It currently lacks support for changing keys or deleting peers as the wg(9) supports

unfortunatelly there is a need to use PORTEPOCH

In D25839#572447, @manu wrote:

I didn't knew this features, looks useful, is the variable reset by the firmware ? (Or at least is supposed to be ?)

It's a bit funny that the check is == NG_HCI_LINK_ACL (we are speaking ACL anyway), but makes sense — with LE it would be NG_HCI_LINK_LE_PUBLIC / NG_HCI_LINK_LE_RANDOM, and others like SCO wouldn't be used with L2CAP (?)

In D25690#568607, @emax wrote:

can you please explain why using l2cap socket is not good enough?

In D25587#565988, @asomers wrote:

I haven't been able to test it with a hardware crypto accelerator.

In D25552#565508, @markj wrote:

• these checks should really be lifted into a subroutine,

In D25373#565380, @markm wrote:

ECAM hacks? When are those likely to appear? :-)

In D24255#565138, @mjg wrote:

I agree with the patch. What line would like to see in "submitted by"?

ping

In D25509#563827, @hselasky wrote:

Change looks good! Do you need help submitting?

This needs rebase now after the zeroing changes

The clear stall quirk is not necessary anymore (since cr50 firmware 0.3.24), so let's just recognize the device.

Rebased.

In D24787#560671, @andrew wrote:

In D24787#550414, @greg_unrelenting.technology wrote:

Looks like this breaks aarch64, I got a "Synchronous exception" after the loader detects filesystems. Rebuilding after reverting the change fixed it.

Does this fix it? https://github.com/CTSRD-CHERI/cheribsd/commit/ef7b5749427620d6ee1c9834ea6a264f816e99ea

Works on my mcbin with the official SPCR table! :) Might test on other things later.

Sure, makes sense I guess