I wonder if we should move the old defines from linux_file.h somewhere under sys/x86/linux/, to prevent future confusion?

Sigh, wrong diff.

Make it buildable on !arm64.

Honestly, for arm64 we need all of Linuxulator backported to 13-STABLE. The one currently there doesn't support some pretty basic things, like signal delivery.

(Tinderboxed.)

Translate the signal number and siginfo.

Rebase.

(Tinderboxed.)

Add back missing chunk.

Follow dchagin@'s advise and make it MI.

On amd64 we have both 32-bit and 64-bit versions of linux_rt_sigsuspend(), though.

Fix trampoline, don't use sv_sigcode_base.

Now, about the upstream - I've looked at https://github.com/eggert/tz.git, and it... well, it does resemble our code, to an extent. Which is to say, their code is quite a bit different from ours. Not sure how to handle this, tbh.

In D30183#702980, @imp wrote:

In D30183#702874, @trasz wrote:

Indeed, this is intended to detect changes to the timezone. However, it's not just one file: it also needs to detect changes to a symlink components in the timezone file path; so while the stat(2) version is fine as it is - it uses the whole path - the kqueue(2)-based one would require keeping open file descriptors for each path component. And with both kqueue(2), and the current implementation using stat(2), we would need some kind of static timeout to avoid calling into the kernel every time.

Wouldn't it be sufficient to check the destination file as well as the symlink itself to detect any changes in anything other than a pathological deployment?

Use CLOCK_MONOTONIC, not CLOCK_MONOTONIC_FAST; remove comment.

(Tinderboxed.)

In D31251#703644, @dchagin wrote:

I think you should start by adapting arm64 sendsig and sigreturn, and trampoline

The change is trivial, but I'd like to make sure I got this right; I have a patch that implements signal delivery on arm64, but it's still somewhat buggy. I'm not sure where the argument got here in the first place.

In D30183#677842, @philip wrote:

Is this NetApp code being merged, or is this upstream tzcode? If this is not upstream, it should be submitted to the tz mailing list for wider review by the tz community.

Use clock_gettime(2) and make WITH_DETECT_TZ_CHANGES a proper build option.

Sorry for delay; I had quite a bit of a backlog...

Thank you for testing. The duplicated entries look interesting; I think this is another reason why the special_media map ignores geom_label(4) providers. I think we should have a sysctl that reports not just providers usage counts, but also their geom class names, so we can explicitely filter out labels, while keeping other providers with slash in their names.

I thought about this, and while I agree in principle with what this should eventually look like, I'd rather stay with the current patch for now. The deficiencies you've identified are real, but they are already there, and I'd prefer to first get finished with UMA CCBs, with minimally intrusive patches like this one, and only after that's done get back to more intrusive stuff. It's just easier to debug (and perhaps merge) this way. Not to mention I don't even have a way to test this code; I believe I'd need two physical isp(4) HBAs with a cable?

(Tinderboxed.)

Fix Xr.

(Tinderboxed.)

So... Scott, are you still against the change as it is?

Thanks :-)

Regen, improve man page description.

(Tinderboxed.)

Sorry for delay. I've just finished dusting off https://reviews.freebsd.org/D28212; hopefully it will hit the tree soon.

Fix problems reported by jhb@, also style(9).

There might be some deferred action going on here, but I'd rather not do any deeper changes simply because it's unrelated to the problem at hand. I'm not even sure how to test it properly - it probably involves an FC HBA (isp(4)?) in target mode.

(Tinderboxed.)