За последние 60 дней ни разу не выходила
Сайт листа:
http://www.linuxrsp.ru
Открыт:
25-07-2003
Пре-модерация: Нет
Адрес для писем в лист: comp.soft.linux.discuss-list@subscribe.ru
Адрес
модератора: comp.soft.linux.discuss-owner@subscribe.ru
On Wed, 22 Oct 2003, Alexander S. Yurkov wrote:
Впрочем, можно передать адрес заголовка a обработчик системного вызова это
проверит по адресу возврата, вытащенного из стека. Но как конкретно
реализовано в Linux?
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru
Приветствую.
On Wed, 22 Oct 2003, Vasile wrote:
По видимому MMU это часть кода ядра?
*nix тем хорош, что он в значительной мере аппаратнонезависимый. Не
полностью, конечно. Хочется ясно представлять себе что есть аппаратно
независимая а что - зависимая часть системы. В конце-концов IMHO можно
считать, что unix работает на неком виртуальном (логическом) процессоре
и вот архитектуру этого виртуального процессора хотелось бы понимать.
Тогда вся аппаратнозависимая часть это реализация виртуального процессора.
Для i386 существуют понятия
Это аппаратура или нечто програмное? По логике вешей должно быть
нечто програмное. Физических регистров, с помощью которых происходит
отображение виртуальных адресов в физиченские как правило немного
и нельзя каждому процессу выделить по своему набору регистров.
Просто не хватит регистров.
Процесс работает с виртуальными адресами (не имея понятия о
ОК. Своего рода заголовок процесса. Что-то такое есть всегда в любой ОС.
Несколько неожиданно. Очевидно тут идет речь о виртуальном адресном
пространстве. Не перемещать же при каждом системном вызове
код ядра! :-)
Но тогда надо сначала настроить отображение виртуальных адресов в
физические. Для данного процесса. При каждом системном вызове.
Вообще при каждом прерывании. Видимо это и делает MMU?
При напосредственном исполнении команды системного вызова (INT в
интел х86) мы не сможем сразу попасть в виртуальное адресное
пространство нужной структуры. Видимо сначала мы попадем в
MMU?
Судя по всему это означает, что есть несколько окон отображения
виртуальных адресов на физические и когда исполняется код пользователя
часть окон, соответствующая U-zone, коду ядра и т. п. "отображена в
никуда". При выполнении системного вызова происходит замена режима
процессора на ядро (ну это сразу, при загрузки PSW из вектора прерывания)
и включается отображение этих окон на реальные адреса (а это, видимо
делает MMU?). Так?
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru
Здравствуйте, Alexander.
Вы писали 23 Октябрь 2003 г., 13:54:47:
Нет, это функциональный блок CPU (хотя возможна и иная апаратная
реализация). Имеет свой набор регистров, доступных в
привилегированом режиме с помощью набора комманд процессора.
В моём понимании, Unix абстрагируется от конкретной апаратной
архитектуры, и даёт пользователю/разработчику унифицированый
интерфейс (насколько можно общий) для большинства архитектур.
Аппаратура. GDT/LDT это часть регистров MMU, в общем представляют
собой лишь ссылку на область памяти содержащие эти таблицы
отображения. (Вывод: чем больше системной памяти, тем больше размер
этих таблиц.) При адресации формируется виртуальный адрес, он
передаётся MMU который самостоятельно ищет по этим таблицам
соотвествующий физический адрес (опять же в оперативной памяти).
Теперь становится ясно какую нагрузку на RAM даёт эта защита, и почему
так важны в современных системах скоростные кэш-буферы.
Совершенно верно.
Да. Правда саму начальную настройку отображения делает ядро. И при
переключении на другой процесс, просто загружается другой адрес в LDT,
а за остальное отвечает уже процессор (MMU).
Да. (AFAIK)
On Wed, 22 Oct 2003, Vasile wrote:
Хм-м-м-м... А вообще идея красивая. Не знаю так ли реализовано в юниксе,
но можно сделать следующем образом. Естественно, обработчик прерывания
начинает работать при иной настройке отображения виртуальных адресов в
физические, нежели процесс пользователя (другой набор бит, определяющих
регистры управления памятью в PSW). Но он может сделать следующее.
Достать из стека PSW пользователя. Модифицировать в нем биты режима
процессора (разрешить режим ядра) и эмулировать самого себя но уже с
измененным вектором прерывания (подставив PSW пользователя с
модифицированными битами режима процессора). После этого процессор попадет
опять в адресное пространство пользователя (так как в PSW теперь указаны
пользовательские регистры управления памятью) но уже в режиме ядра! И
никаких проблем с определением какой процесс вызвал прерывание. Красиво.
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru
Здравствуйте, Alexander.
Вы писали 23 Октябрь 2003 г., 0:57:27:
Зачем всё усложнять: первое преимущество Unix'a - его простота (второе
- файловая система).
На самом деле вспомним что кроме режимов привилегий процессоров
(кстати верно подметили: из 4-х уровней для i386+ в Linux используются
всего лишь 2 крайних), для эфективного управления многозадачностью
используется также MMU (memory management unit)
(немного некоректно сформулировал идею, так как управление
уровнями привелегий является частью функций MMU). Я не очень хорошо
знаком с разными архитектурами систем (в частности более близкое
знакомство имел с i80x86 и Etrax100LX). Для i386 существуют понятия
GDT (Global Descriptor Table) и LDT (соотвественно Local). Они
обозначают таблицы с данными для управления областями памяти.
Существует одна GDT на всю систему, и по одной LDT для каждого
процесса. Процесс работает с виртуальными адресами (не имея понятия о
физическом распределении памяти), для правильного их отображения в
физическое адресное пространство используется LDT.
Так вот, вернёмся к Unix. Для каждого процесса выделяется зона памяти
(U-zone) содержащая набор информации о процессе. В частности там
находится время исполнения программы, приоритет, значение nice,
список открытых файлов, корень, рабочий каталог, значение umask и все
ID (uid, gid, euid, egid), ...
При системном вызове начинает исполнятся код ядра, но при этом он
выполняется в адресном пространстве пользовательского процесса (!).
Он сразу обращается к U-zone, берёт оттуда pid (process id) и если
нужная информация не находится в U-zone (например адрес буфера
открытого файла), он её ищет в соотвествующей глобальной области
данных используя идентификатор процесса (pid)
Замечание: сам процесс не имеет непосредственного доступа к
вышеописаной информации и должен использовать функции
ядра.