OSDev http://osdev.su/ |
|
Интерфейс возможно файловый. http://osdev.su/viewtopic.php?f=5&t=1075 |
Страница 2 из 3 |
Автор: | pavia [ 12 апр 2015, 15:40 ] |
Заголовок сообщения: | Re: Интерфейс возможно файловый. |
Но вопрос не в том делать ВФС или нет. А в том что есть разные ФС и следовательно есть разные параметры вернее атрибуты. Основная идея в том что я хочу дать прикладной программе доступ к каталогу. Но так как есть разные ФС, то хочется ввести абстрактную запись. Это нужно что-бы не плодить сущности. Но проблема в том что по мимо сокрытия информации о реализации. Нужно и расширегие. И вот как спроектировать систему которую можно расширять. Конечно тут советуют взять всё по максемому. Но я не хочу много времени тратить на выяснения максимума. |
Автор: | Freeman [ 12 апр 2015, 21:33 ] |
Заголовок сообщения: | Re: Интерфейс возможно файловый. |
pavia писал(а): Конечно тут советуют взять всё по максемому. Но я не хочу много времени тратить на выяснения максимума. А не нужно выяснять максимум прямо сейчас. Достаточно принять это как архитектурное направление и предусмотреть возможность роста в будущем. Нормальный инженерный подход. |
Автор: | D-S [ 13 апр 2015, 09:38 ] |
Заголовок сообщения: | Re: Интерфейс возможно файловый. |
Я категорически за vnode/vfs. 1. Он хотя и косоватый для атрибутов, но проверенный жизнью и главное, для него есть много реализаций, которые можно смотреть и использовать. Иначе придется самому кодить себе файловую систему. Можно взять что-то простое и проверенное временем и с этим работать. Ext4 например можно и на первых порах без журнала. Там не так много зависимостей с ядром - вполне можно портировать. В результате будут переносимые хранилища данных. 2. Файловый интерфейс - достаточно низкоуровневый интерфейс и никто не мешает сделать его объектно орентированные надстройки. 3. Для разработки своего нужно для начала точно сформулировать чем не устраивают интерфейсы существующие. Такое ТЗ может здорово помочь в работе. |
Автор: | Freeman [ 13 апр 2015, 21:29 ] |
Заголовок сообщения: | Re: Интерфейс возможно файловый. |
pavia писал(а): Я пока решил остановиться на абстрактном типе. Так как есть 2 типа файла открытые и те что в каталоге. То видимо придется использовать множественное наследование. Откуда требуется для каждого типа хранить список интерфейсов. Перечитал тему от начала до конца и понял, что не совсем понимаю, что хочет сделать автор. Нужно больше контекста. Это внутри ОС будет? Что имеется в виду под словом "интерфейсы"? По формальным признакам пока выделяю лишь сообщение Bargest-а, поскольку он описывает что-то конкретное и свое, а не призывает бездумно копировать чужие решения. |
Автор: | iz56 [ 13 апр 2015, 22:11 ] |
Заголовок сообщения: | Re: Интерфейс возможно файловый. |
Интерфейс _возможно_ файловый. От файлов требуется только одно - возможность давать имена порциям данных в пространстве имён носителя. Всё что сверх этого - излишки и капризы программистов. |
Автор: | Freeman [ 14 апр 2015, 22:17 ] |
Заголовок сообщения: | Re: Интерфейс возможно файловый. |
iz56 писал(а): От файлов требуется только одно - возможность давать имена порциям данных в пространстве имён носителя. Это только для FAT справедливо. Общая картина сложней. За сутки мысли отстоялись, теперь могу их сформулировать. Я вспомнил, почему придал большое значение атрибутам. По смыслу атрибуты разбиваются на три логические группы: статус, воздействующие на имя (ссылки, метки) и воздействующие на данные (сжатие, шифрование, разрежение, доступ по сети). Один бит атрибута может скрывать тонны кода, реализующего необходимую функциональность. В решении Bargest-а предусмотрена логика для атрибутов, воздействующих на имя: Bargest писал(а): Драйвер должен преобразовать path/to/file в реальное имя. Например, если ФС не поддерживает разные регистры букв - перевести к общему регистру, если в пути есть ссылки (симлинки/ярлыки, лежащие на диске) - развернуть их и так далее. Аналогичным образом можно организовать абстракцию и над сжатием, шифрованием и разрежением. |
Автор: | iz56 [ 14 апр 2015, 22:32 ] |
Заголовок сообщения: | Re: Интерфейс возможно файловый. |
Меня пугает такое безответственное отношение к ресурсам - какие-то аттрибуты, используемые менее чем в 0,001 случаях. А в ФС для этого выделено место - на каждый файл , байт. Вроде немного. А файлов тысячи и более. И теперь из-за такой ерунды код обслуживающий ФС, будет обрабатывать при каждом обращении к файлам еще и аттрибуты. Опять ресурсы уходят в песок. Метаинформация не должна быть навязанной. Делайте к каждому файлу довесок в виде файла_с_метаинформацией - а там хоть что. |
Автор: | pavia [ 15 апр 2015, 00:42 ] |
Заголовок сообщения: | Re: Интерфейс возможно файловый. |
По поводу довестка. Вот так это сделано в *nix'ах: http://csalpha.unomaha.edu/~stanw/papers/90-vnode.pdf Выделяется не в ФС, а в ВФС. Но вопрос интересный надо будет подумать. PS. Я немного отвлёкся на графику. Будет время напишу всё про ФС. |
Автор: | Yoda [ 15 апр 2015, 12:48 ] |
Заголовок сообщения: | Re: Интерфейс возможно файловый. |
iz56 писал(а): Меня пугает такое безответственное отношение к ресурсам - какие-то аттрибуты, используемые менее чем в 0,001 случаях. Время последнего изменения файла – тоже атрибут. Он лишний? iz56 писал(а): А в ФС для этого выделено место - на каждый файл , байт. Вроде немного. А файлов тысячи и более. Несколько килобайт на файловую систему – не беда. Плохо другое – почти все атрибуты идеологически устарели или вообще вредны. Так, атрибутом Read-Only сейчас уже никого не остановить, но иногда от него возникает неожиданный геморрой, например, когда удаляешь файлы, скопированные при помощи проводника с компакт-диска. Иногда же геморрой с read-only превращается в настоящую головную боль. Так есть соньковский MP3-плеер, соединяющийся с компом по мультимедиа-протоколу. Жена туда закидывает файлы с компакт-диска (естественно с установленным атрибутом "только для чтения"). Как обычный диск плеер в системе не видится (специфика мультимедиа-протокола). Но атрибут read-only у файлов при этом копируется. Софт плеера наотрез отказывается удалять файлы с таким атрибутом. Не то, чтобы спрашивает подтверждения, а просто отказывается, не важно, как запрошено удаление, с компа или кнопками на панели. Вопрос: что делать? Удалить такие файлы можно только переформатированием плеера . За последние Nдцать лет я ни разу не сталкивался с осмысленным использованием этого атрибута. Не раз приходилось консультировать по геморрою "почему я не могу удалить директорию? Она же пустая!" Ан, нет, не пустая, – какая-то дурацкая софтина создала в ней скрытый файл. А смысл атрибута "системный" вообще ускользает от меня. Даже в старой ДОСовской архитектуре атрибутов это, по большому счёту, комбинация атрибутов "скрытый" и "только для чтения". Линуксовые атрибуты ещё хуже. Чего стоит только "время последнего чтения файла" – вы только читаете носитель, а на него при этом происходит запись! Идея универсальной метаинформации (также как и NTFS-потоков) тоже вредна, поскольку превращает атрибуты в свалку нестандартизированного и ни с чем не совместимого бардака. Их даже нельзя запаковать в архив. Моё сугубо личное мнение: необходимо отказаться от использования любых атрибутов (а также любой метаинформации) кроме одного – времени последней записи в файл. |
Автор: | SII [ 15 апр 2015, 14:37 ] |
Заголовок сообщения: | Re: Интерфейс возможно файловый. |
Я довольно широко использую атрибут "только для чтения" для своих собственных нужд -- чтобы случайно не похерить файл, который мне нужен и содержимое которого должно оставаться неизменным. Так что не могу согласиться, что такой атрибут совсем уж не нужен. Атрибут скрытого файла тоже небесполезен -- позволяет не загромождать отображаемый каталог служебными файлами, которые должны там быть, но которые не нужны пользователю. Вот что полезно было бы -- возможность привязать к файлам текстовые теги, заданные пользователем, чтобы потом быстро искать файлы именно по этим тегам. Понятно, что всё это нужно далеко не всем и каждому, но есть те, кому нужно. Так почему бы это не поддерживать? |
Страница 2 из 3 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |