In D45552#1148980, @markj wrote:

I'd rather not add new uses of the sticky bit.

and pw(8) could offer to do that as @markj suggests

Do you mean adduser? pw isn't interactive.

From a sysadm's perspective, I also not very sure it's a good idea to add one more (and uncommon) place other than /tmp (and /var/tmp) where non-superuser can write files to by default. It might cause a DoS issue to the system.

Maybe /usr/obj/home/foo can be a symlink to /home/foo/obj instead, though that's perhaps a bit sneaky.

Oh yes, and I even accepted this when I said it. :)

It seems libproc's proc_signame() is just buggy in FreeBSD. illumos calls str2sig(): https://github.com/illumos/illumos-gate/blob/1b1703a43cdfe482965d40a4baae758d05844ac2/usr/src/lib/libproc/common/proc_names.c#L106

FWIW, of the two ports that broke, one had already fixed itself upstream but we just have an ancient version in the ports tree.

libproc is a Solaris interface, so I think it's documented there. proc_signame() is functionally equivalent to strsignal() AFAIK.

This could also be fixed by updating to a newer version, but that involves other change as it doesn't build the same, etc. so I punted on that. The latest release is 2025.1, so the port is about 7 years out of date.

Do we still need this after fixing the PCI bus driver to stop caching the message count?

The dtrace use is under #ifdef illumos but that should probably be fixed to always be enabled as proc_signame() exists in libproc. The plockstat use is enabled on both FreeBSD and illumos (and is also for a call to proc_signame()).

Hmm, my grep found a few uses in cddl tools for dtrace:

If this works I'm fine with landing it.

Also, not sure if it's worth saying, but I chose to use a devctl event that triggers nvmecontrol reconnect rather than adding a new nvmfd daemon to the system similar to iscsid. One reason is that nvmfd is already taken (though I plan to add nvmf support to ctld and retire nvmfd eventually), but adding an nvmfd would also mean either duplicating a bunch of code from nvmecontrol or having to factor it out into a library, etc. I also find the design of iscsid a bit odd as iscsictl basically sends message to iscsid via ioctls using the kernel as a kind of proxy. With this approach, the additional state of a timer for reconnects is kept in the kernel instead, but I think overall that this is simpler.

Also, devctl events seem to be rather inconsistent in naming (upper vs lower case for system, etc.)

The events from devd look like:

Use Dl

I think EDOOFUS is fine.

So maybe one commit to update the krb5 code to use crp_opaque = NULL and then you can just remove the flag entirely in a second commit? The changes look ok to me though (I'm just also fine with now removing the flag entirely)

I just wonder if the panic is a feature that the driver is broken? That is, does the driver still work ok if the ordering is wrong and this patch is applied?

exp-run requested at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286477

In D50089#1142520, @theraven wrote:

This probably needs an exp run, I don’t know how many ports depend on this behaviour.

Also included in https://github.com/freebsd/kyua/pull/265

This fixes the build with GCC.

This makes C++ on FreeBSD less of a special snowflake. In particular, once this is reverted, clang fails the same way GCC fails currently on kyua. Had this not been in place, I wouldn't have pushed a broken patchset to kyua. :(

In block_abi.h there is a GET_BLOCK_FUNCTION macro, and I sort of wonder if a GET_BLOCK_ISA wouldn't be useful instead (maybe if we ever have to fix this sort of thing in the future it will be useful to factor out such a macro)? OTOH, I can't see any other reason for the typedef DECLARE_BLOCK in fts.c except to handle this case, so I think this patch is fine as-is.

In D50016#1141998, @mhorne wrote:

Thanks, this is great.

To me it is preferable to replace the repeated #ifdef __arm__ instances with a named flag, e.g. #ifdef DEVMAP_HAS_STATIC. If it is annoying to achieve then no problem.

In D49970#1141843, @olce wrote:

In D49970#1141669, @jhb wrote:

Originally it ways always tab. The change to permit spaces is recent, and older code from BSD should probably stay as it was to avoid churn. It seems the recent additions to this file just failed to follow the part about "match the existing style".

FWIW, I've added the corresponding commit to .git-blame-ignore-revs (as requested by markj@) so that it doesn't show up in git blame (provided git is so configured).

Would you like me to switch to all tabs instead?

In D49970#1141597, @olce wrote:

In D49970#1141594, @jhb wrote:

Hmm, isn't this backwards as style(9) requires tabs? Probably not worth swapping back at this point, but maybe avoid future style regressions?

I thought that was OK:
"Put a single space or tab character between the #define and the macro name, but be consistent within a file."

There was a mix of tabs and spaces, with a slight majority of spaces (and using spaces is my personal preference as well, as TABs sometimes cause misalignment in diffs).

The registers are 16-bit in the hardware. Linux might be using 32-bit ints just to be more efficient on architectures that don't handle shorts as well. What do the relevant APIs in Linux itself use for the types?

This isn't about namespacing though. Even without the namespacing you'd just have undefined symbols for the symbol without the prefix. Doesn't this just revert your earlier change though, and shouldn't we now drop all of the SKSRCS in all of the other Makefiles (not just the ones I added) since they are now redundant?

In D49955#1141577, @olce wrote:

In D49955#1139102, @jhb wrote:

If this header is used outside of base and the _id[] array is used from it, then we might need to instead disable the warning for this header during the test-includes phase.

Yes. That's why this approach seems somewhat impractical, and also ad-hoc as we would have to do that anytime we add some static constant to some header. This is a rare case, and right now I'm not really sure why we would need to do that. Perhaps to simplify cases where the same header is used in the kernel and in userland?

From D49830, I gather you also tried to disable -Wunused-variable. Isn't that approach enough? It has the benefit to be more generic. That said, the macro guard is anyway needed if the header is included by userspace and the constant not used.

Hmm, isn't this backwards as style(9) requires tabs? Probably not worth swapping back at this point, but maybe avoid future style regressions?

If this header is used outside of base and the _id[] array is used from it, then we might need to instead disable the warning for this header during the test-includes phase.

See D49954 and D49955 for one approach. I also tested patching tools/build/test-includes/Makefile to add -Wno-unused-variable to CFLAGS for these specific headers.