This did seem a rather better approach to the issue, but I still have the other approach.

To put it a different way, intr_event_destroy() is called from recovery and shutdown routines. Callers have likely already received an error status from another function (since they passed a NULL event), yet now they're trying to recover and get yet another error indicator. Recovery is impossible.

This seemed a rather simple, yet high value point. Yet it sat here with no reviews and unable to step forward. Then the garbage of D47002 got approved in 5 seconds. I get the message, no it is not merely people got tired of trying to converge the interrupt systems. Many people simply didn't care and unintentionally made it extremely difficult.

I'm guessing Phabricator/arcanist got updated and so new things are being created with dependencies matching git commit order (which is a good rough guess, but not always perfect). Appears D48052 is not a parent of D48053, but instead a parent of . Mainly D48052 and D48053 need to be committed before D48054; but D48052 and D48053 can be committed in either order.

Looks reasonable to me. Though the option is primarily to allow removing the timer on ARM/RISC-V (where it doesn't presently work). I'm unsure whether it is possible to avoid on x86.

Updating, point to possible solution for what I need @mav to review (remove ->pic_enable_intr() call from clock.c/875b8844bec hack).

In D47846#1090926, @imp wrote:

yea, the only question I have is if we move all the assembly values into machine/intr.h, duplicating one or two across architectures and include machine/intr.h for the assembler, or if I leave it as I have it inthe review. @jhb

Seems the issue in sys/x86/isa/clock.c originates from rG:875b8844bec. I'm unsure how to work around the issue, rG:49ed68bbf3c makes the situation worse.

Yet the solution to the underlying issue is also quite simple (already have a commit on GH, I can upload to Phabricator if desired), so perhaps that should be considered? If nothing else that gives an additional option which may turn out rather superior for the long term. The underlying issue has likely been causing all sorts of (perhaps minor) trouble for some already.

Then when looking for something else discover sys/x86/isa/clock.c has the call i8254_intsrc->is_pic->pic_enable_intr(i8254_intsrc); without the ->pic_enable_source(). I lack hardware to test this, so I'm unsure of the effect.

In D47846#1090953, @jhb wrote:

I don't see a compelling reason to duplicate values across architectures. That would seem to defeat the point of the shared header file.

This seems reasonable, though I'm concerned with the present approach.

I dislike making the interrupt headers assembly-safe merely for this. If this is really desired, then have the all constants in machine/intr.h (which is better anyway).

Unless there is something I'm unaware of, INTR_IRQ_INVALID isn't ever used by assembly-language.

Closing in light of rG:700f7e793b3793606fbb9942eda03ac02991c126.

Updating to jhibbits@ preferred method of accomplishing the goal. This is only expected to be used during a transition period, so hopefully will disappear later.

Note to anyone else who happens to run across this. Indeed, (mask_fn)isrc->is_pic->pic_disable_source could be substituted for the intr_disable_srcargument to intr_event_create() inside intr_register_source(). Issue is after this commit, #1457 first modifies intr_disable_src and then later completely removes it. At the point where this is the wrapper still needs to be retained.

Mostly looking for a review from @royger I'm unsure whether this additional call really needs to be retained, versus being unnecessary.

As proposed.

Reclaiming/reopening as per note in D47279. This could be a better solution to the issue pointed at.

In D47279#1078374, @jrtc27 wrote:

Says the person sending messages laced with hostile sarcasm.

Wow, so friendly to revert something immediately after the person gets a rebase done and without informing them about discussion which was occurring. Also odd how there is suddenly all this discussion now when there was no activity on the original source for more than a month. I tried to get everyone's attention who is on here.

This is part of a fascinating end point I reached in combination with other commits. Specifically, Github #1457. I think this is better to review via GitHub, since the full git support allows viewing as part of the full series. Phabicator isn't all that well suited to the role.

The problem which this was a part of solving looks like it will be dealt with via other means. As such dumping this.

Once the fixes to the multi-root support are in, using those will address my need. Unfortunately the problem brought up by the comment. "QQQ: Only root PIC is aware of other CPUs ???", still remains. This is no longer productive for me, so abandoning this one.

If someone is up for forward progress on this trivial issue, I recommend doing: (assuming your remote for FreeBSD-Github is "github")

I had thought that it might be better, if you were going to push this through quickly, to simply push past and deal with the aftermath. Issue is you've now taken long enough for me to start organizing my thoughts better.

Having two distinct names for the interrupt headers serves to interfere with most efforts to converge the interrupt frameworks. Simply rename all of them to "machine/a_bikeshed_string_for_sed_to_target.h". Another name could be substituted, but right now simply have a random one for this commit.

I was simply looking for a pause, so now removing the pause.

I guess I'll have to leave it there then.

In D47002#1071817, @imp wrote:

If it breaks the Gordian Knot, let's create machine/interrupt.h to contain the APIs that are common between INTRNG and !INTRNG, lets do it. Let's see where we wind up, and we'll discover if it's too trivial or not.

In D47002#1071806, @kevans wrote:

In D47002#1071777, @ehem_freebsd_m5p.com wrote:

Take a look at the first two commits of GitHub #1286. The first two create an interrupt_t type definition for things which only handle pointers to the architecture type, but don't directly examine the contents. If you have to #include sys/intr.h, then it is literally impossible to write truly machine-independent beyond having a void *.

Where did someone dictate that you have to include sys/intr.h, and for what? With the little details you've given it sounds like you're imposing restrictions on yourself, there's no hard requirement on INTRNG to include machine/intr.h. I don't see anything in your change offhand that's prevented by INTRNG consumers wanting sys/intr.h instead of machine/intr.h. You can include just the header you actually need.

In D47002#1071804, @imp wrote:

If you need a type that's really MI, define it in a MI header (say machine/types.h or invent machine/interrupt.h). End of problem. There's not even a need for #ifdef anything. Just include machine/interrupt.h which has a well defined interface (because you just defined it and it has no historical issues).

In D47002#1071782, @jrtc27 wrote:

You already need to #ifdef INTRNG for machine/intr.h, doing it for sys/intr.h is no worse in that regard. So kindly calm down.

In D47002#1071690, @imp wrote:

This is the more typical pattern.

See sys/endian.h including machine/endian.h for but one of many examples (though that example is a bit convoluted in spots due to slight differences between endian.h, sys/endian.h and machine/endian.h consumer expectations.

NO ABSOLUTELY NOT. The reason is this makes architecture-independent source impossible without a #ifdef INTRNG.

I suspect this needs to now be rebased onto main. I've got concerns, so I would like to take a look at what comes when the interaction with the FIQ stuff comes in. Simply asking looking for a temporary pause.

@jrtc27 my one concern was to alert everyone here that discussion has occurred elsewhere. I was thinking discussion might have ended here, but it is now clear it has not terminated. Now I know I need to be tracking both.

In D40161#954037, @kevans wrote:

I was trying to avoid enums because I didn't want to cement us into new KPI for other types when we can easily discriminate with an argument, and enums add room for error since they're a C construct.

This is a real problem with having both Phabricator and GitHub. This got copied to GitHub and now there is some discussion there. This was likely due to the long pause after September 7th, someone really wanted this feature.

The one comment can be done on commit.

This is basically okay, but there urgently needs to be a comment here. At a future point the versions of Xen which lack this hypercall will no longer have any support and the error should instead be returned. This will likely be at least 5 years before this can be done, but there should be a comment with specific information.

Seems fine, though as this is x86-land so I'm not doing testing. I do strongly prefer this being a separate commit from D46122 as it now is.

I had expected to simply handle D44251 as a squash review, though this works too. I do want to note what the output of devinfo -u looks like.

I doubt it is possible to converge the interrupt infrastructures without exposing this interface. This interface is the common point duplicated on every architecture, so things go through here. The way to discourage access to this interface for your alternative interface to provide valuable services which simplify consumers. For my case (Xen) where the drivers already exist, using the higher-level interface would be much harder.