Динамическое определение дисковых устройств

Kernel architecture questions
  • CleverMouse wrote:Специальное извещение для изменения подключённых дисков не планируется. Изменение подключённых дисков есть частный случай изменения папки в файловой системе, так что на уровне API имеет смысл планировать создание извещения об изменении произвольной папки.
    Имеет смысл подумать, а не создаст ли это проблему - все программы дернутся перечитывать свои директории. Все же разделение по типу было бы уместно - появление нового устройства это все-же логически другое действие, чем переписывание директории на существующем носителе, хоть и со стороны 70 функции выглядит одинаково.
  • Хм. можно еще посмотреть на пример реализации inotify из linux - в части событий изменения каталогов.
  • Насчет ревизии 2140. Текущий алгоритм работы кэша неэффективен для размера более 1 Мб - я проверял это опытным путем в свое время. Хорошим решением было бы использовать хэш-таблицу, но к сожалению я не осилил алгоритм (видимо сказалось отсутствие у меня высшего образования).
  • такое впечатление, после прочитанного, что тема должна была быть именно
    CleverMouse wrote:нового API для работы с дисковыми устройствами
    а у же в нем инкапсулируется
    CleverMouse wrote:Динамическое определение дисковых устройств
    и уже, как подпункт, как часть API... Так?
    Или же ввиду осознания всего объема работ вцелом по данному аспекту, работа, как бы начата со средины и с того, что уже сложилось, кристаллизовалось, назрело или вызрело и "лежит на поверхности" сознания разработчика, ясно и четко видно и представляется логически и блочно правильно?
    Все это хорошо, безспорно или даже отлично, но!
    CleverMouse wrote:Начальную стадию реализации API уже можно увидеть на svn вместе с описанием API
    тут, как бы для автора всегда все ясно и четко и тем более где лежит, что в изложенном важно, а что нет... а конкретнее можно, как для людей возможно только впервые появившиеся на горизонте? (пожелание)
    Ведь уместно: точно где что читать(ссылка, путь) и есть ли будут ли блок-схемы нового, особенно в разрезе понятий драйверная модель (или новая драйверная модель?).
    Что то уже мелькало тут рядом... и вообще, чтобы к сему привыкали в будующем чтоли, если это так.
    Ведь все туда идет (катится :wink: ), так?
    Смотри, Ваши споры/творчество с Serge тоже немалый позитив, как процесс развития, но раз это публично, значит Вы не покрасоваться хотите,
    а логично, как бы участия, понимания общественности,
    а для этого нужно переводить с Вашего "модернизированного китайского" хотя бы глобальные сущности для простых смертных.
    Подавать материал в "съедобном виде" (НЕ имеется ввиду углубленная детализация).
    Тянуть это на потом, "когда родится все" - не годится.
    Это, конечно если для людей и для участия людей делается.
    Иначе, как показывает жизнь форума, ветку ведут 1-2 чела и мило там себе общаются. Такое и в привате ведь вполне сойдет.
    Я могу понять лимит суток, занятость, азарт озарения и вдохновения, но можно ли хотябы в недалеком будующем рассчитывать, на доступную для многих людей подачу материала (особенно для сравнительного впечатления, оценки изменений в структуризации)
    хотябы в виде аналога или подобия такой убогости вида, типа эта Visioлизация:
    viewtopic.php?f=35&t=1381&start=255
    визуализация колоссальная психологическая вещь в восприятии сути.
    Спасибо!
  • Mario, я и так уже просрочила обещанный срок реализации USB - из-за излишней ориентации на драйвера аппаратной части и недооценки объёмов переделывания ядра, - и если я начну сейчас вносить нетривиальные изменения в работающие части, я просто в этом увязну. В данный момент я решаю задачу "улучшить уровень работы с дисковыми устройствами и не ухудшить прочие уровни". Так что кэш остаётся таким, какой он есть сейчас. Также, например, остаются спорные фичи "выдавать ошибку записи при чтении" и "форсировать сброс изменённых данных на диск после каждой дисковой операции" - просто потому, что они не имеют отношения к уровню дисковых устройств. Если хочется пообсуждать их, можешь создать отдельную тему, участия в которой я не гарантирую.

    VaStaNi, да, тема была бы "новое API для работы с дисковыми устройствами", если бы тут были люди, которых интересовал бы именно этот аспект. Но поскольку активных ядерщиков двое и один из них в интересе к этой теме замечен не был, то сообщение ориентировано на прикладных программистов.

    Работа начата откуда надо и закончится где надо. Работа включает в себя создание нормальных условий для написания драйверов дисков. Работа не включает в себя переписывание всей дисковой подсистемы.

    Описание API лежит в очевидном месте svn://kolibrios.org/kernel/trunk/docs/drivers_api.txt и написано конкретнее некуда. В том числе оно должно быть понятно и для людей, впервые появившихся на горизонте, - конечно, в предположении, что эти люди способны осилить сотню строчек текста.

    Новой драйверной модели не планируется. Код для работы с драйверами, написанный Serge, выполняет свои функции.

    Блок-схем не планируется. Человеку, пишущему драйвер, можно подумать, таких тут больше одной, нужны не они, а описание API и, возможно, примеры программирования. Для человека, интересующегося устройством ядра, я оставляю достаточно подробные комментарии. Комментарии включают как общий обзор структур и функций без деталей, так и детали происходящего по ходу выполнения кода. Если появятся люди, которые убедительно скажут "мы хотим видеть общий обзор функций, нам лень смотреть файлы, но мы полезны для проекта, правда-правда", то комментарии к функциям вообще можно выдёргивать в отдельный файл при автосборке, если, конечно, договориться, что именно считать функциями.

    Если вы не в состоянии воспринимать текст, а можете только смотреть на картинки, нарисуйте сами и любуйтесь: прямоугольник с надписью "disk" - если точность превыше краткости, то "block device", если вас не интересует возможность понимания нерусскоязычными программистами, то "диск"/"блочное устройство"; внутри меньший прямоугольник с надписью "media"/"носитель"; вниз линию к словам "device driver"/"драйвер устройства", вверх несколько линий к нескольким прямоугольникам "partition"/"раздел", от которых ещё линии к словам "other layers"/"прочие уровни". Где именно следует разместить дисковый кэш так, чтобы было видно, что он существует, что он опционален, что операции с разделами идут через кэш, но что логически разделы относятся к диску, а не к кэшу, вам придётся думать самому - я это описываю текстом.
    Сделаем мир лучше!
  • CleverMouse wrote:Mario, я и так уже просрочила обещанный срок реализации USB - из-за излишней ориентации на драйвера аппаратной части и недооценки объёмов переделывания ядра, - и если я начну сейчас вносить нетривиальные изменения в работающие части, я просто в этом увязну.
    Можно подумать, что кто-то ставит тебе рамки и сроки, кроме тебя самой. Работа свободная и творческая, если конечно кто-то не заинтересовал тебя каким либо деловым предложением. Я же просто изложил суть, которая была в теме, которая была снесена мной-же года 3-4 назад, во время разборок на форуме и прочитать соответственно изложенное там ты не можешь. Согласен, что работа которую ты делаешь очень объемная - я это ценю и буду по мере возможности помогать, хотя бы грамотным тестированием.
  • ф-ция TimerHS даёт возможность зарегистрировать и 10 и 20 таймеров. Думаю что это может выльется в через-чур большую нагрузку на ядро. Лучше перенести эту нагрузку на драйвер и сделать только одну ф-цию - RegisterNextSingleTimer, которая автоматически будет отменять предыдущий таймер. Как только таймер сработает драйвер может сразу же зарегистрировать другой таймер.
    Самая большая проблема с кучей таймеров это то что они запросто могут прийти с сильным запозданием если назначены через короткие промежутки времени. В то время как с RegisterNextSingleTimer драйвер может проверить время и передумать регистрацию нового таймера.

    Можно сделать возможность регистрации одного и только одного переодического, и одного и только одного единовременного..

    Что такое "HS" в названиях ф-ций и каким образом вы считаете что это понятно окружающим?
    ; void close(void* userdata);
    ; Optional.
    ; The last function that is called for the given disk. The kernel calls it when
    ; the kernel has finished all operations with the disk and it is safe to free
    ; all driver-specific data identified by 'userdata'.
    Что вы предлагаете ядру делать таково с диском что после этого нужна отдельная ф-ция. Ядро ничего о диске не знает. Может вы имели ввиду приказ драйверу "disableDisk" ?
  • Сначала не забудте почитать kernel/trunk/docs/drivers_api.txt
    ReportDiskState(DISKFUNC* functions, int diskID, int stateFlags, void* more, void* more2)
    ;===============================================
    ; This function is called by driver to indicate current state of some device
    ; This function is exported by kernel.
    ;-------------------------------------------------------------------------------------
    "diskID" is supplied by driver every new unique disk
    ;-------------------------------------------------------------------------------------
    ; if "functions" !=0 then driver wishes to update function pointers.
    ; if this is 1st call with "functions" != 0 then new disk is automatically added given that diskID does not yet exist for this driver in kernel databse. Only one disk with same diskID(for this driver) can be added othrewise report error.
    ; "functions" variable is allowed to be non-zero on every ReportDiskState call to ease up life of driver programmer.
    ;-------------------------------------------------------------------------------------
    ; "stateFlags" - every bit in this bitmask indicates some different state that currently
    ; applies to the diskID (DELETED disk, SUSPENDED disk, BUSY disk, EJECTED media, ...)
    ;-------------------------------------------------------------------------------------
    ; "more" & "more2" are different depending on stateFlags


    SetDiskState(int diskID, int action, int optionalFlags)
    ;==============================================
    ; Executed by kernel to issure desired command to disk driver
    ; This function is exported by driver.
    ;-------------------------------------------------------------------------------------
    ; "action" var can be set to DISK_DISABLE, DISK_SUSPEND, MEDIA_REMOVE, MEDIA_INFO... more can be added later without changing the API.
    ; user can choose these actions thru corresponding GUI of device explorer window or kernel issues them on its own
    ;
    ;
    ;
    ; Optionally DISKFUNC struct can contain pointer(s) (like "void* userdata") that get passed
    ; to all/some/selective callbacks.
  • ilya
    Хорошее предложение. Есть ещё замечания:
    1.Не надо забывать про управление пританием для мобильных устройств. SetDiskState() просто необходима.
    2.Нужна функция GetDiskState() для получения дополнительной информации от диска - SMART и прочая фигня. Эта функция может заменить querymedia().
    Таким образом будет полный набор функций:
    GetDiskState и SetDiskState - инициатор ядро
    и ReportDiskState - инициатор драйвер
    3. Я считаю что имя диску должно назначать ядро, а не драйвер. Иначе непонятно как избежать коллизии имён.
  • Serge wrote:2.Нужна функция GetDiskState() для получения дополнительной информации от диска - SMART и прочая фигня. Эта функция может заменить querymedia()
    Судя по названиям, это всё же разные вещи. GetDiskState -- как бы текущее состояние устройства, а querymedia -- его статические характеристики. Есть ли смысл объединять, надо подумать (не мне, естественно).
    3. Я считаю что имя диску должно назначать ядро, а не драйвер. Иначе непонятно как избежать коллизии имён.
    С точки зрения здравого смысла, драйверы вообще не должны заботиться об именах устройств: они им не нужны, они требуются системе для поиска драйвера, обслуживающего то или иное устройство...
  • ilya, одному драйверу может оказаться полезным устанавливать несколько таймеров - например, к компьютеру запросто могут быть подключены две USB-клавиатуры, для каждой из которых нужен отдельный таймер автоповтора. То, что таймеры "могут прийти с сильным запозданием, если назначены через короткие промежутки времени" - это фича: лучше поздно, чем никогда. Если драйвер действительно хочет создавать только один таймер в каждый промежуток времени, он легко может сделать это и сейчас: создавать только однократные таймеры - с interval = 0 - и в конце таймерной функции добавлять очередной таймер. То есть гипотетическая RegisterNextSingleTimer - это просто ограниченная TimerHS с interval = 0 и дополнительным спорным ограничением "один таймер на драйвер".

    HS = hundredths of seconds, единицы измерения времени в аргументах.
    Сделаем мир лучше!
  • ilya, функция close предназначена для драйвера, она не обязана делать что бы то ни было с диском. При обнаружении диска драйвер, как правило, выделяет для работы с ним какие-то ресурсы - например, хотя бы память под хранение связанных с ним служебных данных. Функция close вызывается последней, так что в ней драйвер может эти ресурсы освободить.

    ReportDiskState слишком перегружена - хотя бы неопределённые "void* more" и "void* more2" это доказывают. Незачем постоянно менять функции DISKFUNC, их лучше задать один раз при добавлении диска, а для остальных операций это совершенно избыточно. Ясно, что при различных значениях stateFlags операции будут совершенно различными, так что незачем искусственно объединять их в одну функцию.

    Serge, GetDiskState/SetDiskState можно добавить в любой момент, когда будет более ясно, что именно от них требуется и кто именно будет требовать. querymedia заменять вряд ли стоит, хотя бы потому, что размер сектора и ёмкость блочное устройство знать обязано, а SMART и прочую фигню устройство может и не поддерживать. Тем не менее, при особом желании можно и её расширить, определив дополнительные биты в Flags как символ "ядро запрашивает дополнительную информацию"/"драйвер возвратил дополнительную информацию".

    Имя диска в текущей Колибри определяется по типу устройства, и это вроде как соответствует идеологии Колибри "меньше промежуточных слоёв абстракции". С этой точки зрения, здравый смысл как раз подсказывает, что имя должно определяться драйвером, и отсюда же отсутствие конфликтов имён - разные драйвера отвечают за разные типы устройств, а в пределах своего типа обеспечить уникальность драйвер вполне может.

    Для меня не имеет существенного значения, откуда именно ядро будет узнавать имя диска. Если есть вариант, при котором ядро может узнать существующие имена /hd0,/cd1,/bd2,/rd,/fd не из драйвера и эту схему ты считаешь более логичной, рассказывай. Если ты считаешь желательным вообще изменить текущую схему именования, то это изменение даже не прикладного уровня, а вообще видно на пользовательском уровне, так что должен быть опрос - отдельный от этой темы - с конкретными предложениями и разъяснениями.
    Сделаем мир лучше!
  • Хотя DiskMediaChanged и, возможно, DiskDel можно и заменить на что-нибудь в духе ReportDiskState, только менее нагруженную. Но DiskAdd лучше оставить как есть.
    Сделаем мир лучше!
  • CleverMouse wrote:ilya, одному драйверу может оказаться полезным устанавливать несколько таймеров
    Совершенно верно. Даже в таком простом на первый взгляд драйвере, как UART (на ПК более известен как COM-порт) мне понадобилась возможность иметь два таймера: один для таймаута вывода и второй -- для таймаута ввода (эти две операции могут выполняться независимо). Опасения же насчёт нагрузки на ядро необоснованны: достаточно лишь выстраивать таймеры в очередь в порядке времени их срабатывания, что несложно. Если ожидается действительно большое количество одновременно активных таймеров (скажем, больше сотни), можно эту очередь организовать в виде двоичного дерева, чтобы убыстрить процедуру добавления нового таймера (фактически -- поиска места под него).
    Имя диска в текущей Колибри определяется по типу устройства... С этой точки зрения, здравый смысл как раз подсказывает, что имя должно определяться драйвером, и отсюда же отсутствие конфликтов имён - разные драйвера отвечают за разные типы устройств...
    Тут просто возникает проблема такого рода. Как известно, драйвер обслуживает конкретный тип устройства и действительно может в теории безконфликтно обозвать все устройства этого типа. Однако имена одного вида и одинакового функционального назначения (например, имена жёстких дисков) могут, в принципе, соответствовать физически сильно отличающимся устройствам, которые обслуживаются разными драйверами (скажем, один жёсткий диск прицеплен через древний PATA, другой -- через AHCI, третий -- SCSI, а четвёртый на самом деле вообще сетевым является). Тут, мне кажется, лишь два варианта: либо давать подобным дискам принципиально разные имена, либо позволять их назначать (по крайней мере, частично) самой системе. Например, драйвер идентифицирует себя как драйвер жёсткого диска, и при подключении нового диска к этому драйверу ОС сгенерит новое имя вида HDn (ну или какое там принято). Пользователю обычно удобней иметь единообразные имена независимо от реального типа устройства (поскольку в подавляющем большинстве случаев важны не тонкие технические нюансы, а общее назначение устройства), хотя иногда это мешает. В общем, тут стоит подумать и, возможно, устроить голосование (лично я от участия в официальном голосовании воздержусь, поскольку к разработке и даже пользованию КОС отношения не имею, а, так сказать, выступаю в роли внештатного флудераста, однако моё мнение -- генерить имена системой).
  • Who is online

    Users browsing this forum: No registered users and 5 guests