Elliott Mitchell

The issue in the final commit is still there. The present mechanism is `intr_pic_init_secondary()` calls `PIC_INIT_SECONDARY()` then those calls need to propagate the call. Unfortunately only the GICv3 driver attempts...

Given how things are shaping up, this might be superior for my purpose. Alas as the comments mention, what about setup for non-PIC devices with PPI interrupts?

Huh. Hadn't actually realized the extent of that dependency. Yet it is there since needs `INTR_ROOT_COUNT` to be visible elsewhere to work. I guess this is how this works.

Since I need someone, how about @mhorne this time? I was thinking you were planning for the first commit as part of #1363, but now it seems I need that...

Key phrase there "existing PIC drivers implementing `pic_init_secondary()`". Which means if a PIC is a child of PIC driver which does not implement `pic_init_secondary()`, then that child won't have the...

> Something is wonky about your model. If it is indeed a PIC, give it PIC methods, and if necessary, update it's parent PIC to propagate the `pic_init_secondary` call. This...

> smp_rendezvous exists... That may in fact work better than what I had previously been aware of. Thanks. Now to see whether it does work, then to see whether it...

Checking confirmed `smp_rendezvous()` did serve to fill the need. Now I need someone to look at #1281 (one definite bug, several concerning bits) and #1285. I only need the first...

@markjdb prefers `intr_event_destroy()` returning an error for `ie == NULL`. Problem is this is answering the **wrong** question for most callers. Since this is called from cleanup/error paths, the caller...

Putting this a different way, given a random `struct intr_irqsrc *isrc;`, the following **must** always terminate no matter the initial state of `isrc`: ``` while(intr_isrc_deregister(isrc)!=0) sleep(1); ``` (this would be...