Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Aug 03, 2021 12:46 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 15 posts ] 
Author Message
PostPosted: Thu Apr 29, 2021 11:56 pm 
Offline
User avatar

Joined: Mon Apr 06, 2020 1:09 pm
Posts: 106
Здравствуйте всем, недавно в одной из наших бесед зашла речь о создании (или портировании) аналогов программ dd, mkfs и parted для КолибриОС. Наличие подобного софта позволило бы создать пошаговый установщик Колибри на жесткий диск, что было бы полезно широкому кругу пользователей. Изначально прозвучало предложение сделать новую сисфункцию для низкоуровневой работы с дисками (с блоками, разделами и т.д). Однако, потом пришло понимание небезопасности такого решения. Следовательно, возникает идея написать отдельный драйвер для Колибри, предоставляющий такую функциональность. Просьба к разбирающимся в вопросе: расскажите пожалуйста, какие конкретно функции должны быть в API для низкоуровневой работы с дисками?

_________________
The best way to predict the future is to create it.


Top
   
PostPosted: Fri Apr 30, 2021 2:47 am 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 660
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.


Top
   
PostPosted: Fri Apr 30, 2021 6:40 pm 
Offline
User avatar

Joined: Thu Jun 25, 2020 1:14 am
Posts: 82
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.


То есть вы считаете что нужно реализовать системые вызовы? Или я чего-то не понял...

_________________
Gentlemen, has it occurred to you to use libc.obj instead of "reinventing the wheel"?


Top
   
PostPosted: Sun May 02, 2021 10:09 pm 
Offline

Joined: Tue Apr 09, 2019 8:57 pm
Posts: 58
Считаю, лучше сделать отдельный драйвер - слишком острые API будут. Соответственно, нужно и как-то защитить возможные последствия от дурака.


Top
   
PostPosted: Wed May 05, 2021 1:12 am 
Offline
User avatar

Joined: Thu Jun 25, 2020 1:14 am
Posts: 82
Прежде чем писать драйвер, нужно сделать, чтобы он мог использовать эти внутренние функции ядра. Мне кажется что функции для работы с дисками ядро не экспортирует... Или я ошибаюсь?

_________________
Gentlemen, has it occurred to you to use libc.obj instead of "reinventing the wheel"?


Top
   
PostPosted: Wed May 05, 2021 10:29 am 
Offline

Joined: Tue Apr 09, 2019 8:57 pm
Posts: 58
Для работы с дисками ядро экспортирует только 3 функции DiskAdd, DiskDel и DiskMediaChanged, но для ваших задач это не тот случай. Возможно придется писать свои функции, но на всякий случай посмотрите функции в самих драйверах ФС типа xxx_create_partition.


Top
   
PostPosted: Wed May 05, 2021 1:35 pm 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 660
Coldy wrote:
Считаю, лучше сделать отдельный драйвер - слишком острые API будут. Соответственно, нужно и как-то защитить возможные последствия от дурака.

How driver is safer than a syscall?

turbocat wrote:
То есть вы считаете что нужно реализовать системые вызовы? Или я чего-то не понял...

Yes but file descriptors first. With partition formatting code in userspace.


Top
   
PostPosted: Wed May 05, 2021 2:14 pm 
Offline
User avatar

Joined: Thu Jun 25, 2020 1:14 am
Posts: 82
Я конечно за системные вызовы.... НО! Чтобы работать с драйвером нужно помучится: загрузить его, а потом юзать его API. А вот системный вызов.... Нечаянно не то значение записал в регист и диск испорчен!

_________________
Gentlemen, has it occurred to you to use libc.obj instead of "reinventing the wheel"?


Top
   
PostPosted: Wed May 05, 2021 2:21 pm 
Offline

Joined: Tue Apr 09, 2019 8:57 pm
Posts: 58
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 и т.п. научатся понимать дескрипторы.


Top
   
PostPosted: Wed May 05, 2021 3:37 pm 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 660
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.


Top
   
PostPosted: Wed May 05, 2021 4:40 pm 
Offline

Joined: Tue Apr 09, 2019 8:57 pm
Posts: 58
dunkaist, я согласен, что ACL и дескрипторы - это круто и нужно. Но этого всего нет сейчас в Kolibri.
Было бы неплохо хотя бы набросать спецификации всего этого, прототипы функций и т.п., чтобы все разработчики понимали к чему стремиться и учитывали это. Ну и параллельно надо реализовывать все это. Есть кто-то кто сможет двигать этот вопрос с мертвой точки хоть как-то?


Top
   
PostPosted: Wed May 05, 2021 6:59 pm 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 660
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?


Top
   
PostPosted: Sun May 09, 2021 12:10 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1282
Сколько занимался дисковой системой, так и не понял, как дескрипторы должны ускорить работу.


Top
   
PostPosted: Sun May 09, 2021 3:36 pm 
Offline

Joined: Tue Apr 09, 2019 8:57 pm
Posts: 58
Ниже частный случай для 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:
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
   ...


Top
   
PostPosted: Mon May 10, 2021 1:04 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1282
hd_find_lfn работает медленно только первый раз, далее данные находятся в дисковом кэше и работа кода уже несущественна: сам по себе системный вызов это уже +1000 тактов, так что нечего вызывать fread в цикле.
С другой стороны, вместо дескрипторов можно использовать внутреннее кэширование по текстовому пути к файлу и не менять API. Так же можно реализовать и ограничение доступа.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 15 posts ] 

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited