Fixes to fixes to 1363 problems

[ehem]

This is kind of urgent as I had been wanting some of this with #1363. Finally spotted the overt assembly to C bridge and that works better for things meant to be shared.

Hopefully got the headers right. Turned out to need LINT-ACPI to find the combination which actually triggered the one condition.

This is kind of urgent-ish.

---

Now doing cleanup from the fallout resulting from people changing things without understanding.

[bsdimp]

It's late here and I'm off to bed. I'm on travel tomorrow and may be jet lagged tuesday, and I'll look at it first of the pull requests. We have a lot of time before the branch to refine and I spent time at EuroBSDCon recruiting reviwers. I wanted to let you know quickly my schedule.

[ehem]

On review seems the one which had been in the middle really needed to be first. Dunno about others, but there seems a phenomenon the first commit usually needs to be last and the last commit needs to be first.

[ehem]

I'm unsure the last one really needs to be part of this. Simply a fragment of where I think things are going, simply illustrating what I was thinking of.

[ehem]

While I'm not too hopeful about the latter two right now, I hope the two at the front can go in now.

[bsdimp]

This code is hard to review. It has taken me far to long to understand it.

First, it undoes the consensus ending to the sys/intr.h machine/intr.h debate. Those changes are recjected outright at this time. We may want to revisit it in the future, but there's not strong justification for doing it now. There's also not support for moving all the defines into machine/intr.h and moving them out of sys/intr.h, but that might be possible. Nothing really needs to have machine/intr.h be completely independent, apart from two arch's exception.S. The current situation is fine for the moment and not worth the churn to fix.

Second, the renaming, at this time, of the interrupt files creates a lot more chrun than the benefit from having a uniform name.

I dislike having interrupt_t. You can't forward declare typedefs. However, given the size of the change, it's hard to know for sure where that's going. I know it enables other things in #1457, so perhaps it would be better there.

So a big part of the problem, as I've pointed out many times before, is that one has to look at a lot of changes to know what's relevant. All the renaming and shuffling and so-forth is a huge mental load to keep track of. Some of it is relevant for later changes, some of it relitigates old battles you lost, some of it is churn that might be marginally better, but gets in the way of understanding the basics of the proposed changes. So when you submit such a hodge podge, and then send me blaimy emails, of course you're going to get slow service. It takes a lot to understand and I'm treating this as a special case to the normal rules of closing stuff with huge amounts of unrelated or at the current time irrelevant churn.

I'm just a volunteer here. You don't get to demand service from me. Especially in the part of the system that can have huge systemic performance regressions if not done properly. So these things take time, and that's the best you can expect.

[ehem]

This code is hard to review. It has taken me far to long to understand it.

Originally it was simpler. Problem is someone broke something which meant more had to get in and the complexity went up. Had this been reviewed months ago it wouldn't have the extras.

First, it undoes the consensus ending to the sys/intr.h machine/intr.h debate. Those changes are recjected outright at this time. We may want to revisit it in the future, but there's not strong justification for doing it now. There's also not support for moving all the defines into machine/intr.h and moving them out of sys/intr.h, but that might be possible. Nothing really needs to have machine/intr.h be completely independent, apart from two arch's exception.S. The current situation is fine for the moment and not worth the churn to fix.

Having headers be standalone is standard practice. This means you can include fewer and development is simpler due to needing fewer #include lines.

Second, the renaming, at this time, of the interrupt files creates a lot more chrun than the benefit from having a uniform name.

This is required for interrupt_t to be useful. This allows source files which merely handle pointers to the structure to #include a common name, then use pointers to the structure without looking inside.

I dislike having interrupt_t. You can't forward declare typedefs. However, given the size of the change, it's hard to know for sure where that's going. I know it enables other things in #1457, so perhaps it would be better there.

It is a step in the direction of commonizing the interrupt frameworks. Might seem low-ish value at first glance, but suddenly you can handle things as interrupt_t * instead of void *.

For #1457 this allows creation of alternatives to intr_event_create() which by using interrupt_t * drastically reduces the amount of casting. While I am not adverse to some casting, the amount in the FreeBSD kernel is unnecessarily excessive. A major problem for #1457 was distinguishing the different cases in io_apic.c.

I'm just a volunteer here. You don't get to demand service from me. Especially in the part of the system that can have huge systemic performance regressions if not done properly. So these things take time, and that's the best you can expect.

The initial steps of #1457 definitely have minor reduction. interrupt_t * is part of an interface which regains some.

Alas it is primarily hypervisors which need common interrupt frameworks. Allows porting to a single system instead of having to treat FreeBSD as 3 distinct OSes.

[ehem]

Gah, #1286 also relies on interrupt_t, but there it is completely fundamental. A common type allows nibbling hunks off the interrupt infrastructures in the hope of converging them.

EDIT: Erk, correct the pull reference.