Are there any difference between "kernel preemption" and "interrupt"?

Question

I just reading an article which says:

Reasons to control the interrupt system generally boil down to needing to provide synchronization. By disabling interrupts, you can guarantee that an interrupt handler will not preempt your current code. Moreover, disabling interrupts also disables kernel preemption. Neither disabling interrupt delivery nor disabling kernel preemption provides any protection from concurrent access from another processor,however.

So I just wonder the difference between interrupt and kernel preemption.

Or could we say disabling kernel preemption also disables interrupts?

Answer 1

When a process is interrupted, the kernel runs some code, which may not be related to what the process does.
When this is done, two things can happen:
1. The same process will get the CPU again.
2. A different process will get the CPU. The current process was preempted.

So preemption will only happen after an interrupt, but an interrupt doesn't always cause preemption.

Answer 2

They're different. Interrupts may occur outside even the context of the kernel, so changing the way the kernel handles preemption won't affect interrupts. It just appears that in the context of your article, kernel preemption depends on interrupts working (probably because it's implemented using a timer of some sort).