User Details
- User Since
- Mar 11 2014, 8:46 PM (583 w, 1 d)
Yesterday
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:
Tue, May 13
If this works I'm fine with landing it.
Thu, May 8
Wed, May 7
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.
Tue, May 6
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)
Mon, May 5
Sun, May 4
Sat, May 3
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?
Wed, Apr 30
exp-run requested at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286477
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. :(
Tue, Apr 29
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.
Mon, Apr 28
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?
Hmm, isn't this backwards as style(9) requires tabs? Probably not worth swapping back at this point, but maybe avoid future style regressions?
Wed, Apr 23
Tue, Apr 22
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.