OSDev

Кто хочет получить права на изменения в коде проекта (SVN), присылайте заявки на akobets$mail.ru
Главная страница
База SVN

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

Да, жалко что 64-битном режиме сегменты убрали (оставили только сегменты FS и GS, но в них только база). Тогда идея бесперспективна, ОС переделывать уже не буду :-)

Придумал, как передавать данные в формате XML без потери эффективности из-за текстового представления.
Решение напрашивается само собой - преобразовать (по сути скомпилировать) данные в бинарный вид, оставив в текстовом виде только схему (тоесть из оригинального вида все данные удаляются). При этом передача состоит из двух блоков - заголовок и содержание. Принимающий может проводить декомпиляцию до оригинального вида без искажений.
Процесс передачи на примере:
Оригинал (текст):
<VideoData>01,02,03,04,05<VideoData>
<AudioData>06,07,08,09,00<AudioData>

Скомпилированный заголовок (текст):
<VideoData>[5]<VideoData>
<AudioData>[5]<AudioData>

Теперь [5] означает размер байт в бинарном блоке.

Бинарный блок (10 байт):
01,02,03,04,05,06,07,08,09,00

Получающая сторона может использовать бинарные данные по прямому назначению. Тоесть декомпиляция в символьное представление может и не понадобиться, и получается экономия времени на интерпретацию данных.

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

Не знаю правильно-ли, но скомпилировать удалось.
Не удается создать образ CD. Может я ни тем mkisofs.exe пользуюсь?

mak4444, на диске C: должен иметься установленный Grub. Если его нет, то скопируй с загрузочного Express диска всю папку boot на C:\.

Касательно файловой системы. Я пришёл к выводу, что даже обычная ФС полностью отвечает требованиям объектности. Не важно, что файлы - это просто набор байтов. В компьютере всё набор байтов.
Важно только выполнение одного условия касательно типизации, которое в обычных ОС не выполняется. Должна быть не просто декларативная типизация на уровне ни к чему не обязывающего слова в конце имени файла, а должна быть реальная строгая типизация, классическия строгая типизация, как в языках программирования. Что означает, что с файлом можно работать не как с набором байт, а только как с объектом определённого типа и ни как иначе, посредством определённого объектного компонента и интерфейса.
Введение строгой типизации имеет значение и с точки зрения уровня безопасности. Собственно говоря, типизация в файловой системе имеет точно такое же значение, точно такой же эффект, как и появление строгой типизации в языках программирования, позволяющая вести более глубокий и качественный контроль за манипуляцией и взаимодействием объектов, так как это дополнительный аспект правил. Это дополнение к правилам области видимости, которые имеются в существующих ФС. К примеру, с помощью настроек типизации можно сделать так, что файлы типа cpp могли изменяться лишь определённой программой, к примеру EditCpp, компилятор CompileCpp имел права только на чтение этих файлов, а всем остальным программам вообще недоступен. Также можно сделать и для типов exe, что создаваться и изменяться они могут только определённым компилятором и системной утилитой инсталяции. А вот уж чтобы к примеру какой-нибудь вирус не мог создать exe из своего cpp путём использования компилятора, тут помогут обычные права области видимости - компилятору должны быть доступны файлы cpp лишь из определённых директорий, где находятся пользовательские проекты.

Тогда, по сути, расширения в привычном смысле вообще становятся не нужны. Тип можно хранить внутри ФС, программы будут видеть только "свои" файлы.
А вот как быть с копированием? Ведь CopyFile должна иметь доступ на чтение/запись любого файла...

Всё-таки удобнее хранить тип файла в имени.
Процедура CopyFile должна предоставляться виртуальной файловой системой (VFS), или просто системой, в зависимости от архитектуры ОС.
Программа может и просто скопировать объект на объектном уровне: создать новый объект такого же типа, передать ему содержание объекта-источника, и записать его как файл-приёмник.

>Всё-таки удобнее хранить тип файла в имени.
разница лишь в том увидит пользователь расширение или нет. для системы разницы нет - имя файла лежит в ФС.

>А вот уж чтобы к примеру какой-нибудь вирус не мог создать exe из своего
>cpp путём использования компилятора...

>Процедура CopyFile должна предоставляться виртуальной файловой системой
>(VFS), или просто системой, в зависимости от архитектуры ОС.

тогда наш любимый вирус находит каталог пользовательского проекта, копирует свои исходники в него (ведь CopyFile - доступная системная процедура) и спокойненько запускает CompileCpp.

На уровене лишь ФС реализовать защиту от вирусов, имхо, невозможно...

p.s. А тема то была об объектности ФС... Извиняюсь за оффтоп :)