Serial ATA

Drive subsystem, filesystem drivers
  • 1. А что будет раньше. VFS или драйвера и соответствующее определение устройств?

    3. Ну перемещение, например, всех приведенных реализаций (образы, сеть) в ядро еще сильнее снизит надежность. В конечном итоге просто появится специальный прокси-драйвер для таких задач. Возможно сейчас не стоит сильно парться такой задачей, но предусмотреть её решение в будущем все же стоит. Например позволить драйверу обслуживать несколько устройств, а не сторого одно.

    ..bw
  • bw

    3. Не факт. Сейчас vfs и все драйверы работают в режиме ядра. Неправильный адрес DMA вынесет систему в любом случае независимо от ring0 или ring3.
  • В общем видится мне, нужен такой интерфейс:

    int AddRAWDrive(sname, id, blocksize, fread, fwrite = null, umount = null);
    sname - символическое имя класса укстройств ("hd", "mb", "rd", etc), думаю за каждым драйвером можно закпепить свое имя ATA - "hd", ATAPI - "cd", Floppy - "fd", RAM drive - "rd", SATA - "sd", etc
    id - номер устройства (видимо нужно что то типа GetNextID(sname), или что то думать, если хочется что бы не слетало разименование при добавлении нового диска)
    fread(block, count, buffer), fwrite(...) - чтение/запись блока, для устройств не поддерживающих запись fwrite = null
    blocksize - размер блока (кластера...) в байтах
    umount - функция отключения

    возвращает код ошибки (всё нормуль, id занят, неверные параметры...)

    это интерфейс можно пускать и в ring3 с сообветствующей оберткой

    поверх этого строятся разделы (ссылка на устройство, начальный/конечны блок, функция отключения), поверх разделов драйвера фаловых систем. отключение каскадное (фс -> разделы -> устройства)

    Про кеширование, есть разные варианты:
    1) универсальное, работающее прозрачно для драйверов (реагирует на вызовы fread, fwrite драйвера устройства).
    2) реализуемое драйверами устройств, сязано с конструктивной спецификой различных устройств (размеры блоков, зависимость скорости записи/чтения от количества блоков, встроенное кеширование...)
    В идеале оба способа, по выбору драйвера.
  • Ghost

    Драйверу не надо самому назначать имя. Оно ему вообще ни к чему. Это должна делать файловая система.
    Драйвер должен только найти устройство и сообщить о нём файловой системе. Остальное его не касается.

    Я думаю использовать для устройств логические номера.
    Допустим в системе будет максимум 32 устройства одновременно.
    Указатели на устройства заносятся в массив. Младшие пять бит логического номера будут индексом в массиве, старшие - порядковый номер устройства. Тогда логическиё номера будут выглядеть 0х0020,
    0х0041, 0х0062 и т.д.
  • Ещё есть некоторые проблемы из-за того, что если какой-то BIOS-диск совпадает с видимым ядру, то кэши файловой системы для двух дисков должны также совпадать, так что нужно ещё уметь определять такие совпадения. Вероятно, лучше всего, чтобы конфигурация устройства, возвращаемая драйвером, включала информацию, достаточную для выделения базового порта устройства (в том смысле, в котором его понимает BIOS для функции 13.48) и различения вещей типа primary/slave.
    Ушёл к умным, знающим и культурным людям.
  • Синхронизация кешей будет кошмаром. Может отключать BIOS-диск или драйвер если оба видны ядру ?
  • Синхронизация кэшей проблемой не является, когда кэш физически один и тот же для двух устройств. Но определять такое в любом случае надо.
    Разве что нужно внимательнее следить за освобождением памяти под кэш при удалении устройств, но это технический нетрудный момент.
  • А как сейчас решается проблема ?
  • Сейчас код обработки BIOS-дисков знает, что из жёстких дисков ядро поддерживает только IDE - primary master/slave с базовым портом 1F0h и secondary master/slave с базовым портом 170h, и при сканировании видимых в BIOS дисков проверяет, не имеет ли очередной диск такой базовый адрес (через int 13h/ah=48h), и если имеет, то запоминает в таблице дисков, что у него такой-то идентификатор по мнению ядра - от 0 до 3 (/hd0 - /hd3). Позднее при создании кэшей для диска, не связанного с IDE, выделяется отдельный кэш, а для диска, связанного с IDE, просто хранится соответствие и запросы к кэшу перенаправляются на кэш для IDE.
  • Serge
    Если не драйвер будет говорить имя ("hd", "mb", "rd"), как его даст файловая система???
  • diamond

    Если SATA или PATA в native mode там будут другие базовые адреса. А есть способ получить серийный номер устройства через биос ?

    Ghost
    Ну не обязательно в явном виде. Система запрашивает параметры устройства, получает тип устройства, назначает имя по своему разумению и монтирует с этим именем. Ещё можно давать каждому устройству имя на PCI шине. У меня получится IDE D31:F1:Primary:Master, CD D31:F1:Secondary:Master, SATA D31:F2:Primary:Master. У sata нет деления на master и slave, но для совместимости можно считать что там primary master и secondary master.
  • получает тип устройства - тогда типы устройств нужно ограничивать и при добавлении нового типа прейдется править код выдачи имени в части ФС
    имя на PCI шине - с RAM дисками что тогда делать? или скажем USB (на одной PCI шине их может быть много)?

    Мне кажется лучше пусть его дает драйвер (он то лучше знает что это за устройство), драйвер говорит, хочу быть "hd", система говорит, Ok, есть свободный номер 2. Создается устройство /hd2/, далее прослойка смотрит есть ли разделы, говорит О! есть два раздела, с такими то линейными диапазонами адресов, появляются /hd2/0, /hd2/1, далее на каждом разделе опредляется ФС, все.

    VFS понятия не имеет про диски, у не все строится от корня. Происходит попытка чтения файла /hd2/0/test.txt, vfs разбирает первые два участка пути, находит описание в таблице, дергает процедуру чтения файла для заданной ФС, передает ей указатель на структуру с процедурами чтения с устройства, и смещением раздела от начала (при желании можно ввести прослойка для преобразования лакальной и глобальной нумерации блоков, тогда ФС всегда считает что раздел начинается с нулевого блока. Но это спорно)...
  • Ghost

    А если драйвер скажет "хочу быть Васей Пупкиным" ?
    Типов устройств не так много. С usb нет проблем - адрес контроллера на шине PCI + 7 бит usb адрес устройства. Пусть это будет стодвадцатисемиканальный ata контроллер. Для не-PCI устройств сделать специальные коды. Такая адресация для внутрених систем а не для того чтобы пугать юзеров. Например если надо принудительно назначить имя устройства через файл конфигурации.
  • Serge
    В native mode ядро этих дисков и не увидит, так что всё в порядке. Серийный номер узнать вроде нельзя. В EDD 3.0 теоретически выдаётся информация о шине и физическом положении устройства на шине, но реально даже современные BIOSы не всегда это поддерживают.
  • Who is online

    Users browsing this forum: No registered users and 2 guests