Как ОС обычно идет об управлении обработке страницы и памятью ядра?

Правильный подход заключается в том, чтобы использовать этот ViewHelper только в контексте USER_INT или на страницах, где кэш полностью отключен (хотя это не рекомендуется).

Только когда визуализируемый вами шаблон не может быть кэширован TYPO3, ViewHelper будет выполняться каждый раз и давать правильный результат.

6
задан Erick Robertson 4 January 2012 в 13:19
поделиться

2 ответа

Хорошая начальная точка для всех этих вопросов должна посмотреть на то, как Unix делает это. Как известная кавычка говорит, "Те, кто не понимает UNIX, обречены переосмыслить его, плохо".

Во-первых, о вызывании функций ядра. Недостаточно просто иметь функции где-нибудь, программа может звонить, так как программа по всей вероятности работает в "непривилегированном режиме" (звоните 3 на IA-32), и ядро должно работать в "привилегированном режиме" (обычно звонят 0 на IA-32) сделать его priviledged операции. Необходимо так или иначе сделать переход между обоими режимами, и это является очень архитектурно-зависимым.

На IA-32 традиционный путь состоит в том, чтобы использовать логический элемент в IDT вместе с программным прерыванием (Linux использует интервал 0x80). Более новые процессоры имеют другие (более быстрые) способы сделать это, и которые доступны, зависит от того, является ли ЦП от AMD или Intel, и на определенной модели CPU. Для размещения этого изменения недавние ядра Linux используют страницу кода, отображенного ядром во главе адресного пространства для каждого процесса. Так, на недавнем Linux чтобы сделать системный вызов Вы вызываете функцию на этой странице, которая в свою очередь сделает то, что необходимо для переключения на привилегированный режим (ядро имеет больше чем одну копию той страницы и choses, которые копируют для использования на начальной загрузке в зависимости от функций процессора).

Теперь, управление памятью. Это - огромный предмет; Вы могли записать большую книгу об этом и не exaust предмет.

Обязательно имейте в виду, что существует по крайней мере два представления памяти: физическое представление (реальный порядок страниц, видимых к аппаратной подсистеме памяти и часто к внешним периферийным устройствам) и логическое представление (порядок страниц, замеченных программами, работающими на ЦП). Довольно легко смутить обоих. Вы будете выделять физические страницы и присваивать их логическим адресам на адресном пространстве ядра или программе. Единственная физическая страница может иметь несколько логических адресов и может быть отображена на различных логических адресах в различных процессах.

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

Программы выделяют память на остальной части адресного пространства несколькими способами:

  • Часть памяти выделяется загрузчиком программы ядра. Это включает код программы (или "текст"), инициализируемые данные программы ("данные"), программа деинициализировала данные ("bss", заполненный нулями), стек и несколько ненужных деталей. Сколько выделить, где, что должно быть начальным содержанием, какие флаги защиты использовать, и несколько других вещей, читаются из заголовков на исполняемом файле, который будет загружен.
  • Традиционно на Unix, существует область памяти, которая может вырасти и уменьшиться (ее верхний предел может быть изменен через brk() системный вызов). Это традиционно используется "кучей" (средство выделения памяти на библиотеке C, который malloc() один из интерфейсов, ответственно за "кучу").
  • Часто можно просить, чтобы ядро отобразило файл на область адресного пространства. Чтения и записи к той области (через волшебство подкачки страниц) направлены к отступающему файлу. Это обычно называют mmap(). С анонимным mmap, можно выделить новые области адресного пространства, которые не поддерживаются никаким файлом, но иначе действуют одинаково. Загрузчик программы ядра будет часто использовать mmap выделить части кода программы (например, код программы может быть поддержан самим исполняемым файлом).

Области Acessing адресного пространства, которые не выделяются всегда (или резервируются для ядра) считают ошибкой, и на Unix заставит сигнал быть отправленным в программу.

Компилятор любой выделяет память статически (путем определения его на заголовках исполняемого файла; загрузчик программы ядра выделит память, при загрузке программы) или динамично (путем вызывания функции на стандартной библиотеке языка, которая обычно затем вызывает функцию в библиотеке стандарта языка C, которая затем называет ядро для выделения памяти и подразделяет его при необходимости).

Лучший способ изучить основы всего этого состоит в том, чтобы прочитать одну из нескольких книг по операционным системам, в особенности те, которые используют вариант Unix в качестве примера. Это войдет в путь больше детали, чем я мог на ответе на StackOverflow.

12
ответ дан 8 December 2019 в 13:03
поделиться

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

В x86 существует два способа реализовать системные вызовы: с прерываниями, и с sysenter/sysexit инструкциями. С прерываниями ядро настраивает таблицу дескрипторов прерываний (IDT), которая определяет возможные точки входа в ядро. Пользовательский код может затем использовать int инструкция генерировать мягкое прерывание для вызова в ядро. Прерывания могут также быть сгенерированы аппаратными средствами (так называемые трудные прерывания); те прерывания должны обычно быть отличны от мягких прерываний, но они не должны быть.

sysenter и sysexit инструкции являются более быстрым способом выполнить системные вызовы, начиная с обработки прерываний является медленным; я не настолько знаком с использованием их, таким образом, я не могу прокомментировать, являются ли они лучшим выбором для Вашей ситуации.

Какой бы ни Вы используете, необходимо будет определить интерфейс системного вызова. Вы, вероятно, захотите передать аргументы системного вызова в регистрах а не на стеке, начиная с генерации прерывания вызовет Вас к стекам коммутаторов к стопке ядра. Это означает, что необходимо будет почти наверняка записать некоторые тупики ассемблера и на конце непривилегированного режима для создания системного вызова, и на снова на конце ядра, чтобы собрать аргументы системного вызова и сохранить регистры.

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

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

6
ответ дан 8 December 2019 в 13:03
поделиться