| Привет |
| Мини-чат |
Вы должны быть авторизованы, для того чтобы оставлять комментарии на сайте. Пожалуйста, авторизируйтесь или зарегистрируйтесь на сайте. @Wanderer:Верно.Но в тоже время останавливаться на позициях критика не желаю.Есть уже рабочие намётки(можно по телнету пощупать) для всей этой истории,правда Буратино пока ещё носом не дорос,чтобы презентовать широкой публике.
Зато осталась главная мысль, которую нужно распечатать и повесить на самом видном месте: "Если хотите достичь успеха, меньше говорите и больше делайте". Вкратце, будьте немыми трудоголиками.
@exelents:от проекта остался весь этот веб.Только и всего.Пока так.Кто молится на линукс,кто на винду.Понимая всю безисходность,вся аудитория удалилась.К сожалению не вижу креатива в переработке POSIXґа!Вообще никто не замечает...Нафик ядро нужно,если подсистема над ним отсутствует?!На мой взгляд надо концентрироваться на новом возможном стандарте,и даже в переработке языка C/C++,если так охота можно всё назвать уже D...То что есть - сказал бы... - желаю себе лучшего!
По всем внешним признакам этот проект успешно загнулся.
Ни тебе описание процесса, ни новых версий.. Загублено.. Есть кто-нибуть из Саратова/Энгельса?
|
| Операционная система 3OS -> Форумы -> Идеология проекта | |||
|
|||
 Критики немногоПерейти к странице Предыдущая -1-2-3 |
| Автор | Отправлено |
| Davy |
|
||
Сообщений - 4 |
Freeman писал(а): ... если 3ОС будет работать на FAT, ни о каких правах доступа и речи не идет. На Ext2 - пожалуйста, но это будут абсолютно те же самые права, что и в Linux. Сорри. Просто по ходу обсуждения я подумал о создании новой ФС. Freeman писал(а): ... Кстати, на данный момент вопросы безопасности в 3ОС вообще не проработаны. Можете чем-то помочь конкретным? Спасение утопающих - дело рук самих утопающих...  |
||
| Наверх |
|
| HandleX |
|
||
Сообщений - 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 |
|
||
|
Сообщений - 4 |
HandleX писал(а): ... IDE.ChannelCount Очень вкусно. Я бы даже предложил объединить в общий корень родителя "Устройства". Т.е.: Dev.IDE.ChannelCount или даже Host("local").Dev.IDE.ChannelCount ну и все подобные поля и методы. Таким образом, rootу могут быть дистанционно доступны абсолютно все ресурсы удаленного хоста. ИМХО, так даже еще вкуснее HandleX писал(а): ... Само по себе дерево это двусвязный список, с указателеми на родителя. Блочное. 1. Я не против, но зачем двусвязный список? Ясно, что для большей гибкости, но например? 2. Сорри, что значит "Блочное". Типа "Железячное"? HandleX писал(а): ... Позже, если будет время, пространно поразмышляю о том, какая должна быть Native 3OS Object File System Надо сказать, ты действительно рассмотрел пока только "Железный" уровень ОО всей системы в целом, взяв пример одного из направлений. Но дальше, ведь, дерево будет "проростать" в уровень пользователя? На каком уровене лучше "вставить" драйверы файловых систем, да так, чтобы не тормознуто было? |
||
| Наверх |
|
| izzi_narkomanius |
|
||
Сообщений - 27 |
тык идея в принципе понятна -но! das is глупо перечеркивать наработки сотен программеров, изобретателей только потому что вас они не устроили. у ваc есть замена формату mpeg? кодеку divx? либо вы смиритесь с разными форматами - либо ничего у вас не выйдет | ||
| Наверх |
|
| izzi_narkomanius |
|
||
|
Сообщений - 27 |
ответ скорее в стандарты и 3ос был. если вопрос в КПД то на прежде всего смотреть не какой у нас объект а где у нас тормозит. при переключении между потоками главный тормоз -сброс TLB. потому некоторые потоки разумно сделать общими чтоб они существовали св любом адресном пространстве. или хаводить процесс с большим колвом потоков драйверов. хотя это скорее огранизация моего ядра и наверно вам не очень подойдет. к тому же для работы этой схемы необходима сегментация | ||
| Наверх |
|
| AlexeyASugonyaev |
|
||
|
Зарегистрирован: Tuesday 18.11.2003 06:36 Местоположение: Челябинская обл., г.Карталы Сообщений - 68 |
izzi_narkomanius писал(а): ... ответ скорее в стандарты и 3ос был. если вопрос в КПД то на прежде всего смотреть не какой у нас объект а где у нас тормозит. при переключении между потоками главный тормоз -сброс TLB. потому некоторые потоки разумно сделать общими чтоб они существовали св любом адресном пространстве. или хаводить процесс с большим колвом потоков драйверов. хотя это скорее огранизация моего ядра и наверно вам не очень подойдет. к тому же для работы этой схемы необходима сегментация Может вообще проще фиксировать весь TLB? Это гораздо продуктивнее, причем фиксировать его на наиболее активных потоках. Но для этого нужна совершенно иная модель памяти нежели используемая сейчас традиционно страничная. А переключение (хардверное) задачи в любом случае инвалидирует TLB, так что плясать надо именно от этого места: либо софтверное переключение задачи, либо что то иное - о чем я написал выше. |
||
| Наверх |
|
| izzi_narkomanius |
|
||
|
Сообщений - 27 |
а если вообще вынести потоки на уровень узера? например так - в процессе имеется функция int user_exec(struct context *th_cx) возвращает колво раз которое её можно вызвать еще - для запуска других потоков на соседних процах при выборе процесса. то есть если функция вернула не 0 это значит что процесс остается в планировщике а не отправяется в список работающих процессов и еще раз не запустится. а если не вернула до переключения процесса - сохранить состояние процесса и потом начать его с места остановки. +возвращает адрес контекста которым надо заполнить регистры CS:EIP. после чего происходит передача управления по этому контексту. просто и аккуратно. ядро ~300байт. тогда процесс сможет сам решить как ему планировать свое время. только я не об этом - разделяемые потоки это те потоки которые выполняются в расшаренной области памяти и отделены от узера сегментацией. они выполняются в ring 3 но их память размечена во все процессы. |
||
| Наверх |
|
| Hover |
|
||
|
Местоположение: Там, где не боятся думать. Сообщений - 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 - сатира! |
||
| Наверх |
|
| В онлайне |
| Гостей: 2, Пользователей: 0 ... Максимум онлайн: 23 (Пользователей: 0, Гостей: 23) зарегистировано 05.12.2005 | 03:31 Зарегистрированных пользователей: 319 Последний зарегистрированный пользователь: maxutov |
| © 3OS.Team 2002-2005 |