I was also under the vague impression (I could be wrong about this) that pacbell's Terms of Service for their adsl lines involved not running servers...Is LinuxOne busted? (That'd be pretty funny, after the hassle they gave the reporter about his Yahoo account Terms of Service...)
It's OK to run servers if you pay for one of the static IP options (like I do).
No, "preemption points" is precisely not what this is. The kernel is preemptible by default, except during protected critical regions. A "preemption points" kernel is non-preemptible by default, and preemption can only happen at the preemption points.
So - if MontaVista's kernel is fully preemptive it should be interruptible at any time. This means that there are no times when you can't serve an interrupt, or am I wrong?
It's not interruptible when interrupts are disabled. So interrupts are disabled to protect critical regions in this type of kernel.
"Fully preemptible" means always preemptible by default, except when it isn't. The alternative is non-preemptible by default, except at certain well-defined preemption points. There have been some kernel patches proposed that add more preemption points, but I believe that a fully preemptible kernel is cleaner, more maintainable and higher-performance, when it's done correctly. SGI's IRIX works this way, for example.
The problem, though, is that the approach taken doesn't work on multi-CPU systems. The overhead of synchronization between CPUs is prohibitive when doing preemption in the manner that MontaVista describes.
The current version uses a no-preempt flag (actually a counter) to protect critical regions against kernel preemption. However, the ultimate goal is protect critical regions only be disabling interrupts on the local CPU. This works fine on SMP systems. As an example, SGI's IRIX works this way, and not only scales to large numbers of CPUs, but can also make real-time guarantees that are good enough for mission-critical audio and video applications.
Slashdot Mirror
I was also under the vague impression (I could be wrong about this) that pacbell's Terms of Service for their adsl lines involved not running servers...Is LinuxOne busted? (That'd be pretty funny, after the hassle they gave the reporter about his Yahoo account Terms of Service...)
It's OK to run servers if you pay for one of the static IP options (like I do).
The bit about not support multiprocessors is unfortunate.
Support for kernel preemption in an SMP kernel will be added in a future version of the patch.
No, "preemption points" is precisely not what this is. The kernel is preemptible by default, except during protected critical regions. A "preemption points" kernel is non-preemptible by default, and preemption can only happen at the preemption points.
So - if MontaVista's kernel is fully preemptive it should be interruptible at any time. This means that there are no times when you can't serve an interrupt, or am I wrong?
It's not interruptible when interrupts are disabled. So interrupts are disabled to protect critical regions in this type of kernel.
"Fully preemptible" means always preemptible by default, except when it isn't. The alternative is non-preemptible by default, except at certain well-defined preemption points. There have been some kernel patches proposed that add more preemption points, but I believe that a fully preemptible kernel is cleaner, more maintainable and higher-performance, when it's done correctly. SGI's IRIX works this way, for example.
The problem, though, is that the approach taken doesn't work on multi-CPU systems. The overhead of synchronization between CPUs is prohibitive when doing preemption in the manner that MontaVista describes.
The current version uses a no-preempt flag (actually a counter) to protect critical regions against kernel preemption. However, the ultimate goal is protect critical regions only be disabling interrupts on the local CPU. This works fine on SMP systems. As an example, SGI's IRIX works this way, and not only scales to large numbers of CPUs, but can also make real-time guarantees that are good enough for mission-critical audio and video applications.