[PATCH 0/7 um: IRQ handling cleanups

[Johannes Berg]

On Tue, 2020-11-24 at 16:34 +0000, Anton Ivanov wrote:
> On 24/11/2020 09:06, Anton Ivanov wrote:
> > 
> > On 24/11/2020 08:58, Johannes Berg wrote:
> > > On Tue, 2020-11-24 at 09:55 +0100, Johannes Berg wrote:
> > > > > I have tried some of what you did when working on timers/epoll -
> > > > > namely turning off the HZ-like nanosleep in time.c. I could not get it
> > > > > to work at the time. So I dropped it from the final version of the
> > > > > patches.
> > > > 
> > > > That one's just weird ... and unnecessary. I can't see why it could
> > > > possibly matter.
> > > 
> > > Or actually ... wait? I thought you were referring to "um: simplify
> > > os_idle_sleep() and sleep longer" but that's not in this set now...
> > > 
> > > Anyway, if you were indeed referring to that patch, it's not strictly
> > > needed - removing it would just mean I couldn't call os_idle_sleep() for
> > > suspend but would have to add os_suspend() or something. OTOH, it didn't
> > > break anything for me (neither time-travel nor normal mode), and I can't
> > > see how it was necessary since if clock_nanosleep() (or now select())
> > > was interrupted by a signal and returned, the signal handler ran too...
> > 
> > The early version of the timer patches were fairly fragile.
> > 
> > There is quite a bit of belt-n-braces leftovers from that, it will be good to clean it up.
> 
> I need to double-check the IRQ delete code. While I made most of it
> lockless and reentrant, I never finished cleaning all of it at the
> end.
> 
> That is where ->purge was coming from.

I have no idea what ->purge is? :)

> There were a couple of places in the serial code which could (and did)
> try to delete an IRQ out of the IRQ handler. I am not sure that is
> still the case as that also got rewritten to implement write IRQs
> instead of IRQ_NONE.

Hmm. OK, but nothing used IRQ_NONE?

johannes