| |||||||||||||
|
| |||||||||||||
ARM SoC launched with Linux support (Linux Devices)ARM SoC launched with Linux support (Linux Devices)Posted Jan 9, 2009 22:21 UTC (Fri) by jgg (guest, #55211)In reply to: ARM SoC launched with Linux support (Linux Devices) by simlo Parent article: ARM SoC launched with Linux support (Linux Devices)
It is actually a pretty good idea if you combine it with kernel controlled code in the VDSO. Clearly operating on arbitrary user code is not a good idea..
Basically, the kernel has useful atomic_* function calls exported in its VDSO, if ever there is a preemption then during the context switch back to the suspended task the kernel checks if the PC is within the bad portion of the VDSO (two compares) and if so then it inspects the situation in more detail and adjusts the PC to return to the start of the atomic op function and tries again.
Similar precautions can be taken for signals and other cases. The basic structure of the atomic functions in the VDSO would be of the load locked/store conditional type with the kernel providing a loop back to start if the 'reservation' is lost.
User space simply links to these calls like normal VDSO linking. The VDSO is readonly to user space and has a unique physical and virtual address.
If generalized properly it could be efficiency neutral for userspace by being optimized to a specific CPU model. Certainly on ARM it has got to be a win if you need to support all CPU types. PPC and others with ll/sc it might be neutral, if the vdso functions are thick enough to replace what would have been a function call anyhow. Probably not useful on x86..
(Log in to post comments)
|
|
||||||||||||