Board.KolibriOS.org

Эта тема предназначена для обсуждения нового API для работы с дисковыми устройствами. Преимущества над текущей схемой следующие:
* Возможность динамического подключения и отключения устройств.
* Разделение собственно дисковых операций, типа чтения/записи, и более высокоуровневых, уровня файловых систем.
* Возможность вынесения собственно дисковых операций в отдельный драйвер, не знающий ничего об уровне файловых систем.
* Отсутствие длительных глобальных блокировок типа текущего [hd1_status], который блокирует вообще все операции со всеми ATA-дисками, CD/DVD и BIOS-эмуляции. В новой схеме есть одна глобальная блокировка, охраняющая виртуальную корневую папку; после того, как стало понятно, с каким диском хочет работать файловая операция, в глобальных блокировках нет нужды. Случай двух зависимых устройств типа /hd0 и /hd1, с которыми нельзя работать одновременно, может и должен разруливать драйвер этих устройств.

Начальную стадию реализации API уже можно увидеть на svn вместе с описанием API. Дальнейший план действий таков:
1. Модификация кода файловых систем так, чтобы они работали с дисковыми устройствами, подключёнными через новое API. На первом этапе, вероятно, дело ограничится FAT32. При этом код сохранит возможность работать с дисковыми устройствами, реализованными в текущей схеме.
2. Подключение USB-хранителей информации - в первую очередь флешек, хотя USB-контроллеры дискет и CD отличаются не слишком существенно в плане программирования - через новое API. Тестирование и отладка обоих сторон интерфейса - драйверной и ядерной.
3. Перевод текущих дисковых устройств на новую схему. Это позволит, например, из двух реализаций FAT12, для рамдиска и для дискет, оставить одну, а также получить рамдиск с любой файловой системой.

Функции 18.11 и 58 не будут работать для новых устройств на втором этапе и будут удалены на третьем. Заодно умрут функции 21.7, 21.8. Вместо функции 18.11.1 уже сейчас следует использовать чтение виртуальной корневой папки функцией 70.1. Вместо функций 18.11.2 и 58.15 будет подфункция функции 70, возвращающая информацию о файловой системе. Вместо 58.0 уже сейчас следует использовать 70.0, вместо 58.8 будет ещё одна подфункция функции 70, включаемая функцией 21.11 и работающая даже для нераспознанных файловых систем.

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

_________________
Сделаем мир лучше!

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

Хм. можно еще посмотреть на пример реализации inotify из linux - в части событий изменения каталогов.

Насчет ревизии 2140. Текущий алгоритм работы кэша неэффективен для размера более 1 Мб - я проверял это опытным путем в свое время. Хорошим решением было бы использовать хэш-таблицу, но к сожалению я не осилил алгоритм (видимо сказалось отсутствие у меня высшего образования).

такое впечатление, после прочитанного, что тема должна была быть именноа у же в нем инкапсулируется
и уже, как подпункт, как часть API... Так?
Или же ввиду осознания всего объема работ вцелом по данному аспекту, работа, как бы начата со средины и с того, что уже сложилось, кристаллизовалось, назрело или вызрело и "лежит на поверхности" сознания разработчика, ясно и четко видно и представляется логически и блочно правильно?
Все это хорошо, безспорно или даже отлично, но!
тут, как бы для автора всегда все ясно и четко и тем более где лежит, что в изложенном важно, а что нет... а конкретнее можно, как для людей возможно только впервые появившиеся на горизонте? (пожелание)
Ведь уместно: точно где что читать(ссылка, путь) и есть ли будут ли блок-схемы нового, особенно в разрезе понятий драйверная модель (или новая драйверная модель?).
Что то уже мелькало тут рядом... и вообще, чтобы к сему привыкали в будующем чтоли, если это так.
Ведь все туда идет (катится ), так?
Смотри, Ваши споры/творчество с Serge тоже немалый позитив, как процесс развития, но раз это публично, значит Вы не покрасоваться хотите,
а логично, как бы участия, понимания общественности,
а для этого нужно переводить с Вашего "модернизированного китайского" хотя бы глобальные сущности для простых смертных.
Подавать материал в "съедобном виде" (НЕ имеется ввиду углубленная детализация).
Тянуть это на потом, "когда родится все" - не годится.
Это, конечно если для людей и для участия людей делается.
Иначе, как показывает жизнь форума, ветку ведут 1-2 чела и мило там себе общаются. Такое и в привате ведь вполне сойдет.
Я могу понять лимит суток, занятость, азарт озарения и вдохновения, но можно ли хотябы в недалеком будующем рассчитывать, на доступную для многих людей подачу материала (особенно для сравнительного впечатления, оценки изменений в структуризации)
хотябы в виде аналога или подобия такой убогости вида, типа эта Visioлизация:
http://board.kolibrios.org/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"/"прочие уровни". Где именно следует разместить дисковый кэш так, чтобы было видно, что он существует, что он опционален, что операции с разделами идут через кэш, но что логически разделы относятся к диску, а не к кэшу, вам придётся думать самому - я это описываю текстом.

_________________
Сделаем мир лучше!

Можно подумать, что кто-то ставит тебе рамки и сроки, кроме тебя самой. Работа свободная и творческая, если конечно кто-то не заинтересовал тебя каким либо деловым предложением. Я же просто изложил суть, которая была в теме, которая была снесена мной-же года 3-4 назад, во время разборок на форуме и прочитать соответственно изложенное там ты не можешь. Согласен, что работа которую ты делаешь очень объемная - я это ценю и буду по мере возможности помогать, хотя бы грамотным тестированием.

ф-ция TimerHS даёт возможность зарегистрировать и 10 и 20 таймеров. Думаю что это может выльется в через-чур большую нагрузку на ядро. Лучше перенести эту нагрузку на драйвер и сделать только одну ф-цию - RegisterNextSingleTimer, которая автоматически будет отменять предыдущий таймер. Как только таймер сработает драйвер может сразу же зарегистрировать другой таймер.
Самая большая проблема с кучей таймеров это то что они запросто могут прийти с сильным запозданием если назначены через короткие промежутки времени. В то время как с RegisterNextSingleTimer драйвер может проверить время и передумать регистрацию нового таймера.

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

Что такое "HS" в названиях ф-ций и каким образом вы считаете что это понятно окружающим?

Что вы предлагаете ядру делать таково с диском что после этого нужна отдельная ф-ция. Ядро ничего о диске не знает. Может вы имели ввиду приказ драйверу "disableDisk" ?

Сначала не забудте почитать kernel/trunk/docs/drivers_api.txt

ilya
Хорошее предложение. Есть ещё замечания:
1.Не надо забывать про управление пританием для мобильных устройств. SetDiskState() просто необходима.
2.Нужна функция GetDiskState() для получения дополнительной информации от диска - SMART и прочая фигня. Эта функция может заменить querymedia().
Таким образом будет полный набор функций:
GetDiskState и SetDiskState - инициатор ядро
и ReportDiskState - инициатор драйвер
3. Я считаю что имя диску должно назначать ядро, а не драйвер. Иначе непонятно как избежать коллизии имён.

Судя по названиям, это всё же разные вещи. GetDiskState -- как бы текущее состояние устройства, а querymedia -- его статические характеристики. Есть ли смысл объединять, надо подумать (не мне, естественно).



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

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 лучше оставить как есть.

_________________
Сделаем мир лучше!

Совершенно верно. Даже в таком простом на первый взгляд драйвере, как UART (на ПК более известен как COM-порт) мне понадобилась возможность иметь два таймера: один для таймаута вывода и второй -- для таймаута ввода (эти две операции могут выполняться независимо). Опасения же насчёт нагрузки на ядро необоснованны: достаточно лишь выстраивать таймеры в очередь в порядке времени их срабатывания, что несложно. Если ожидается действительно большое количество одновременно активных таймеров (скажем, больше сотни), можно эту очередь организовать в виде двоичного дерева, чтобы убыстрить процедуру добавления нового таймера (фактически -- поиска места под него).



Тут просто возникает проблема такого рода. Как известно, драйвер обслуживает конкретный тип устройства и действительно может в теории безконфликтно обозвать все устройства этого типа. Однако имена одного вида и одинакового функционального назначения (например, имена жёстких дисков) могут, в принципе, соответствовать физически сильно отличающимся устройствам, которые обслуживаются разными драйверами (скажем, один жёсткий диск прицеплен через древний PATA, другой -- через AHCI, третий -- SCSI, а четвёртый на самом деле вообще сетевым является). Тут, мне кажется, лишь два варианта: либо давать подобным дискам принципиально разные имена, либо позволять их назначать (по крайней мере, частично) самой системе. Например, драйвер идентифицирует себя как драйвер жёсткого диска, и при подключении нового диска к этому драйверу ОС сгенерит новое имя вида HDn (ну или какое там принято). Пользователю обычно удобней иметь единообразные имена независимо от реального типа устройства (поскольку в подавляющем большинстве случаев важны не тонкие технические нюансы, а общее назначение устройства), хотя иногда это мешает. В общем, тут стоит подумать и, возможно, устроить голосование (лично я от участия в официальном голосовании воздержусь, поскольку к разработке и даже пользованию КОС отношения не имею, а, так сказать, выступаю в роли внештатного флудераста, однако моё мнение -- генерить имена системой).