Page 1 of 1

Низкоуровневая работа с дисками

Posted: Thu Apr 29, 2021 11:56 pm
by rgimad
Здравствуйте всем, недавно в одной из наших бесед зашла речь о создании (или портировании) аналогов программ dd, mkfs и parted для КолибриОС. Наличие подобного софта позволило бы создать пошаговый установщик Колибри на жесткий диск, что было бы полезно широкому кругу пользователей. Изначально прозвучало предложение сделать новую сисфункцию для низкоуровневой работы с дисками (с блоками, разделами и т.д). Однако, потом пришло понимание небезопасности такого решения. Следовательно, возникает идея написать отдельный драйвер для Колибри, предоставляющий такую функциональность. Просьба к разбирающимся в вопросе: расскажите пожалуйста, какие конкретно функции должны быть в API для низкоуровневой работы с дисками?

Re: Низкоуровневая работа с дисками

Posted: Fri Apr 30, 2021 2:47 am
by dunkaist
I don't know how this should be done properly but the most obvious way to implement this functionality seems to be API of open, seek/tell, read/write, close.
Yes, this requires a kind of file descriptors but we need them anyway.

Re: Низкоуровневая работа с дисками

Posted: Fri Apr 30, 2021 6:40 pm
by turbocat
dunkaist wrote:I don't know how this should be done properly but the most obvious way to implement this functionality seems to be API of open, seek/tell, read/write, close.
Yes, this requires a kind of file descriptors but we need them anyway.
То есть вы считаете что нужно реализовать системые вызовы? Или я чего-то не понял...

Re: Низкоуровневая работа с дисками

Posted: Sun May 02, 2021 10:09 pm
by Coldy
Считаю, лучше сделать отдельный драйвер - слишком острые API будут. Соответственно, нужно и как-то защитить возможные последствия от дурака.

Re: Низкоуровневая работа с дисками

Posted: Wed May 05, 2021 1:12 am
by turbocat
Прежде чем писать драйвер, нужно сделать, чтобы он мог использовать эти внутренние функции ядра. Мне кажется что функции для работы с дисками ядро не экспортирует... Или я ошибаюсь?

Re: Низкоуровневая работа с дисками

Posted: Wed May 05, 2021 10:29 am
by Coldy
Для работы с дисками ядро экспортирует только 3 функции DiskAdd, DiskDel и DiskMediaChanged, но для ваших задач это не тот случай. Возможно придется писать свои функции, но на всякий случай посмотрите функции в самих драйверах ФС типа xxx_create_partition.

Re: Низкоуровневая работа с дисками

Posted: Wed May 05, 2021 1:35 pm
by dunkaist
Coldy wrote:Считаю, лучше сделать отдельный драйвер - слишком острые API будут. Соответственно, нужно и как-то защитить возможные последствия от дурака.
How driver is safer than a syscall?
turbocat wrote:То есть вы считаете что нужно реализовать системые вызовы? Или я чего-то не понял...
Yes but file descriptors first. With partition formatting code in userspace.

Re: Низкоуровневая работа с дисками

Posted: Wed May 05, 2021 2:14 pm
by turbocat
Я конечно за системные вызовы.... НО! Чтобы работать с драйвером нужно помучится: загрузить его, а потом юзать его API. А вот системный вызов.... Нечаянно не то значение записал в регист и диск испорчен!

Re: Низкоуровневая работа с дисками

Posted: Wed May 05, 2021 2:21 pm
by Coldy
dunkaist wrote: How driver is safer than a syscall?
Никак. О безопасности должен позаботится разработчик. Драйвер загружается по запросу, зачем эти API постоянно держать в памяти для всех приложений? Они нужны только специфическим приложениям (dd и mkfs), далее они должны быть выгружены. В этом преимущество драйвера.
dunkaist wrote: Yes but file descriptors first. With partition formatting code in userspace.
Тут поддерживаю, но только в том, что дескрипторы надо прикрутить к ФС - сейчас каждый запрос к ФС идет через поиск файла на диске - это замедляет работу с ФС. С дескрипторами будет безусловно быстрее. Но это тема отдельной доработки. Сейчас надо просто держать в голове (на будущее), что появятся функции вроде file_open и file_close, а функции file_read, file_write и т.п. научатся понимать дескрипторы.

Re: Низкоуровневая работа с дисками

Posted: Wed May 05, 2021 3:37 pm
by dunkaist
turbocat wrote:Нечаянно не то значение записал в регист и диск испорчен!
If file descriptors are used, you have to make two mistakes: first call open, then write syscalls.
In big systems this is resolved by user and file permissions and program capabilities.
Coldy wrote:Драйвер загружается по запросу, зачем эти API постоянно держать в памяти для всех приложений? Они нужны только специфическим приложениям (dd и mkfs), далее они должны быть выгружены. В этом преимущество драйвера.
If file descriptors are used, most code will be shared with general file i/o. As a plus, access to files, sockets and some devices will be unified.

Re: Низкоуровневая работа с дисками

Posted: Wed May 05, 2021 4:40 pm
by Coldy
dunkaist, я согласен, что ACL и дескрипторы - это круто и нужно. Но этого всего нет сейчас в Kolibri.
Было бы неплохо хотя бы набросать спецификации всего этого, прототипы функций и т.п., чтобы все разработчики понимали к чему стремиться и учитывали это. Ну и параллельно надо реализовывать все это. Есть кто-то кто сможет двигать этот вопрос с мертвой точки хоть как-то?

Re: Низкоуровневая работа с дисками

Posted: Wed May 05, 2021 6:59 pm
by dunkaist
Coldy wrote:dunkaist, я согласен, что ACL и дескрипторы - это круто и нужно. Но этого всего нет сейчас в Kolibri.
Sometimes features depend on other features, it happens. It is for the topic starter to decide which design to implement.
Coldy wrote:Было бы неплохо хотя бы набросать спецификации всего этого, прототипы функций и т.п., чтобы все разработчики понимали к чему стремиться и учитывали это.
Kernel logic can be partially reused after network functions of the new network stack by hidnplayr. They accept socket IDs which behave just like file descriptors. User API can be anything implementer is aware of, e.g. POSIX-like.
Coldy wrote:Ну и параллельно надо реализовывать все это. Есть кто-то кто сможет двигать этот вопрос с мертвой точки хоть как-то?
The topic starter?

Re: Низкоуровневая работа с дисками

Posted: Sun May 09, 2021 12:10 pm
by Pathoswithin
Сколько занимался дисковой системой, так и не понял, как дескрипторы должны ускорить работу.

Re: Низкоуровневая работа с дисками

Posted: Sun May 09, 2021 3:36 pm
by Coldy
Ниже частный случай для fat_Read (из SVN). При вызове fread (для FAT - fat_Read) каждый раз вызывается hd_find_lfn, которая возвращает direntry и sector. hd_find_lfn имеет некую задержку по своей работе, теперь представь если fread вызывается 100 или 1000 раз в цикле. Очевидно, что direntry и sector можно сохранить один раз (при вызове fopen) и вернуть пользователю некий индекс (handle), скажем из массива открытых файлов. Далее при вызове fread извлекать по индексу direntry и sector и подавать напрямую fat_Read.

Code: Select all

fat_Read:
        call    fat_lock
        call    hd_find_lfn ; return: CF=1 - file not found, eax=error code
			    ;    else CF=0 and edi->direntry, eax=sector
        jc      .notFound
	...

Re: Низкоуровневая работа с дисками

Posted: Mon May 10, 2021 1:04 pm
by Pathoswithin
hd_find_lfn работает медленно только первый раз, далее данные находятся в дисковом кэше и работа кода уже несущественна: сам по себе системный вызов это уже +1000 тактов, так что нечего вызывать fread в цикле.
С другой стороны, вместо дескрипторов можно использовать внутреннее кэширование по текстовому пути к файлу и не менять API. Так же можно реализовать и ограничение доступа.