Использование стека под буфер ...

Выделять и освобождать память нужно будет очень часто - поэтому здесь уже критичны затраты на выделение/освобождение памяти.

При возникновении исключения мне уже не нужен будет мой буфер в стеке.

Вот здесь пожалуйста поподробнее ... Вот у меня выполняется код в RING0, в стеке лежит буфер. Сам я не передаю управление пользовательскому процессу, т.к. я уже говорил что в коде не используется ни CALL ни API (т.е. управление может передать ядро кому-либо при возникновении аппаратного прерывания или еще как-то - я не особо силен в ядре поэтому могу неточно выражаться) поэтому я и хочу узнать может ли ядро (А НЕ МОЙ КОД !!!) использовать стек поего процесса если он находится в RING0.



2 Ms Rem:

Под входом в обработчик прерывания ты как раз и имел ввиду то, что я написал чуть выше ("управление может передать ядро кому-либо при возникновении аппаратного прерывания или еще как-то")?



P.S. По сути буфер - это область памяти для хранения локальных переменных некоего "эмулятора" процессора, для которого очень важно оригинальное состояние ESP, в тоже время нет возможности постоянно дергать выделение/особождение памяти при работе эмулятора на простом участке кода (как я уже говорил участок кода не содержит никаких вещей, которые могут портить буфер). На этапе "старта" эмулятора мне неизвестно сколько будет одновременно ниток крутится в эмулируемой процедуре, поэтому я не могу заранее выделить нужный по размеру буфер. Поэтому и возникла идея использовать под буфер стек (затирание стека при эмуляции кода будет контролировать сам эмулятор и двигать буфер дальше по стеку в случае "наезда" на него вершины стека). Остался последний вопрос - возможное затирание стека кем-то другим.

 

dermatolog

Я имел в виду, что ситуация в ринг3 и ринг0 координально различается. Стек ринг3 потока никто кроме него использовать никогда не будет, но в контексте ринг0 потока может исполняться другой код. Нпример при приходе прерывания происходит сохранение адреса возврата в стеке и переход в обработчик ISR. При этом используется ядерный стек потока, и в отличии от работы в юзермоде, никакого переключения на другой стек не происходит. Еще ядерный поток будет прерываться вызовами DPC и APC, которые тоже будут использовать его стек. Короче в ядре такой метод выделения памяти заведомо обречен на глюки.

 

2 Ms Rem:

Спасиба за разъяснения. В принципе мне было достаточно самого верхнего сообщения на этой странице, но народ захотел продолжения )

 

dermatolog

Вот это нужно было сказать сразу, а не в конце, или тренируешь местных телепатов?

 

)



Всем спасибо вопрос закрыт.