в одном и том же контексте,

мне нравится идея что ядро не имеет своего а.п. Вместо этого, оно помещает себя численно в один и тот же диапазон всех а.п. Эта картина намного яснее и не порождает путаницы подобной вопросу темы. Любой поток пользовательского процесса может уйти в ядро. Не переключаются же при этом а.п? Нет! А прерывания, ими драйверы как раз и занимаются. Кто же в обработчике апаратного прерывания будет переключать контекст на другой процесс? Хотя может в линуксе так делают. У них же и планировщик - отдельный процесс. В Виндовсе, планировщик это отложенный вызов процедуры (dpc), помещаемый в очередь процедурой обработки прерывания (isr) таймера, и по сути все они работают в а.п. процесса, поток к-го прервали, как и все остальные isr'ы и dpc.
А.п. - это атрибут процесса и в каждом таком а.п. есть область для ядра и доступная только ему, в том числе и простым юзерским потокам, когда они переходят в режим ядра. Система может создать какой-то процесс вроде system, напр. чтобы в него помещать созданные в том числе и драйверами потоки работающие только в диапазоне ядра, но всеравно у этого процесса будет свое а.п. с адресами от 0 до FFFFFFFF в 32-битной системе, т.е. и с юзерспейсной областью.
Так что по идее и драйверы в тч, должны работать в а.п. любого пользовательского процесса. Какого, зависит от того, что за событие привело к коду драйвера. Но как в линуксе, я не знаю. :D

в одном и том же контекстеА что нужно, чтобы "перейти в режим ядра", перейти в ring0, и это будет значить, что мы можем писать/читать по адресам 0-1GB (в x86_32)?

с помощью системных вызовов. А те, используют или спец команды, или генерируют прерывание для этого рассчитанное. Типа int 80h. В режиме ядра доступно всё а.п.
Т.е. если процесс system начнет выделять память через kmalloc/vmalloc, то оно будет выделятся в некоторой юзерспейсной области, а не в kernel-space: 0-1GB (в x86_32)?

дело не в каком процессе это происходит, а при каком уровне привелегий. Для этого в системе есть соотв. апи, с помощью одного процесс выделяет себе пользовательскую память находясь в реж.польз., с помощью другого - в ядре. Тоесть чтобы выделить в ядре, нужно быть в режиме ядра и вызывать нужные ф-ции. И наоборот. Хотя в конечном счете все выделения заканчиваются в реж.ядра.
А если это событие - аппаратное прерывание, то в а.п. какого процесса будет это прерывание, ведь оно не вызвано никаким процессом?

я уже писал, как раз для прерываний это видно очень хорошо, - это очень нерационально, в обработчике апп. прерывания переключаться на какой-то другой процесс. Прерывания - сами по себе, они отдельные единицы работы процессора, но когда они выполняются, они "видят" а.п. процесса, работу к-го прервали. Поскольку это не проблема. Они работают в обл.ядра, а если обработка прерывания подразумевает попадание данных в а.п. другого процесса, это не проблема - они будут скопированы, отображены в нужный момент в цепочке доставки данных конечному пользователю.

AndreTMА нахрена? Нахрена приложению знать тонкости контекста ?
Кто-нибудь может мне пояснить вероятность такого события (некошерные проги отбрасываем)?
а оно и не знает, переключениями между а.п. занимается диспетчер ОС. Напр. во время работы какого-то потока какого-то процесса какой-то польз.программы возникает прерывание от таймера, управление уходит на обработчик этого прерывания, а.п. остается того же процесса, но работа уже идет в режиме ядра; обработчик уменьшает счетчик для текущего потока, видит, что хватит ему выполняться, ставит в очередь dpc планировщика и, на выходе, понижает IRQL, когда доходит до IRQL=DISPATCH_LEVEL, выполняются dpc, в т.ч. - dpc планировщика, тот выбирает новый поток из списка очередей, и если тот из другого процесса чем текущий, - переключает контекст, изменяется указатель на каталог таблиц страниц, сливается tlb и тд, вот уже и другое а.п. Это делается ОС, прозрачно для програмы, в рамках многоуровневой обработки прерывания, но, как видно, для этого не нужно какого-то третьего процесса со своим а.п. Также и драйверы обрабатывают свои прерывания на своих DIRQL'ях. Но это на виндовс.

AndreTMvalkotвозникает прерывание от таймера, управление уходит на обработчикАга... Вот именно в этот момент - приложение уже не контролирует обработку. Мимо...
ну естесственно, такова природа прерываний, даже если его обработка была бы возложена на приложение, его возникновение - независимый вобщем процесс. это не вызов ф-ции. Это еще один независимый механизм, о котором впрочем приложениям ничего неизвестно.