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
