OSDev

для всех
Текущее время: 29 мар 2024, 16:02

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 25 ]  На страницу 1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Интерфейс возможно файловый.
СообщениеДобавлено: 11 апр 2015, 11:18 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1126
Сижу придумываю файловый интерфейс. Так вот в чем трудность есть разные файловые системы. И хочется иметь универсальный дескриптор файла.
Как бы вы сделали такой дескриптор-описатель?


Я пока решил остановиться на абстрактном типе. Так как есть 2 типа файла открытые и те что в каталоге. То видимо придется использовать множественное наследование.
Откуда требуется для каждого типа хранить список интерфейсов.
Я вот думаю что как-то сложно получается. Можно ли как-то проще это сделать?

Не хочется как-то уходить в ООП. А остаться с функциональным способом работы.

Что бы было понятно дескриптор файла.
Код:
TFileDescriptor - абстрактный тип.
  TypeInfo:TTypeInfo;
  Делегаты:
    Path:TPath;
    MainParametrs:TFileParamets;
    Lock:TLock;
  end;

 
TFileParamets= record
  Size:SInt64;
  SystemUser:(fpSystem,fpUser);
  Private:(fpPrivate,fpVisible);
  end;
 

TTypeInfo=record
  Indefiner = TGUID
  Interfaces:array of TInterfaceInfo;
  end;


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Интерфейс возможно файловый.
СообщениеДобавлено: 11 апр 2015, 17:39 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
Гм, гм. Файлы, интерфейсы и GUID. Что-то это мне напоминает... Делается попытка переизобрести Windows Cairo или концепцию 3OS 2004 года? У этой задачи есть только одно решение. :ugeek:

А вот файловые системы нужно не нивелировать до наихудшей, а приводить к наилучшей, иначе получатся классические дырявые абстракции: абстракция есть, но на практике всё равно приходится писать код вне нее. Чтобы избежать этого, за образец нужно брать наиболее проработанную файловую систему -- IFS/NTFS или что-то аналогичное продвинутое из *NIX (ReiserFS?).

В модуле CoreWrappers есть такое описание:
Код:
type
  TFileAccess = set of (faShareRead, faShareWrite, faShareDelete, // ordered
    faWrite, faKeep, faOverwrite, faDeleteOnClose, faSequential, faRandom,
    faNoBuffering, faOverlapped, faWriteThrough);

  TFileAttributes = set of (faReadOnly, faHidden, faSystem, faVolumeLabel,
    faDirectory, faArchive, faNormal, faTemporary, faSparsed, faReparsePoint,
    faCompressed, faOffline, faNonIndexable, faEncrypted, fa0x8000, faVirtual);


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Интерфейс возможно файловый.
СообщениеДобавлено: 11 апр 2015, 18:46 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1126
Как не стараюсь изобретать, а у меня всё Windows получается. :D
Можно конечно GUID заменить на класс атрибут с описанием структуры основного класса. Но пользоваться им будет нельзя. Так как это служит для единоразового обмена.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Интерфейс возможно файловый.
СообщениеДобавлено: 11 апр 2015, 20:18 

Зарегистрирован: 26 мар 2012, 17:32
Сообщения: 209
Просто нужно делать VFS, а не как в винде. Дескриптор соответственно привязывается к inode в VFS. А в точках монтирования ссылаться на драйвер той или иной ФС, реализуя отображения между виртуальными inode и реальными.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Интерфейс возможно файловый.
СообщениеДобавлено: 11 апр 2015, 20:35 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
pavia писал(а):
Как не стараюсь изобретать, а у меня всё Windows получается. :D

А ведь если подумать, в этом нет ничего странного. Компания Apple создавалась как разработчик бытовых ПК, Google -- как интернет-поисковик, и только Microsoft -- как компания-разработчик системного ПО. А NTFS и Cairo разрабатывались еще при Билле Гейтсе.

Nable писал(а):
Просто нужно делать VFS, а не как в винде. Дескриптор соответственно привязывается к inode в VFS.

А чем копирование решений *NIX лучше копирования решений Windows?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Интерфейс возможно файловый.
СообщениеДобавлено: 11 апр 2015, 20:59 

Зарегистрирован: 26 мар 2012, 17:32
Сообщения: 209
Потому что в одном случае исторически сложившиеся костыли и подпорки с наслоениями совместимости, а в другом - действительно решения, за которыми какое-то проектирование и теория стоят. VFS есть не только в *nix и я не говорю копировать реализацию из *nix (в ней барахла не меньше, чем в виндах), я говорю про идеи. Вот есть идея VFS. А в виндах и идеи-то толком нет (кроме того что пытаться нивелировать время разбора структур ФС с помощью блочного кеша, да со временем подтягивать идеи, которые в других системах давно устоялись).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Интерфейс возможно файловый.
СообщениеДобавлено: 12 апр 2015, 11:44 

Зарегистрирован: 31 окт 2011, 18:20
Сообщения: 230
Цитата:
Вот есть идея VFS. А в виндах и идеи-то толком нет

В винде изначально идея - юзер явно задает устройство и путь на нем. Как "C:\path\to\file". Или "COM1:" для ком-порта. При этом одно устройство, как я понимаю, может находиться на другом. Имеем четкое дерево устройств. Можем четко передавать IO запросы родительскому устройству.
Цитата:
действительно решения, за которыми какое-то проектирование и теория стоят.

Не сказал бы: наплодить рандомное дерево с кучей перекрестных ссылок и к половине рандомных узлов привязать рандомные драйвера - это не серьёзное проектирование и теория. Из-за VFS изредка даже всплывают зияющие дыры в безопасности, например когда оказывается, что node можно перемонтировать на систему и писать туда из-за того, что драйвер проверочку не сделал (хотя если уж делается VFS, то это дело системы, разве нет?). Пока писал драйвер для линуска на работе - обплевался этой "чудесно спроектированной" системой. А мне ведь от драйвера всего ничего надо было.

По сабжу. У меня сделано так:
1) ПО открывает файл по строке следующего вида: DevName:(//)path/to/file (// сейчас нет, но потом может добавлю, если не лень будет. Все же смысловой нагрузки он не несет).
2) Система вызывает драйвер устройства DevName по точке входа resolve. Драйвер должен преобразовать path/to/file в реальное имя. Например, если ФС не поддерживает разные регистры букв - перевести к общему регистру, если в пути есть ссылки (симлинки/ярлыки, лежащие на диске) - развернуть их и так далее. Допустим, драйвер вернул путь my/new/file.txt
3) Система преобразует DevName к ID-шнику устройства фиксированной длины (пусть это будет 0001) и создает/открывает серию файлов:
0001:my
0001:my/new
0001:my/new/file.txt
Эти файлы выстраиваются в дерево. Если файл в памяти был создан, он просто открывается. Если нет - вызывается функция драйвера по открытию/созданию объекта, туда передается "объект". При создании драйвер может в "объект" (который является универсальным системным типом) в предусмотренные user-defined поля записать любые значения. Эти значения гарантировано не будут изменены до удаления объекта (файла).
Есть хорошие задатки:
1) Благодаря явному заданию устройства в начале пути мы скрываем от юзера/по дерево устройств, и потому оно имеет вполне четкую структуру (ведь никакой юзер не запускает в него свои кривые ручки). Можно организовать стек драйверов с вызовом драйвера родительского устройства через стандартные функции IO, при этом не реализуя дополнительную логику внутри драйвера.
2) Система не просматривает и не открывает те файлы, к которым за сеанс работы не будет ни одного обращения (таких абсолютное большинство), не создает лишних узлов в дереве файлов.
Но есть проблема - как сделать перечисление доступных файлов. Пока особо не думал. Скорее всего это будет одной из опциональных фич конкретного драйвера, и она будет возвращать список путей или просто имя N-го файла в определенной директории. Хотя бы потому, что не для каждого устройства эта операция имеет смысл.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Интерфейс возможно файловый.
СообщениеДобавлено: 12 апр 2015, 13:29 

Зарегистрирован: 04 ноя 2007, 14:48
Сообщения: 113
А я думаю что всё уже написано до нас, и нужно просто взять и скопировть наиболее понравившееся решение.
Все эти VFS IFS NTFS whateverFS - идея есть у всех. И у всех эта идея одна и та же. А реализации разные.
И уж раз речь пошла про костыли, то везде сплошные костыли (я открою вам секрет, даже в том, что вы напишете будет ещё бОльшая масса костылей). Я бы сказал что в винде их меньше просто исходя из того, что кодерам заплатили за их работу, значит у них была мотивация писать более качественный код. И не только кодерам, но и архитекторам.
И да, ООП и функциональное программирование не исключают друг друга.
Подумайте над этим. Вот.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Интерфейс возможно файловый.
СообщениеДобавлено: 12 апр 2015, 14:34 

Зарегистрирован: 26 мар 2012, 17:32
Сообщения: 209
dragon писал(а):
И уж раз речь пошла про костыли, то везде сплошные костыли.
Несомненно, никогда с этим не спорил.
dragon писал(а):
Я бы сказал что в винде их меньше просто исходя из того, что кодерам заплатили за их работу, значит у них была мотивация писать более качественный код. И не только кодерам, но и архитекторам.
ОМГ, кто-то ещё не в курсе что свободный софт != бесплатный. Это я к тому что не-в-винде кодерам и архитекторам тоже платят и ещё как (Red Hat, HP, Intel, IBM и прочие менее известные конторы). Кроме того, миллионы обобщённых индусов могут замечательно поспорить с утверждением что деньги мотивируют писать качественный код. Так что неудачный аргумент.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Интерфейс возможно файловый.
СообщениеДобавлено: 12 апр 2015, 15:33 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1126
Bargest писал(а):
Цитата:
Вот есть идея VFS. А в виндах и идеи-то толком нет

В винде изначально идея - юзер явно задает устройство и путь на нем. Как "C:\path\to\file". Или "COM1:" для ком-порта. При этом одно устройство, как я понимаю, может находиться на другом. Имеем четкое дерево устройств. Можем четко передавать IO запросы родительскому устройству.

Да так было до поры до времени. Но в 2k уже это не так. Там также есть отображения. А вообще они что-то в Win 7-8 там меняли.

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

Хотя если говорить про DirectX и NDIS которые выпускались раз в 3 месяца и потому как друшлак. И каждый норовит обойти костыли или лишние абстракции для ускорения.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 25 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB