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

Drive subsystem, filesystem drivers
  • 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.
  • 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.
    То есть вы считаете что нужно реализовать системые вызовы? Или я чего-то не понял...
    Изобретайте колёса каждый раз, когда хотите написать новую программу.
  • Считаю, лучше сделать отдельный драйвер - слишком острые API будут. Соответственно, нужно и как-то защитить возможные последствия от дурака.
  • Прежде чем писать драйвер, нужно сделать, чтобы он мог использовать эти внутренние функции ядра. Мне кажется что функции для работы с дисками ядро не экспортирует... Или я ошибаюсь?
    Изобретайте колёса каждый раз, когда хотите написать новую программу.
  • Для работы с дисками ядро экспортирует только 3 функции DiskAdd, DiskDel и DiskMediaChanged, но для ваших задач это не тот случай. Возможно придется писать свои функции, но на всякий случай посмотрите функции в самих драйверах ФС типа xxx_create_partition.
  • Coldy wrote:Считаю, лучше сделать отдельный драйвер - слишком острые API будут. Соответственно, нужно и как-то защитить возможные последствия от дурака.
    How driver is safer than a syscall?
    turbocat wrote:То есть вы считаете что нужно реализовать системые вызовы? Или я чего-то не понял...
    Yes but file descriptors first. With partition formatting code in userspace.
  • Я конечно за системные вызовы.... НО! Чтобы работать с драйвером нужно помучится: загрузить его, а потом юзать его API. А вот системный вызов.... Нечаянно не то значение записал в регист и диск испорчен!
    Изобретайте колёса каждый раз, когда хотите написать новую программу.
  • 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 и т.п. научатся понимать дескрипторы.
  • 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.
  • dunkaist, я согласен, что ACL и дескрипторы - это круто и нужно. Но этого всего нет сейчас в Kolibri.
    Было бы неплохо хотя бы набросать спецификации всего этого, прототипы функций и т.п., чтобы все разработчики понимали к чему стремиться и учитывали это. Ну и параллельно надо реализовывать все это. Есть кто-то кто сможет двигать этот вопрос с мертвой точки хоть как-то?
  • 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?
  • Сколько занимался дисковой системой, так и не понял, как дескрипторы должны ускорить работу.
  • Ниже частный случай для 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
    	...
    
  • hd_find_lfn работает медленно только первый раз, далее данные находятся в дисковом кэше и работа кода уже несущественна: сам по себе системный вызов это уже +1000 тактов, так что нечего вызывать fread в цикле.
    С другой стороны, вместо дескрипторов можно использовать внутреннее кэширование по текстовому пути к файлу и не менять API. Так же можно реализовать и ограничение доступа.
  • Who is online

    Users browsing this forum: No registered users and 2 guests