стек ядра и стек пользовательского пространства

1. в чем разница между стеком ядра и стеком пользователя ?

короче говоря, ничего-кроме использования другого местоположения в памяти (и, следовательно, другого значения для регистра stackpointer), и обычно разные защиты доступа к памяти. Т. е. при выполнении в пользовательском режиме память ядра (частью которой является стек ядра) будет недоступна, даже если она сопоставлена. Наоборот, без явного запроса со стороны код ядра (в Linux, через такие функции, как copy_from_user()), память пользователя (включая пользовательский стек) обычно не доступна напрямую.

1. почему используется [отдельный ] стек ядра ?

Разделение привилегий и безопасности. Во-первых, программы userspace могут делать свой стек(указатель) все, что они хотят, и обычно нет архитектурного требования даже иметь действительный. Поэтому ядро не может доверие userspace stackpointer должен быть действительным и не использоваться, и поэтому потребуется один набор под собственным контролем. Различные архитектуры ЦП реализуют это по-разному; процессоры x86 автоматически переключают stackpointers при переключении режима привилегий, а значения, используемые для разных уровней привилегий, настраиваются - привилегированным кодом (т. е. только ядром).

1. если локальная переменная объявлена в ISR, где она будет хранится ?

в стеке ядра. Ядра (ядро Linux, то есть) делает не hook ISRs непосредственно к архитектуре x86 прерывание ворота но вместо этого делегирует отправку прерывания общему механизму входа/выхода прерывания ядра, который сохраняет состояние регистра перед вызовом зарегистрированных обработчиков. Сам процессор при отправке прерывания может выполнить привилегию и / или переключатель стека, и это используется / настраивается ядром так, чтобы общий код записи прерывания уже мог полагаться на присутствующий стек ядра.
Тем не менее, прерывания, возникающие при выполнении кода ядра, будут просто (продолжать) использовать стек ядра на месте в этот момент. Это может, если обработчики прерываний имеют глубоко вложенные пути вызова, привести к переполнению стека (если глубокий путь вызова ядра прерывается, и обработчик вызывает другой глубокий путь; в Linux файловая система / программный RAID-код прерывается известно, что сетевой код с активными iptables запускает такие в не настроенных старых ядрах ... решение заключается в увеличении размеров стека ядра для таких рабочих нагрузок).

1. каждый процесс имеет свой собственный стек ядра ?

не только каждый процесс-каждый нить имеет свой собственный стек ядра (и, по сути, свой собственный стек пользователя). Помните, что единственное различие между процессами и потоками (для Linux) - это факт что несколько потоков могут совместно использовать адресное пространство (создание процесса).

1. как процесс координируется между обоими этими стеками ?

вовсе нет - в этом нет необходимости. Планирование (как / когда выполняются разные потоки, как сохраняется и восстанавливается их состояние) - это задача операционной системы, и процессам не нужно беспокоиться об этом. По мере создания потоков (и каждый процесс должен иметь хотя бы один поток), ядро создает для них стеки ядра, в то время как стеки пользовательского пространства либо явно создаются/предоставляются любым механизмом, используемым для создания потока (такие функции, как makecontext() или pthread_create() разрешить вызывающему указать область памяти, которая будет использоваться для стека "дочернего" потока) или унаследована (путем клонирования памяти при доступе, обычно называемого "копировать при записи" / COW, при создании нового процесса).
Тем не менее, процесс can планирование влияния своих потоков и / или влиять на контекст (состояние, среди которых есть stackpointer потока). Для этого существует несколько способов: Unix signals,setcontext(), pthread_yield() / pthread_cancel(), ... - но это disgressing немного от изначального вопроса.