Re: [PATCH 0/7 um: IRQ handling cleanups

From: Anton Ivanov <anton.ivanov@kot-begemot.co.uk>
To: Johannes Berg <johannes@sipsolutions.net>, linux-um@lists.infradead.org
Subject: Re: [PATCH 0/7 um: IRQ handling cleanups
Date: Tue, 24 Nov 2020 16:42:29 +0000	[thread overview]
Message-ID: <25d38c35-c5f9-e0be-fd6d-3a77025e5dbb@kot-begemot.co.uk> (raw)
In-Reply-To: <425d0c637bff893c89ee9374e6f741bbace89f27.camel@sipsolutions.net>

On 24/11/2020 16:39, Johannes Berg wrote:
> 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?

Not any more. All of the serial code used it till recently for write :)

> 
> johannes
> 
> 
> _______________________________________________
> linux-um mailing list
> linux-um@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-um
> 

-- 
Anton R. Ivanov
https://www.kot-begemot.co.uk/

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um