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

Kernel architecture questions
  • art_zh wrote:Огромная просьба (пока еще не поздно) определять интервал в миллисекундах, а не в сотых долях секунды.
    Учитывая производительность процессоров ПК, может, ещё меньше единицы? Задавать, например, в микросекундах, ну а уж с какой точностью реально поддерживается -- пускай определяется реализацией. В конце концов, на ПК, даже промышленных, не решают задачи, где нужно действительно "с точностью до такта" времена выдерживать, поскольку там это попросту невозможно (это не AVRка какая-нибудь), а поэтому, ИМХО, достаточно, чтобы при установке таймера до его срабатывания проходило времени не меньше, чем задано.
  • art_zh, если это пожелание к реализации, то высокоточные таймеры в принципе должны быть отдельным API с другим принципом работы. Например, Delay имеет миллисекундную точность. Если реализация устраивает, но самые исходные данные в миллисекундах, то кто-то должен перегонять их в тики таймера, и неясно, почему этим должно заниматься ядро, а не вызывающий код.
    Сделаем мир лучше!
  • CleverMouse wrote:Если реализация устраивает, но самые исходные данные в миллисекундах, то кто-то должен перегонять их в тики таймера, и неясно, почему этим должно заниматься ядро, а не вызывающий код.
    Ядро знает, чему равны тики таймера (оно ж настраивает железо), а вот вызывающий код прикладного уровня (и даже драйверы) этого может и не знать (да и не должен знать то, что прямо к нему не относится). В противном случае при внесении изменений в ядро, связанные с увеличением точности таймера, придётся ещё и прикладной код весь переделывать...
  • Насчёт длительности тиков таймера можно не волноваться - она из стольких мест торчит, что её всё равно невозможно изменить. Если не считать трюка "повышаем точность до 1мс, но всю старую обработку вызываем не всегда, а каждый 10-й раз", который фактически сохраняет старую частоту для основной части кода.
    Сделаем мир лучше!
  • CleverMouse
    В таком случае это не timer, а counter.
    И интервал тогда надо жестко привязывать не к секундам, а к квантам системного таймера. Однажды их длительность таки-может измениться.
  • ...в результате чего начнут глючить все программы, использующие любую из сисфункций 5, 23, 26.9, то есть практически все хоть сколько-нибудь существенные. Ну ладно SII, но ты-то должен быть знаком со списком сисфункций?
    Короче, функции TimerHS и CancelTimerHS изменению не подлежат. Не нравятся - не используйте, пишите свои. Тема посвящена дисковым устройствам.
    Сделаем мир лучше!
  • SII прекрасно указал проблемы с именованием устройств из драйвера.
    По таймерам. Драйверу достаточно одного ядерного таймера. Дополнительные таймеры реализуются силами самого драйвера. То есть драйвер поддерживает свой упорядоченный список таймеров, и устанавливает таймер ядра на минимальный интервал.
    Предложение отсчитывать время таймеров и миллисекундах тоже считаю правильным.
  • Частоту системного таймера давно пора поднять до 250-500 Гц. И счетчик тиков делать дополнительный на 64 бита. Переключать потоки на каждом тике тоже не айс. Нужны кванты 20-50 миллисекунд.
  • Serge wrote:Драйверу достаточно одного ядерного таймера. Дополнительные таймеры реализуются силами самого драйвера. То есть драйвер поддерживает свой упорядоченный список таймеров, и устанавливает таймер ядра на минимальный интервал.
    А зачем сваливать на потенциально каждый драйвер несвойственные для него функции, которые элементарно поддаются обобщению и централизованной реализации? Зачем дублировать, по сути, один и тот же код в куче драйверов, если можно реализовать его один раз?
    Предложение отсчитывать время таймеров и миллисекундах тоже считаю правильным.
    А лучше всё ж в микросекундах -- чтоб запас на будущее был...
  • Serge wrote:Частоту системного таймера давно пора поднять до 250-500 Гц. И счетчик тиков делать дополнительный на 64 бита. Переключать потоки на каждом тике тоже не айс. Нужны кванты 20-50 миллисекунд.
    Причём размер кванта потенциально должен устанавливаться для каждого потока индивидуально (на основе приоритетов или ещё чего -- это уж неважно в данном случае).
  • SII

    Код может быть и в ядре. По такому принципу работают таймеры в Minix.
  • CleverMouse

    [corrected] прошу забыть этот пост. Тут я был сильно неправ.
  • Однако как хорошо когда все начинают думать вслух наконец.
    А знаете у всех современых устройств есть прерывания, таймауты ваще не должны использоватся
    одному драйверу может оказаться полезным устанавливать несколько таймеров - например, к компьютеру запросто могут быть подключены две USB-клавиатуры, для каждой из которых нужен отдельный таймер автоповтора.
    2 клавы - 2 драйвера клавы
  • ilya wrote:А знаете у всех современых устройств есть прерывания, таймауты ваще не должны использоватся
    Как ни странно, не все устройства являются современными. И даже не всё зависит от их современности.
    ilya wrote:2 клавы - 2 драйвера клавы
    Ага, и дважды в памяти дублировать один и тот же код, а не только данные, связанные с управлением конкретным экземпляром устройства.
  • Who is online

    Users browsing this forum: No registered users and 2 guests