Hi,
On 10-2-27 上午9:10, Dirk Vogt wrote:
Hej, You're right. There is indeed a problem, which we haven't stumbled over yet. That is, because the irq handler runs at at a higher priority in our ddekit implementation. However on a multiprocessor machine this
I don't understand. How can using a higher priority in the irq handler solve/avoid the problem? unless you mean running the softirq thread in a higher priority. Otherwise, the softirq thread can still be preempted and lose raised softirq as I mentioned in the previous letter.
problem would indeed occur. We recognized the problem and are currently discussing solutions. One Solution would be to have one Soft-irq thread for each irq. You can expect a fix for this soon. If mach supports it
Isn't it the current implementation? In DDE, each driver has one irq and one softirq thread?
and you are using a single core machine a suggest to raise the prio of the irq handler thread in the ddekit as workaround.
In my current porting, I already raise the priority of the irq handler, but it doesn't solve the problem.
I am thinking of using a lock to simulate cli/sti. When local_irq_enable() or local_irq_save() is called, we hold the lock; when local_irq_restore() or local_irq_disable(), we release the lock. We can even provide nested locking support if local_irq_enable() or local_irq_save() is allowed to be called multiple times in the same thread.
Best regards, Zheng Da