Меня посетила такая мысль.
Может стоит переделать немного дисковую подсистему?
Основная идея разделить драйвер файловой системы от драйвера устройства.
Как это будет выглядить.
Имеется 2 таблицы.
1-я таблица - таблица дисков:
type dword
flat_access dword
driver_options dword
name byte[8]
fs_id dword
reserved byte[8]
type - тип дискового устройства harddisk,ramdisk,cdrom,removable,floppy etc
flat_access - указатель на ф-цию драйвера, которая обеспечивает "плоский" доступ к данным
driver_options - указатель на данные необходимые драйверу для доступа к данному диску
name - имя диска при монтировании
fs_id - номер файловой системы.
reserved - в будущем уверен пригодится это раз, во-вторых округление до 32
2-я таблица - таблица доступных файловых систем
со структурой до конца не определился, т.к. плохо знаю как устроены файловые системы. Там должны быть указатели функций для работы с фс и доп инфа.
Теперь как это будет работать.
При загрузке ядро сразу же добавляет рамдиск в эту таблицу и монитрует в /rd/.
Придется немного переделать. Каждое устройство будет монтироваться в корень, а начиная со 2-го уровня будет идти путь на диске.
т.е. /xxx/yyy/yy означает что файл yy лежит в папке yyy от корня диска, смонтированого под xxx.
Отличие лишь в том, что у дисков не будет второй виртуальной папки означающей партицию (/hd1/1/).
Далее каждый драйвер будет добавлять в первую таблицу дисковые устройства.
Например, драйвер IDE сдетектил 2 диска и сидиром. На 1-м обнаружил 2 партиции,на 2-м одну. Значит он добавит в таблицу 4 записи:
harddisk|ide_flat_read|0xXXXXXXXX|0|0|0
harddisk|ide_flat_read|0xYYYYYYYY|0|0|0
harddisk|ide_flat_read|0xZZZZZZZZ|0|0|0
cdrom|ide_flat_read_cd|0xAAAAAAAA|0|0|0
что-то вроде этого, где ide_flat_read это ф-ция драйвера которая обеспечивает плоский доступ к данным.
Для 3-го поля таблицы драйвер создает структуру/массив/какието_данные для каждого диска отдельно. Там будут храниться необходимые для доступа к устройству данные, например IDE может хранить что это за диск (primary/secondary master/slave) и какая партиция и т.п.
остальные поля пока забиваются нулями...
Вот потом эти диски можно будет монировать под таким-то именем для такой-то файловой системы.
А файловые системы должны быть реализованы без привязки к устройствамвам. Файловая система будет использовать лишь функцию плоского доступа.
Под плоским доступом я подразумеваю "получить n байт по такому-то смещению".
Суть ясна? Я знаю, я мысли коряво излагаю. Если есть вопросы - спрашивайте.
А мне нужны советы, стоит ли так делать, если нет, то почему.
Ну и собственно советы по доработке.
Я готов за это взятся в ближайшее время, если необходимо.
Дисковая система
Если можешь, а также хочешь или считаешь нужным - делай. Я не возражаю, думаю, остальные тоже.
2. Функции работы с устройствами по идее всегда выдают целое число секторов.
3. А как же запись? Нужны две функции (одну общую функцию, принимающую дополнительный параметр и делающий switch по нему, не предлагать).
По поводу путей: не совсем понял, текущие пути (/rd/1/somefile.dat, /hd0/1/somefile.dat) сохранятся или изменятся? Если изменятся, то как?
1. Не факт, что функции плоского доступа будет достаточно. Мне с ходу приходит в голову, что у разных устройств, вообще говоря, разные размеры сектора (дискета, жёсткий диск - 0x200 байт, CD-ROM - 0x800 байт), причём существующий код поддержки файловых систем более или менее жёстко завязаны на 0x200 байт, кроме UDFS - там, наоборот, 0x800 байт.А файловые системы должны быть реализованы без привязки к устройствам. Файловая система будет использовать лишь функцию плоского доступа.
Под плоским доступом я подразумеваю "получить n байт по такому-то смещению".
2. Функции работы с устройствами по идее всегда выдают целое число секторов.
3. А как же запись? Нужны две функции (одну общую функцию, принимающую дополнительный параметр и делающий switch по нему, не предлагать).
В текущей реализации информация, нужная для работы коду поддержки файловой системы, хранится в fs_dependent_data_start (fs/part_set.inc) (где описана структура) для текущего обращения к диску и в DRIVE_DATA для всех дисков (куда/откуда она копируется при резервировании раздела). Плюс некоторое количество неинициализированных глобальных переменных ядра.со структурой до конца не определился, т.к. плохо знаю как устроены файловые системы. Там должны быть указатели функций для работы с фс и доп инфа.
По поводу путей: не совсем понял, текущие пути (/rd/1/somefile.dat, /hd0/1/somefile.dat) сохранятся или изменятся? Если изменятся, то как?
Ушёл к умным, знающим и культурным людям.
хм, не знал что файловая система привязывается к секторам. Насколько я читал про FAT там идет понятие блока, и вроде никакой привязке к секторам. Про остальные не знаю. Да и к тому же, как устроены флешки? У меня на флешке стоит FAT32, что не ужели на флешках тоже есть сектора?diamond wrote: 1. Не факт, что функции плоского доступа будет достаточно. Мне с ходу приходит в голову, что у разных устройств, вообще говоря, разные размеры сектора (дискета, жёсткий диск - 0x200 байт, CD-ROM - 0x800 байт), причём существующий код поддержки файловых систем более или менее жёстко завязаны на 0x200 байт, кроме UDFS - там, наоборот, 0x800 байт.
Вот тут я не до конца разобрался(может плоский досуп будет сводится не к байтам а к секторам). Система получается очень похожа на юниховую. В ней девайсы представлены в виде файлов, при маунте любого диска, файловая система через этот файл(точнее иноду) получает доступ к данным на диске, при этом не важно как этот диск устроен физически.
Ответ либо в пункте 1, либо никто не мешает обрезать т.к. требуется.diamond wrote:2. Функции работы с устройствами по идее всегда выдают целое число секторов.
Без проблем. Только почему не катит switch?diamond wrote:3. А как же запись? Нужны две функции (одну общую функцию, принимающую дополнительный параметр и делающий switch по нему, не предлагать).
Можно сделать 2 варианта:
1) просто в таблицу еще один указатель
2) указатель будет не на ф-цию, а на массив ф-ций. Это более гибче, особенно в плане добавления новых ф-ций.
Спасибо за инфу, будет полезно!diamond wrote:В текущей реализации информация...
изменятся. В текущей реализации уходило 2 уровня на определение диска(/hd1/1/). Я предлагаю свести к одному.diamond wrote:По поводу путей: не совсем понял, текущие пути (/rd/1/somefile.dat, /hd0/1/somefile.dat) сохранятся или изменятся? Если изменятся, то как?
Как именовать не суть важно. Можно hd1,hd2,hdn. Правда не видно физическое размещение партиции, а нужна ли она рядовому пользователю? Еще можно что-то вроде линуха hda1,hda2,hdb1, или BSD ad1s1... Опять же - это не суть важно. По моей задумке можно будет вообще именовать /c/, /d/ и т.д.
k@sTIg@r
Под блоком подразумевается кластер. Из блоков соответственно состоят файлы и директории, но вот служебная информация (собственно сам FAT) ориентирован на работу с секторами.Насколько я читал про FAT там идет понятие блока, и вроде никакой привязке к секторам.
Флешка эмитирует дисковое устройство с минимальным размером сектора 512 байт.Да и к тому же, как устроены флешки? У меня на флешке стоит FAT32, что не ужели на флешках тоже есть сектора?
А вот с этим я не согласен. В том же Линукс, по пути можно определить какое физическое устройство используется. Для отладки очень удобно. И к томуже мне не очень нравится излишняя абстракция системы от железа.изменятся. В текущей реализации уходило 2 уровня на определение диска(/hd1/1/). Я предлагаю свести к одному.
Как именовать не суть важно. Можно hd1,hd2,hdn. Правда не видно физическое размещение партиции, а нужна ли она рядовому пользователю? Еще можно что-то вроде линуха hda1,hda2,hdb1, или BSD ad1s1... Опять же - это не суть важно. По моей задумке можно будет вообще именовать /c/, /d/ и т.д.
Правда не видно физическое размещение партиции, а нужна ли она рядовому пользователю?
У меня два винта - sata, ide и dvd. В Колибри они видны как hd0, hd3 и cd2. И о чём мне это говорит ? Так и хочется спросить а где hd1, hd2, cd1 ? (В Ubuntu логические разделы выглядят не лучше - sda2 sda5 sda6). Это раньше было 4 ide устройства, а теперь чёрт ногу сломит. И как сейчас обозначать usb и сетевые диски? /usb1/1, /usb2/2, net1/1... ?А вот с этим я не согласен. В том же Линукс, по пути можно определить какое физическое устройство используется.
Вообще давно пора сделать файловую систему с дескрипторами файлов, и стандартный интерфейс к драйверу физического устройства. Здесь хорошо подойдёт ООП подход. Нужны функции получения параметров устройства, инициализации, сброса при ошибке, чтения и записи n-го количества секторов. Получается вируальный базовый класс физического устройства а дальше уже будут свои производные классы для каждого типа устройств.
Serge
> Получается вируальный базовый класс физического устройства а дальше уже будут свои производные классы для каждого типа устройств.
Собственно это я и хочу сделать Правда я не думал о классах, но к этому шло, покрайней мере логика таже
> Получается вируальный базовый класс физического устройства а дальше уже будут свои производные классы для каждого типа устройств.
Собственно это я и хочу сделать Правда я не думал о классах, но к этому шло, покрайней мере логика таже
"И как сейчас обозначать usb и сетевые диски? /usb1/1, /usb2/2, net1/1... ?" - не могу не фспомнить, что ни того, ни другого Колибри не поддерживает) да и мне лично подход изменения жутко не нравится, хорошо как есть. Про работу через дескрипторы и проч. - это надо писать(переписывать) всю файловую систему, хотя это несомненно приблизит нас к большей высокоуровневости.. но оно надо такое чудо? кстати лично я не против и идеи, и насчет помочь) просто спросил)
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Gluk
Может потому и не поддерживает
Ладно, usb на асме вещь непростая. Пусть будет драйвер виртуального диска. Это проще. Будет удобно работать с образами и в эмуляторе и в реальной системе. И как монтировать и именовать такие диски?
Может потому и не поддерживает
Ладно, usb на асме вещь непростая. Пусть будет драйвер виртуального диска. Это проще. Будет удобно работать с образами и в эмуляторе и в реальной системе. И как монтировать и именовать такие диски?
Serge
А что собственно нам мешает иметь 2 разных наименования для дисков?
Я высказал свое мнение с учетом своего личного опыта работы с дисковыми системами в Винде. Зачастую очень сложно бывает ориентироваться в номерах букв, потому что все разделы очень редко имеют уникальные имена, а судить по размеру логического диска - все равно, что гадать на кофейной гуще. Приходится лезть в свойства и искать - "А на каком это физическом диске расположен искомый логический?".
А так по внешнему виду пути можно с большей уверенностью сказать, что за зверь перед нами, потому что такое название будет неизменным, пока не будет создан новый логический диск посредине уже имеющихся или существующий не будет разбит на 2 или более. А Винда совершенно от балды может повесить диски вперемешку. У меня есть большое подозрение, что и здесь в выбранном направлении развития получится та же хрень...
Надо взвесить все за и против, прежде чем так кардинально менять систему для уровня приложений - опять будем, плюясь переписывать кучу программ. ИМХО я этому не рад.
А что собственно нам мешает иметь 2 разных наименования для дисков?
Я высказал свое мнение с учетом своего личного опыта работы с дисковыми системами в Винде. Зачастую очень сложно бывает ориентироваться в номерах букв, потому что все разделы очень редко имеют уникальные имена, а судить по размеру логического диска - все равно, что гадать на кофейной гуще. Приходится лезть в свойства и искать - "А на каком это физическом диске расположен искомый логический?".
А так по внешнему виду пути можно с большей уверенностью сказать, что за зверь перед нами, потому что такое название будет неизменным, пока не будет создан новый логический диск посредине уже имеющихся или существующий не будет разбит на 2 или более. А Винда совершенно от балды может повесить диски вперемешку. У меня есть большое подозрение, что и здесь в выбранном направлении развития получится та же хрень...
Надо взвесить все за и против, прежде чем так кардинально менять систему для уровня приложений - опять будем, плюясь переписывать кучу программ. ИМХО я этому не рад.
Ты не первый, кого посещает эта мысль. Было также предложение halyavin'а: http://shade.msu.ru/~msu-se/driversystem.htmlk@sTIg@r wrote:Меня посетила такая мысль.
Может стоит переделать немного дисковую подсистему?
Основная идея разделить драйвер файловой системы от драйвера устройства.
viewtopic.php?f=2&t=356
Вообще лучше сохранять совместимость, если нет веских причин этого не делать. Далее, физическое размещение партиции рядовому пользователю не нужно, но это не значит, что его вообще бесполезно знать. В винде я в принципе умею это определять программно (при наличии прав админа), но понятия не имею, как это сделать пользователю, а иногда это нужно.k@sTIg@r wrote:В текущей реализации уходило 2 уровня на определение диска(/hd1/1/). Я предлагаю свести к одному.
Как именовать не суть важно. Можно hd1,hd2,hdn. Правда не видно физическое размещение партиции, а нужна ли она рядовому пользователю?
С другой стороны, в словах
тоже что-то есть.Serge wrote:У меня два винта - sata, ide и dvd. В Колибри они видны как hd0, hd3 и cd2. И о чём мне это говорит ? Так и хочется спросить а где hd1, hd2, cd1 ? (В Ubuntu логические разделы выглядят не лучше - sda2 sda5 sda6). Это раньше было 4 ide устройства, а теперь чёрт ногу сломит. И как сейчас обозначать usb и сетевые диски? /usb1/1, /usb2/2, net1/1... ?
Ну вообще-то сам FAT тоже содержит информацию о кластерах. Но от необходимости знать размер сектора это не освобождает: некоторые критические параметры файловой системы выражены в секторах. Кроме того, код поддержки файловой системы, как уже было сказано, существенно использует размер сектора.Mario79 wrote:Под блоком подразумевается кластер. Из блоков соответственно состоят файлы и директории, но вот служебная информация (собственно сам FAT) ориентирован на работу с секторами.
Ушёл к умным, знающим и культурным людям.
Gluk
>Хорошо как есть....
Для чего хорошо? для текущей ситуации - да, лучше не бывает, все работает и хорошо. А если смотреть в будущее? Придется приходить ко всяким ухищрениям, чтоб прикрутить те же флешки. а про сетевые я молчу.
Так зачем делать сразу ущербно? Тем более на данный момент переделывать не так уж и много.
Maro79
Как бы тебе объяснить. То что я скажу растроит многих. Автоматического монтирования не будет! Автоматически будет монтироваться только рамдиск. Вот тут уже есть несколько путей:
1) для продвинутых юзеров. Будет конфиг файл, который будет маунтить такой-то такой-то диск туда-то туда-то.
2) для простых. Будет програмка, которая будет детектить фс на диске (должна быть ф-ция файловой системы) и монтировать автоматически под определенными именами (по типу текущей реализации)
Тут есть много вариантов и нюансов.
Давайте выясним все за и против. Я "против" не вижу А все "за", как я вижу, вроде бы все понимают.
>Хорошо как есть....
Для чего хорошо? для текущей ситуации - да, лучше не бывает, все работает и хорошо. А если смотреть в будущее? Придется приходить ко всяким ухищрениям, чтоб прикрутить те же флешки. а про сетевые я молчу.
Так зачем делать сразу ущербно? Тем более на данный момент переделывать не так уж и много.
Maro79
Как бы тебе объяснить. То что я скажу растроит многих. Автоматического монтирования не будет! Автоматически будет монтироваться только рамдиск. Вот тут уже есть несколько путей:
1) для продвинутых юзеров. Будет конфиг файл, который будет маунтить такой-то такой-то диск туда-то туда-то.
2) для простых. Будет програмка, которая будет детектить фс на диске (должна быть ф-ция файловой системы) и монтировать автоматически под определенными именами (по типу текущей реализации)
Тут есть много вариантов и нюансов.
Давайте выясним все за и против. Я "против" не вижу А все "за", как я вижу, вроде бы все понимают.
Черт, плагиатчикdiamond wrote: Ты не первый, кого посещает эта мысль. Было также предложение halyavin'а:
Тока не понял, почему все загнулось? Хотя в моем представлении все работает немного по другому.
diamond wrote:Вообще лучше сохранять совместимость, если нет веских причин этого не делать.
Это понятно. Но такой вид по крайней мере некрасиво и неудобно. Да и не вижу проблем. Проблемы будут если какие-либо приложения использовали полные пути (например /rd/1/...). Просто придется такие перебить на /rd/... Собственно и все. Зато дальше удобней будет.
Да, не спорю, нужно знать. Но не по монтируемому имени же? Будет доп функция, которая по имени диска выдаст тебе инфу.diamond wrote:Далее, физическое размещение партиции рядовому пользователю не нужно, но это не значит, что его вообще бесполезно знать. В винде я в принципе умею это определять программно (при наличии прав админа), но понятия не имею, как это сделать пользователю, а иногда это нужно.
Да, тут пардон, полез в дебри которые не знаю. Ща кое-что почитал и понял. Для примера в том же линухе, есть понятие блочный девайс (а не так как я думал раньше, что это обычный файл и писец).diamond wrote:Ну вообще-то сам FAT....
Придется мои какракули переписать...
У нас хорошие идеи обычно загибаются от того, что некому писать кодТока не понял, почему все загнулось?
Пожалуйста, пиши как представляешь. Мнение пишущего код программиста всегда приоритетнее остальных.Хотя в моем представлении все работает немного по другому.
Проблемы будут с файловыми менеджерами. kfar, например, считает во многих местах, что пути выглядят именно так, как они сейчас выглядят (/имя устройства/раздел/путь на устройстве). sysxtree использует структуру существующих путей при показе значков и отображении типа элемента на первых двух уровнях файловой иерархии. Насчёт kfm не знаю.Проблемы будут если какие-либо приложения использовали полные пути (например /rd/1/...). Просто придется такие перебить на /rd/... Собственно и все. Зато дальше удобней будет.
"Для чего хорошо? для текущей ситуации - да, лучше не бывает, все работает и хорошо. А если смотреть в будущее?" - хорошо по простой и банальной причине что мне это удобно, и по моему лучше не надо, просто потому что не нужно, не имеет смысла, и лучше будет означать хуже)
"У меня два винта - sata, ide и dvd. В Колибри они видны как hd0, hd3 и cd2. И о чём мне это говорит ?" - уточню твою задачку. sata у тебя наверное не просто hd0, ф /hd0/1/ + /hd0/2/ , то же с ide. абсолютно видно какой раздел где лежит по крайней мере об этом тебе "это говорить")
А теперь реши мою задачку - у меня в винде один sata, один флоппик, один сидиром, один кардридер. логически это диски A, C, D, E, F, G, H, I, J, M. итак, что мне об этом говорит? а ты как я понял хочешь добиться примерно того же в нашей птичке.
"У меня два винта - sata, ide и dvd. В Колибри они видны как hd0, hd3 и cd2. И о чём мне это говорит ?" - уточню твою задачку. sata у тебя наверное не просто hd0, ф /hd0/1/ + /hd0/2/ , то же с ide. абсолютно видно какой раздел где лежит по крайней мере об этом тебе "это говорить")
А теперь реши мою задачку - у меня в винде один sata, один флоппик, один сидиром, один кардридер. логически это диски A, C, D, E, F, G, H, I, J, M. итак, что мне об этом говорит? а ты как я понял хочешь добиться примерно того же в нашей птичке.
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
diamond
KFM не меньше чем KFAR завязан на вид пути. Так что переделка предстоит немалая.
k@sTIg@r
Почему какое-то приложение определяет наличие дисков? В Линукс давно используют автомонтирование. Но зачем плодить лишний код, который, безусловно, будет содержать ошибки?! ИМХО такие вещи доверять уровню приложения просто глупо!
Я не спорю после загрузки можно иметь возможность примонтировать, и размонтировать какой либо логический диск. Но при загрузке это обязательно должно делать ядро!
Если тебя не устраивает то, что я написал, то вот аргумент - скорость. При переносе на уровень приложения загрузка системы замедлится. Если ты будешь оспаривать этот аргумент - значит ты плохо изучил ситуацию.
KFM не меньше чем KFAR завязан на вид пути. Так что переделка предстоит немалая.
k@sTIg@r
Нафига козе баян, а лысому расчестка?Как бы тебе объяснить. То что я скажу растроит многих. Автоматического монтирования не будет! Автоматически будет монтироваться только рамдиск. Вот тут уже есть несколько путей:
1) для продвинутых юзеров. Будет конфиг файл, который будет маунтить такой-то такой-то диск туда-то туда-то.
2) для простых. Будет програмка, которая будет детектить фс на диске (должна быть ф-ция файловой системы) и монтировать автоматически под определенными именами (по типу текущей реализации)
Тут есть много вариантов и нюансов.
Почему какое-то приложение определяет наличие дисков? В Линукс давно используют автомонтирование. Но зачем плодить лишний код, который, безусловно, будет содержать ошибки?! ИМХО такие вещи доверять уровню приложения просто глупо!
Я не спорю после загрузки можно иметь возможность примонтировать, и размонтировать какой либо логический диск. Но при загрузке это обязательно должно делать ядро!
Если тебя не устраивает то, что я написал, то вот аргумент - скорость. При переносе на уровень приложения загрузка системы замедлится. Если ты будешь оспаривать этот аргумент - значит ты плохо изучил ситуацию.
Who is online
Users browsing this forum: No registered users and 1 guest