: . Главная . : . Форум . : . Загрузка . : . Пользователи . : . ЧаВо . : . Документация . :


Операционная система 3OS -> Форумы -> Идеология проекта
<< Предыдущая тема | Следующая тема >>   

Критики немного

Перейти к странице Предыдущая -1-2-3
Автор Отправлено
Davy
Monday 15.03.2004 11:50 Цитата
Зарегистрирован: Friday 05.03.2004 18:34
Сообщений - 4
Freeman писал(а): ...
если 3ОС будет работать на FAT, ни о каких правах доступа и речи не идет. На Ext2 - пожалуйста, но это будут абсолютно те же самые права, что и в Linux.

Сорри. Просто по ходу обсуждения я подумал о создании новой ФС.
Freeman писал(а): ...
Кстати, на данный момент вопросы безопасности в 3ОС вообще не проработаны. Можете чем-то помочь конкретным?

Спасение утопающих - дело рук самих утопающих...
Наверх
HandleX
Monday 15.03.2004 18:51 Цитата
Зарегистрирован: Friday 13.02.2004 12:39
Сообщений - 18
Давайте по порядку, тем более что это <b>очень серьёзный</b> вопрос:
Davy: «Но если плагины (кодеки) будут "висеть" на уровне пользователя, просто дополняя ФС, то это уже не будет прерогативой ФС, а просто надстройкой для поддержания уровня абстракции. Такую же хрень я могу устроить и поверх FAT. Но это будет, опять-таки, не фичей ФС, а, скорее, фичей ОС»
«А ведь я предлагаю обсудить не верхние слои реализации ФС, а те, которые будут ближе к физике устройств. В каком виде хранить данные? Что решить с правами доступа и вообще с общими атрибутами объектов?»
Вот, возьмём, к примеру, NTFS. Microsoft круто начала, введя файлопотоки, от них до объектной реализации пол-шага. Что не хватает до реальной объектной файловой системы? На нижнем уровне в NTFS всё чудесно, атрибуты могут иметь любую длину, там что FileName, что SecurityDescriptor, что FileAttributes суть некий «приватный файлопоток». А дальше доступ к этим файлопотокам (читай, к полям объекта) ограничивается через системные вызовы. Т.е. бизнес-логика «вморожена» в ядро. Я не знаю, как это охарактеризовать. Это, с одной стороны хорошо в плане стабильности, но очень плохо в плане дальнеших наворотов в сторону ОО.
«GetFileSecuritySetFileSecurity»… Ну-ну… Вы монтировали NTFS в DOS, к примеру? Что там происходит в плане секурности? А летит она ко всем чертям, ты становишься «самым главным Администратором», и читай-не хочу всё то, на что был повешен самый злобный DACL . Т.е. нельзя рассматривать бизнес-логику отдельно от OS, для которой она придумана. Кстати, проверка доступа в самой NT делается только для пользовательских вызовов, в режиме ядра проверка доступа не делается. Да и не нужна там она

Ладно, теперь дальше к нашим баранам. Мне трудно представить «идеальный» объектный подход, когда методы и поля объектов «заморожены» компилятором, как имеет место быть в «классическом» ООП.
Итак, что бы я хотел (рассматриваем работу Storage Subsystem в супер-пупер-продвинутой OO OS):
Начнём с драйвера IDE (он мне ближе ), который, если абстрагироваться, даёт нам интерфейс для оперирования неким объектом класса «шина IDE». Это объект, у которого есть поля типа IDE.ChannelCount, ещё что-нибудь, связанное с шиной, методы вроде IDE.Channel[0].SendATACommand(). Натравливаем на это дело другой драйвер, PhysIDEDevice, потомок BlockDevice, при создании которого в качестве параметра передаётся интерфейс на IDE.Channel[0]. Если на канале есть диски, то объект остаётся загруженным в память ядра, а у интерфейса IDE.Channel[0] появляются новые поля и методы, связанные с PhysIDEBlockDevice! Поехали — IDE.Channel[0].Device[Master].BlockSize, IDE.Channel[0].Device[Master].BlockCount, методы IDE.Channel[0].Device[Master].ReadBlock(), IDE.Channel[0]Device[Master].WriteBlock(). А что будет, если на Slave устройство не подключено, а мы попробуем обратится к его методам? Получим исключительную ситуацию. А для проверки можно попробовать получить интерфейс вот так: CBlockDevice(IDE.Channel[0].Device[Slave]), если получим непустой интерфейс, то значит существует диск на шлейфе.
Хех, дальше — больше. Мы начинаем видеть, как забурлило и заветвилось наше интерфейсное дерево. Будем «проращивать» его дальше? Пожалуйста! Ведь в нашем арсенале есть СBlockDevicePartitionParser, который, будучи создаваем, получает указатель на IDE.Channel[0].Device[Master], он обогатит наш интерфейс полем PartitionCount, методами для изменения разделов, и интерфейсами СBlockDevice(IDE.Channel[0].Device[Master].Partition[N]). Инересно, что к диску уже можно обращаться как CBlockDevice(Физ.Диск), так и CBlockDevice(НужныйРаздел). Ну а дальше… А дальше создаётся великий и могучий CCaсhedBlockDevice, который вкупе c Intel’овской виртуальной адресацией начинает творить чудеса. Он перегружает интерфейс CBlockDevice(НужныйРаздел) таким образом, что обращение к CBlockDevice(НужныйРаздел) будет кэшированным. Плюс добавляет свойство НужныйРаздел.MemoryMapped, 64-битный указатель (хотя валидны только 48 бит) на отображение этого диска в виртуальной памяти цомпутера. Ну а дальше… Драйвер файловой системы получает MemoryMapped или CBlockDevice, я не знаю, что будет «вкуснее» будущим разрабочикам. По производительности, если девайс будет кэшированным, то хоть так, хоть эдак . Через MemoryMapped даже быстрее будет… Если это «вражеская» файловая система типа FAT, то получите интерфейс на СFATRootDirectory с каталогами и файлами и DOS’овскими атрибутами и всеми делами Если это NTFS, то CNTFSRootDirectory со всеми примочками и секурити. Если модель защиты 3OS сможет безболезненно транслироваться в NTFS секурити (я думаю это не будет слишком сложно), то пользовательские интерфейсы можно защищать через NTFS.
Ну вот, пожалуй и всё. Ядро хранит в себе и управляет всем этим великим и могучим интерфейсным деревом. Само по себе дерево это двусвязный список, с указателеми на родителя. Блочное. Указатели сегментные. Объекты, транслирующие в дерево методы, могут находится в разных сегментах с различными привелегиями. Привилегии рулятся Intel’овской защитой памяти. Те кто не может, не смогут Те кто могут, смогут Общие методы для интерфейсов нужно тщательно проработать, т.е. хождение по дереву, перечисление элементов, типы, отображение интерфейсов в процессы и проч.

Интерфейсы транслировать в пользовательский режим с необходимой защитойусечением.

Ух, всё, пальцы устали Предвижу завтра грандиозный флейм… .
Если в 3OS будет всё так, то… мы победим. Позже, если будет время, пространно поразмышляю о том, какая должна быть Native 3OS Object File System
Наверх
Davy
Wednesday 17.03.2004 15:33 Цитата
Зарегистрирован: Friday 05.03.2004 18:34
Сообщений - 4
HandleX писал(а): ...
IDE.ChannelCount

Очень вкусно.
Я бы даже предложил объединить в общий корень родителя "Устройства". Т.е.:
Dev.IDE.ChannelCount
или даже
Host("local").Dev.IDE.ChannelCount
ну и все подобные поля и методы. Таким образом, rootу могут быть дистанционно доступны абсолютно все ресурсы удаленного хоста.
ИМХО, так даже еще вкуснее

HandleX писал(а): ...
Само по себе дерево это двусвязный список, с указателеми на родителя. Блочное.

1. Я не против, но зачем двусвязный список? Ясно, что для большей гибкости, но например?
2. Сорри, что значит "Блочное". Типа "Железячное"?

HandleX писал(а): ...
Позже, если будет время, пространно поразмышляю о том, какая должна быть Native 3OS Object File System

Надо сказать, ты действительно рассмотрел пока только "Железный" уровень ОО всей системы в целом, взяв пример одного из направлений. Но дальше, ведь, дерево будет "проростать" в уровень пользователя? На каком уровене лучше "вставить" драйверы файловых систем, да так, чтобы не тормознуто было?
Наверх
izzi_narkomanius
Wednesday 24.03.2004 22:35 Цитата
Зарегистрирован: Tuesday 06.01.2004 21:02
Сообщений - 27
тык идея в принципе понятна -но! das is глупо перечеркивать наработки сотен программеров, изобретателей только потому что вас они не устроили. у ваc есть замена формату mpeg? кодеку divx? либо вы смиритесь с разными форматами - либо ничего у вас не выйдет
Наверх
izzi_narkomanius
Thursday 25.03.2004 16:25 Цитата
Зарегистрирован: Tuesday 06.01.2004 21:02
Сообщений - 27
ответ скорее в стандарты и 3ос был. если вопрос в КПД то на прежде всего смотреть не какой у нас объект а где у нас тормозит. при переключении между потоками главный тормоз -сброс TLB. потому некоторые потоки разумно сделать общими чтоб они существовали св любом адресном пространстве. или хаводить процесс с большим колвом потоков драйверов. хотя это скорее огранизация моего ядра и наверно вам не очень подойдет. к тому же для работы этой схемы необходима сегментация
Наверх
AlexeyASugonyaev
Friday 26.03.2004 08:03 Цитата
Зарегистрирован: Tuesday 18.11.2003 06:36
Местоположение: Челябинская обл., г.Карталы
Сообщений - 68
izzi_narkomanius писал(а): ...
ответ скорее в стандарты и 3ос был. если вопрос в КПД то на прежде всего смотреть не какой у нас объект а где у нас тормозит. при переключении между потоками главный тормоз -сброс TLB. потому некоторые потоки разумно сделать общими чтоб они существовали св любом адресном пространстве. или хаводить процесс с большим колвом потоков драйверов. хотя это скорее огранизация моего ядра и наверно вам не очень подойдет. к тому же для работы этой схемы необходима сегментация

Может вообще проще фиксировать весь TLB? Это гораздо продуктивнее, причем фиксировать его на наиболее активных потоках. Но для этого нужна совершенно иная модель памяти нежели используемая сейчас традиционно страничная. А переключение (хардверное) задачи в любом случае инвалидирует TLB, так что плясать надо именно от этого места: либо софтверное переключение задачи, либо что то иное - о чем я написал выше.
Наверх
izzi_narkomanius
Saturday 27.03.2004 00:16 Цитата
Зарегистрирован: Tuesday 06.01.2004 21:02
Сообщений - 27
а если вообще вынести потоки на уровень узера?
например так - в процессе имеется функция
int user_exec(struct context *th_cx) возвращает колво раз которое её можно вызвать еще - для запуска других потоков на соседних процах при выборе процесса. то есть если функция вернула не 0 это значит что процесс остается в планировщике а не отправяется в список работающих процессов и еще раз не запустится. а если не вернула до переключения процесса - сохранить состояние процесса и потом начать его с места остановки.
+возвращает адрес контекста которым надо заполнить регистры CS:EIP. после чего происходит передача управления по этому контексту. просто и аккуратно. ядро ~300байт. тогда процесс сможет сам решить как ему планировать свое время.


только я не об этом - разделяемые потоки
это те потоки которые выполняются в расшаренной области памяти и отделены от узера сегментацией. они выполняются в ring 3 но их память размечена во все процессы.
Наверх
Hover
Sunday 31.07.2005 20:58 Цитата
Зарегистрирован: Friday 29.07.2005 22:50
Местоположение: Там, где не боятся думать.
Сообщений - 10
Извините, конечно, за оверквотинг, но отдельные мысли для цитирования вычленять лень. Поэтому выскажу вео мнение сразу обо всем.
Roman I Khimov писал(а): ...
Потому что не удовлетворяет!
Никогда не сталкивались с id3v1, id3v2, APE-тегами? В одних одно, в других другое, периодически программы не могут понять записи друг друга.
Есть еще одна большая проблема - проблема промежуточного формата[i], как я бы ее назвал. Посмотрите - сколько форматов хранения изображений - и JPEG, и GIF, и PNG, и TIFF, и BMP, и многие другие. Но - это форматы хранения результата работы художника! А работает-то он не с ними, а с Photoshop, Corel Draw - у них свои промежуточные форматы, форматы в которых хранится чуть ли не весь процесс создания изображения. И эти форматы оказываются жестко связаны с соответствующей программой! Нет Corel Draw - отдыхай. Это нормально? Данные есть, но прочитать их невозможно! Идти покупать Corel Draw - дороговато как-то. А мне ничего не надо, я хочу видеть результаты своей работы, даже если я их не выкинул в JPEG, GIF...
Более того - я хотел бы иметь возможность минимально эти данные редактировать! И я хотел бы иметь возможность перетащить "вьюер" это формата вместе с самим файлом, поскольку у друга такого нету... И как прикажете быть? Таскать с собой кучу ненужных программ, одна из которых работает с форматами А, Б и В, но не работает с Г, а вторая с А, Г и Е, но не понимает Б и В?
Проблема в унификации форматов хранимых данных - все должно быть читаемо на любой платформе! Какого черта я должен ставить себе Windows и MS Office, если мне надо посмотреть .doc файл? Может я родился с дистрибутивом Linux'а в руках! А OpenOffice навороченные .doc документы все-таки коверкает.
Данные не должны быть зависимы от платформы. Поэтому создание 3OS - это не только создание новой ОС, но и создание новой системы хранения всех данных, представимых в двоичной форме. Это все должно быть снабжено инструментами конвертации в "традиционные" форматы файлов, но поверьте мне, когда подход 3OS к хранению и обработке данных можно будет потрогать руками вы это оцените!
Никакой explorer не может отделить .sxw от .doc - ему это все одно и он ничерта не знает ни о том, ни о другом, если у него нет программы просмотра - это просто [i]мусор
, все равно невозможно с ним ничего сделать и он никогда не сможет сказать, что необходимо для просмотра такого документа. Видя объект типа "электронная таблица" 3OS-система, даже не зная о формате ничего, может предположить где брать средства работы с ним - на 3os.ru конечно же! Передать тип объекта, получить все что надо по сети. Все. Пользователь может спокойно работать с этим объектом. А не заниматься поисками типа "А вот это что за ерундень такая?.. Чем ее открыть-то вообще можно?".
Единственное требование к сторонним разработчикам - предоставьте описание формата. Все. А еще лучше воспользуйтесь нашими, развейте их, ведь описание класса можно и нужно расширять методами работы с ним, почему нет? Можете продавать этот кодек (а любой вызываемый метод, который изменяет состояние объекта - это кодек), раздавать его - нам все равно. Только сделайте так, чтобы после его применения объект был читаем.
Связь "файл-программа" должна уйти в прошлое, как воспоминание о страшном кошмаре. Объект самодостаточен! Хотя храниться на винчестере будут только данные этого объекта, связать их с кодом данного объекта не должно быть проблемой. Более того - две 3OS-системы смогут еще при передаче объекта "договориться", а есть ли у получателя средства работы с данным объектом, и если нет - тут же отправить их!

Про желание смотреть *.cdr без Корела: а фильмы без видеоплеера вам проигрывать не хочется? А рендерить 3дмаксовские сцены без 3дмакса? Вы же понимаете, что есть файлы (ну не нравится файлы, тогда ДАННЫЕ), которые обрабатываются кодером/декодером в полсотни килобайт, но ведь есть и данные посложнее, к примеру те же векторные или форматы данных. Во-первых они просто большие (библиотека корела, обеспечивающая обработку векторных форматов весит около 10 метров). Во вторых работа с такими типами данных не ограничивается пятью командами, и для их редактирования нужна фактически уже вся "студия", даже если вывести "наверх" все методы работы с данным файлом сконструировать из них удобный и правильно работающиий шелл приложения пользователь не сможет. (обратите внимание, когда корел грузится, он дольше всего именно создает свой интерфейс). Поэтому "внешними методами" в таким сложным данным будут только открыть/закрыть, печатать и "изменить в некоей среде".

А теперь по концепции вообще. Вы в этом видите прорыв??? А прорыва-то и не получится. Получится если не изобретение велосипеда, то его усовершенствование. Вы просто воспроизводите технологию OLE. Посмотрите в реестр. Там написано, что, скажем, файлы *.jpeg соотнесены с классом ACDSee.jpeg (логично, ACDSee ведь стоит). И там описано через что его открывать, через что печатать и т.д. Если установить ACDSee Power Pack, то там также будет написано через что их можно конвертить и все это будет работать через контекстное меню! (собственно все это к OLE никакого отношения не имело ). Теперь по поводу OLE.там же рядом написан CLSID OLE-контейнера для Jpeg файлов. Ну а у контейнера есть метод заполнения из файла. Единственное что, не на все типы файлов в Windows есть контейнеры. Но это уже дело не среды а прикладных программистов...

И вопрос немного в другую тему. Принцип работы в 3OS такой: у нас валяется на винте какое-то данное мы хотим с ним работать и вызываем метод этого данного. и данное обрабатывается. тут все ясно. А если же мы хотим выполнить действие не предполагающее работы над конкретными данными пользователя? Например запустить игру. Ведь тут не предполагается обработка каких-то конкретных известных пользователя данных.Как быть в этом случае?

Мой Plasma Shotgun - сатира!
Наверх
Перейти к странице Предыдущая -1-2-3

Модераторы: Roman I Khimov, netwizard.

Переход:     Наверх