Ping D32504.

Ping on D38115. I've got a patch/commit for moving INTRNAME_LEN to sys/sys/interrupt.h and switching PowerPC/x86 to use INTRNAME_LEN instead of MAXCOMLEN + 1. I'm wondering whether that would be acceptable for reviewing as part of D38115 (the overlap is so heavy it seems to make sense, but others may disagree).

Ping D37869? This does appear a remnant of something long forgotten which likely has no effects now. Just hoping for a confirmation and getting this done.

Ping D37938? I was really hoping to get this through as I would mark D35898 approved once this goes in...

reviews.freebsd.org, where commits go to die?

Updating as per @jhb's comment. Checking I noticed INTR_IPI_NAMELEN should also be part of this and merged those in.

@jhb any thoughts on D37869? As noted this seems to have mysteriously appeared, I've got no idea why this was here and no idea why it should remain.

As far as it goes, I could see moving INTRNAME_LEN from sys/sys/intr.h to sys/sys/interrupt.h, then replacing all the instances of MAXCOMLEN + 1 in the PowerPC/x86 intr_machdep.c files with INTRNAME_LEN. Then INTRNAME_LEN could instead use 2*MAXCOMLEN + 1.

Okay, then I need a direction for D38115/D38116.

Update db_show_intrcnt() rather more than suggested, fully adjust to match how all architectures have been handling intrnames for some time.

Appears struct kinfo_proc.ki_moretdname is defined in terms of MAXCOMLEN. This in turn triggers the KASSERT() on line 2477 of sys/kern/imgact_elf.c. Guessing this means __FreeBSD_version would need to be bumped, but also need to look into the KASSERT().

Rather a long time since rG:c37c2d03b87 when it was increased to 19. Now 23 makes more sense. I'm tempted to suggest 31 since machines are so large now.

This is true, but this is also the nature of fixed-length strings. Copy from too long a string and it will overflow. If the truncation becomes a problem, you can increase the string length. I worry more having two fixed-length strings of different lengths is a recipe for a security hole.

I had originally written D38116 before doing this. Then on review I realized this was a distinct value and that would cause things to explode. This does mean intermediate strings are shorter, but these rarely occur. As such I tend to opt for this approach and getting rid of the booby trap.

Ping for D35559. This will be in the way of most attempts to further merge the interrupt interfaces, so deciding the direction would be helpful.

The Phabricator summary got out of synch since I was having to play hunt down the bug(s). There were multiple issues and multiple problems. One concern is, is it better to always have 1 git commit == 1 Phabricator review? Is it perhaps sometimes better to use one review for several closely overlapping issues?

The one plausible alternative would be to leave the intrcnt_setname("???", 0); lines in-place to ensure there is always one nominally valid entry, and would then be overwritten when the first entry was allocated. This really looks like an early placeholder for something during bring-up testing, which was supposed to be removed once tested, but then never got removed.

The summary dated from a point where it was going bonkers due to issues. Two distinct interfaces had been mixed together and I was having a hard time deciding which was correct and should be maintained.

Minimal delta. Simply double-checked the other conditional is unnecessary.

Making it explicit, I had noticed there aren't any calls to intr_ipi_setup() where the last argument is non-NULL. I'm reluctant to remove such since it is low-cost to leave it in and could be very useful. Having typed that, since this has been lurking on ARM for >5 years and never been used it seems a bit unlikely RISC-V will need to use the functionality.

I had also noticed that, but it doesn't strike me as urgent to remove. I don't know whether @jrtc27 has any plans to use the argument after D35898. I'm kind of wondering whether any of the handlers could be shared with RISC-V given how similar they are on ARM/ARM64.

In D37770#862116, @kib wrote:

Are you complaining about a build failure in not-yet-committed code? It took non-trivial efforts for me to understand this.

Problem is 231d75568f16 and cde70e312c3f add the requirement to #include <sys/systm.h> and #include <sys/pcpu.h> before a #include <vm/vm.h>. Otherwise you end up with implicit declarations of PCPU_GET() and invlpg(), causing build failures.

Note, once this is done the struct trapframe *tf argument to intr_ipi_dispatch() will no longer serve any purpose. I've got removing that handy as a distinct patch, since that is purely cleanup. This also has the effect of making passing the trap frame around in bcm2836.c pointless, which is also handy as a cleanup patch.

My hope is to have this before D35898. Noticing how a similar construct inside intr_event_handle() has lasted a decade after having been deprecated.

The need would be addressed by D37870. Since that is simpler and likely less controversial, go with that.

@mhorne, you're the one who suggested this at https://reviews.freebsd.org/D36610#858610. Almost seems too small to bother with the review system, but at the same time.

History leaves me clueless about this. fd036deac1695 is simply moves it from one spot in the file to another, rG:ecee5704ed500 doesn't mention it at all. If this is simply lint then perhaps time to remove?

As threatened, this is pushing IPI and non-IPI interrupt implementations further apart. Does in fact provide some nice characteristics, at the cost of reducing commonality.

WIP. Initial proof of concept implementation of my take on the suggested approach. This has been tested on ARM64, but there is at least one issue of distinct concern here.

I strongly dislike this interface since it is inferior for most consumers. I will admit it can work if bugs get sorted out.

Having the atomic types which vary matching the size of size_t seems distinctly helpful. Since @andrew is the one who matches, any chance this can pass through quickly?

Alerting the others who might be up for trying. Looks vaguely possible, but at this instant I've got another thing on my queue.

Giving up and simply pushing the urgent bits.

Things got rearranged in a hopefully better way, so marking this as dead. Pretty sure underlying issues got fixed.

Actually, my alternative may simply be removing normal interrupts from intrcnt/intrnames, moving them to struct intr_event and adjusting sysctl_intrcnt()/sysctl_intrnames() to report both locations.

In D36610#859012, @mhorne wrote:

Yes, thanks. I meant kern_intr.c and intr_event(9).

Except this is a non-sequitur as intr_event(9) doesn't relate to anything here.

In D36610#858879, @mhorne wrote:

In D36610#858662, @ehem_freebsd_m5p.com wrote:

In D36610#858610, @mhorne wrote:

In its current form, this change has major problems, and is largely unreviewable. The main issue with your approach is that struct intr_event is not the correct place to stash these counters. This is evident by the fact that you are, in a few places, allocating empty (i.e. no handler) intr_event structures simply for this counter bookkeeping. This is a misuse of the structure, doing something completely outside its intended and established purpose (to execute/schedule interrupt handlers). This approach is not going to be accepted, so please set your expectations accordingly.

struct intr_event does center on this task, but this doesn't mean peripheral portions of this task shouldn't be part of struct intr_event. Could you suggest some test for distinguishing whether a given task/field/datum should be on struct intr_event versus what I'm calling interrupt_t (structures intr_irqsrc/intsrc/powerpc_intr)?

Members of struct intr_event should be primarily (with small exceptions) accessed and managed within the kern_event(9) API, that is, kern_event.c. The counters are allocated and incremented outside of this file, even in the current version of your change. This is a good indicator that struct intr_event does not (and should not) own them.

I'm unsure which way you were confused when you typed that. Since find sys/sys sys/kern -type f -print0 | xargs -0 grep -eintr_event -l | sort =>

Having thought about this, I kind of wonder if intrtab_lookup() might be better than intr_lookup(). Handling the table of interrupts could nominally be separate from the interrupt handling. For instance if one tried to port PowerPC onto INTRNG, the first step would be to add a replacement for the present INTRNG table. I kind of like this change, but someone needs to type something first.

In D36628#858690, @ehem_freebsd_m5p.com wrote:

All 3 are presently backwards-compatible to 2003 FreeBSD kernels (at a minimum) due to how things have been implemented.

Make that any kernel after ecee5704ed500a18a49850acb275aa4ff463bdd3, since intrcnt_setname() has been copied too all architectures. This seems painful for pretty well all uses.

In D36628#858665, @kib wrote:

Option 2 depends on the arch' sizeof(u_long), which means that e.g. COMPAT32 requires shims or does not work. Option 3 means that we use unrelated static constant which I do not like as well. For me, the option 1 has the advantages of being backward compatible simply by its nature, and not having the drawbacks I listed above.

All 3 are presently backwards-compatible to 2003 FreeBSD kernels (at a minimum) due to how things have been implemented.

In D36610#858610, @mhorne wrote:

In its current form, this change has major problems, and is largely unreviewable. The main issue with your approach is that struct intr_event is not the correct place to stash these counters. This is evident by the fact that you are, in a few places, allocating empty (i.e. no handler) intr_event structures simply for this counter bookkeeping. This is a misuse of the structure, doing something completely outside its intended and established purpose (to execute/schedule interrupt handlers). This approach is not going to be accepted, so please set your expectations accordingly.

struct intr_event does center on this task, but this doesn't mean peripheral portions of this task shouldn't be part of struct intr_event. Could you suggest some test for distinguishing whether a given task/field/datum should be on struct intr_event versus what I'm calling interrupt_t (structures intr_irqsrc/intsrc/powerpc_intr)?

I've laid out 3 options, but no opinions.

Any word? I really would kind of like to get this in as it potentially blocks at least one device.

In some situations, source code review systems are about as precise as using individual nuclear weapons to target individual insects. I'm unsure I got this into the right state, so perhaps getting it out of this state will push things forward.

Should also state, with tiny adjustment this built fine for ARM64. I doubt there will be issues.

Thoughts on D35417?

New reviews for the updated D32504? A month seems enough time for someone to comment.

Is there a reviewer in the house for D35559?

Presently there are 4 uses of the NULL => trap_frame functionality. xenpci_intr_filter() in sys/dev/xen/xenpci/xenpci.c, which gets removed by D30006. xen_ipi_bitmap_handler() and xen_ipi_swi_handler() in sys/x86/xen/xen_apic.c. Lastly pmu_intr() in sys/arm/arm/pmu.c.

Updating to newer variation of Xen's interface here. I'd noticed NR_EVENT_CHANNELS and EVTCHN_2L_NR_CHANNELS before, but hadn't known which one was the more recent/proper one.

"FreeBSD Phabricator III: The Search for Reviewers"

Depending on the direction this takes, the bug is already fully fixed by what I've got.

Updating to ensure D36610 stays synchronized with my tree. There was a small delta due to overlap with another commit.

Finally tracked down an actual bug I'd been running into. Since I fear you may wish to take small steps and fix strictly what is buggy, I've split this into a separate commit at the front of my repository. This is clearly a bug with vmstat since this violates the sysctl() interface.

Updating to current tree status. At least one serious bug was fixed.

The number of reviewers and subscribers to D32504 keeps increasing, but the review activity is stale. Since the previous approach was refused, there is now a new approach.

Any reviews for this? While it will take a while to make use of this, I have a definite use for this. I was actually hoping for progress, not merely silence on this.

In D36628#837924, @kib wrote:

You did exactly the opposite to what I suggested: you adjusted userspace to kernel interface, instead of fixing the ABI and keeping old vmstat -i working, by fixing kernel. I do not want to enforce my opinion, but at least I thin we need to get the rationale for going this way instead.

Thank you for figuring that out. Though I just lost rather a lot of sanity points.

I just noticed a serious issue. Turns out intrnames is being interpreted in two very distinct fashions in different places. The resultant output is certainly incorrect and may have been broken before intrnames was introduced, yet never fixed.

This needs moving earlier since it needs to alter xen_intr_handle_upcall()'s declaration.

Splitting this. Depending upon how things evolve, there could be a need to have the two files live side-by-side for a bit. The non-split version was okayed in e-mail.

I've tried this and it unsurprisingly passed. Still have the objection, but noting it does appear to work.

@cperciva could I persuade you to try testing D30006? I'm cautiously optimistic it does in fact work for x86, but the problem is I'm setup for testing ARM64, not x86.

Updating to ensure this is consistent with the state of my tree. This has been moved earlier, before D30909.

Updating per @kevans91 on IRC. I would prefer to have !x86, but !i386 !amd64 is good enough.

Nope. This is purely a one-off which happened to show up in front of me when I was looking at something else. I kind of wonder whether intr_bind() should be fixed and turn into an inline static to start encouraging its use. Right now that single use in nexus was the only use and intr_event_bind() is used all over.

Seems I've run into a benefit of this I hadn't been aiming for. This causes all event counters to be reported. As a result this will report events which aren't hooked up to the platform interrupt subsystem.

@mjg aren't you discussing a distinct potential commit here? I don't believe that is how this is supposed to work.

Having a cpu_t seems a bit overkill. Nearly everywhere uses u_int which works fine. Just in this instance I spotted something rather out of date. On the other hand if I was asked to review a diff which created a cpu_t, I would accept it if it looked reasonable.

Updating to present tree status. Like the others in this sequence, suddenly a distinct approach has a massive impact.

Updating Phabricator due to discussions elsewhere. I suspect this will get further adjustment.