Add p_comm

In D57231#1311555, @glebius wrote:

To me this looks like a more generic problem rather than just the watchdogd's problem. Should every daemon have this feature? Or should we say that /var/run shall be mdmfs(8) on hosts with read-only root?

I added authors of the pidfile(3) to add people who definitely thought a lot on this problem.

In D57247#1311835, @glebius wrote:

P.S. Oleksandr, if you got review from any other domain expert than Warner, consider this approved by mentor (me).

P.S. Oleksandr, if you got review from any other domain expert than Warner, consider this approved by mentor (me).

Not a domain expert, so leaving this 100% to Warner. Code & style wise everything LGTM.

This update takes care of PERSONALITY_PATH in addition to PKG_DEFAULT_PATH.

Fill uio_seg and uio_rw.

Thanks! Applied the feedback now.

In D51589#1311788, @emaste wrote:

Is it reasonable to commit this (with the understanding that there will still be issues post-resume)?

Is it reasonable to commit this (with the understanding that there will still be issues post-resume)?

In D57244#1311781, @markj wrote:

Shall we update the kill test in tests/sys/capsicum/capmode.cc to verify sigqueue too?

Shall we update the kill test in tests/sys/capsicum/capmode.cc to verify sigqueue too?

The default pattern is to repeat the queues across the RX queues so if there are 4 RSS queues but 8 RX queues you end up with 1 2 3 4 1 2 3 4 but this is actually configurable at runtime for traffic steering and whatnot

Add a (not even build tested yet) test

Sorry, never mind, I missed that dcb_bound is set implicitly via the union.

In D57096#1311601, @njain15_protonmail.com wrote:

Generally VOP_INACTIVE() is a good place, but a (small) problem with it is that it might be skipped

I had initially called p9fs_fid_remove_all() in VOP_INACTIVE, but as you said, it isn't guaranteed to be called. When I tested this solution, the number of open files on the host still grew quickly. For example, after a poudriere run, lsof shows ~25k file descriptors.

Closing it in VOP_CLOSE keeps this number at <40 for me.

An update to the manual page would also be welcome, as its content is now essentially stale (except on the essential point that zzz serves to suspend :-)).

@ali_mashtizadeh.com

poudriere testport -j FreeBSD15 -p local net/bone-utils

poudriere testport -j FreeBSD15 -p local net/bone-kmods

In D55603#1311570, @afscoelho_gmail.com wrote:

Hi @aokblast, I've found your rapl driver for amd and I'm interested in continuing the work. It's been sitting since March and I'd like to pick it up. Are you still planning to work on it, or would you be OK with me taking over? Thanks

We're almost done; there's just one small issue with additional packaged files, but this is something that's often seen with Python ports that are being patched locally.

In D56835#1311669, @bapt wrote:

In D56835#1311163, @michaelo wrote:

There is one thing I'd really love to see what RC does not have at all: user units like systemd has. It often happens that our users want to run something in the background and I cannot offer anything, but to create an RC for them, install doas, delegate, etc. Too complex. For k5start on AL8 for a specific user I have created a user unit and it does what it should do: keep the Kerberos ticket cache alive. I'd love to hear your opinion on it.

The way I would see it in this case is a new /var/rcd similar to /var/cron/ and people would rcctl user add ./myunit, it will parse and validate and if ok will move it to /var/cron, with rcctl user list and rcctl user del

What do you think?