Linux with MMU on NEEK

--- Quote Start ---

I think that 'disabling the interrupt for a limited time' is quite difficult because we can't detect the instruction despatch and know what pipeline stage deals with the interruptions.

--- Quote End ---

With embedded software we can assume the user processes to be fair, and thus we just should try to avoid a hanging system due to blocked interrupts and so I think a simple timeout of - say - 1000 clock cycles should do here. Of course the user land process would need to re-enable the interrupt as soon as possible.

But I do see another major issue: The interrupt disabling by a custom instruction needs to be done outside of the CPU and thus the timing will be quite sloppy regarding the instructions. So I suppose 100 % atomicness can't be granted and I think the hardware support should be implemented on top of Hippo's suggestion, just in 99,9 % of the cases preventing the necessity for the ISR to bother with the atomic user code, as the ISR is normally not called any more if the user code is in the atomic region.

The mainline macro for an atomic operations would be

___ custom disable interrupt

___ call appropriate_function_in_atomic_page

___ custom enable interrupt

instead of just

___ call appropriate_function_in_atomic_page

if no custom disable interrupt hardware is available

The Kernel code would stay the same.

This problem might make the SMP implementation even more interesting...

-Michael