Здравствуйте, netch80, Вы писали:
C>>Тут не согласен. Из-за отсутствия фиксированого ABI и бинарных драйверов сейчас ядро Линукса развивается просто с первой космической скоростью. N>Перевожу на русский — развивается в самостоятельном полёте в отрыве от реальности. N>)
Но с какой скоростью! В Линуксе сейчас де-факто фич больше, чем в любом другом ядре. И виртуализаций несколько штук (UML, XEN, KVM, Iguest), скоро будет система контейнеров (пока в виде внешних патчей есть OpenVZ и vserver). Недавно адский планировщик еще добавился. Со стороны десктопа — хорошая поддержка ACPI, эксперименты в сторону правильного hibernate. Ну и так далее.
C>> Так как разработчики могут по желанию менять внутренние структуры ядра, часто перекраивая целые системы (вот недавно добили tickless kernel). N>Фича безусловно приятная. (Вообще-то она значительно более раннего происхождения — из линуксового хостинга мелких виртуальных серверов на S/390 — но, видимо, довели до нормального формата.) Хоть и не на любом железе (перестраивать каждый раз i8254 задолбёшься, APIC timer глючит, остаётся разве что HPET, который тоже придуман, мягко говоря, через зад, но в сочетании с ACPI-safe даст то, что нужно).
А что плохого в HPET? Просто интересно?
N>Но при чём тут драйвера? Они обычно заказывали себе таймауты. Если на что-то и влияет отсутствие тиков, то это на устройство callwheel'а (или как оно там зовётся в Linux) центральной системы таймаута, его надо менять на деревья. Драйверам же должно быть пофиг. Более того, если какой-то драйвер сдуру решил ждать тика — это можно и сэмулировать.
Многие драйвера зависели от jiffies, поэтому иногда они слегка переставали работать. Я как-то смотрел diff — куча мелких фиксов в дровах была с этим связана.
N>Если серьёзно подходить к вопросу ABI compatibility, то он решается в любой системе практически при любом изменении интерфейса. Да, старое может работать неэффективно, может работать через переходники, эти переходники будут занимать место и время, но главное, что оно _будет_ работать. Есть много методов для обеспечения такой совместимости. Методы инициализации интерфейса. Поля версий и размеров структур. И так далее...
Я видел изменения в USB-стеке в Линуксе и в слое MTD-устройств (когда добавлял поддержку более нового ядра для одной платы). Многие из них сильно несовместимы, так как изменяют семантику поведения окружения. Можно, конечно, было бы добавить слои эмуляторов и переходников. Но тогда получился бы жуткий монстрик, наподобии ядра Windows.
Посмотри какие изменения произошли с Линуксом за 5 лет (с 2002 года) — если бы мы все еще использовали драйверы 2002 года, то у нас на каждый чих захватывался бы Big Kernel Lock. Да, и куча драйверов просто не работала бы с SMP.
N>И это только одна сторона. А тонкости чипсетов? А SATA на ICH*, которая на каждой второй материнке чуть другая?
Так всегда так — новая технология (SATA) в течение пары-тройки лет поддерживается "урывками". Сейчас уже достаточно стабильно работает.
N>Я верю, что Коксу нет проблем купить именно то железо, которое у него поддерживается. Но массовой от этого система не станет. А линуксовые ядерщики, вместо того, чтобы проявить ситуативную разумную гибкость и хоть тушкой, хоть чучелом, хоть в виде кучи .obj кодов, но протащить чужие драйвера — а затем, получив от этого дополнительные 5-15% рынка, начать уже обосновывать необходимость разработки драйверов в открытом виде и давить своей долей рынка — сейчас требуют нереального, и получат в лучшем случае фигу с маслом.
Проблема в том, что если разрешить бинарные драйвера, то:
1. Исчезнут многие OpenSource-драйвера.
2. От бинарных драйверов будет не избавиться, даже с 90% долей рынка.
3. Фига производители сразу так бросятся писать драйверы. X.org дает достаточно стабильный ABI — а нормальных драйверов от ATI и NVIDIA пришлось ждать много лет.
Мы это видим сейчас на Windows. Для XP 64-bit, например, драйверов очень мало — хотя там и стабильный ABI (forward-compatible с Vista, по большей части). А в Линуксе переход на x64 по большей части прошел совершенно безболезненно.
Лично из моей практики — устройства с драйверами с закрытым кодом для Линукса у меня всегда создавали больше всего проблем (вплоть до выкидывание этого устройства, как в случае с аппаратным Promise RAIDом).
N>Они будут плакать, колоться, и сами и вместе с пользователями, но пользоваться большой, слабоуправляемой, прожорливой и почти недиагностируемой системой только потому, что её много и работая на неё им дают возможность не выдавать чего они не хотят, а если то же с линуксом — их вынуждают раскрыться сразу. А они не готовы раскрыться сразу, пока силу не набрали.
Для таких девайсов обычно разбивают их на две части — GPL-ный переходник и o-шник с закрытой частью. Я работал с подобными устройствами.
Кроме того, в сфере серверных устройств сейчас не выпускают линуксовые драйверы только компании-идиоты. На десктопе ситуация тоже стремительно улучшается (за этот год только несколько крупных прорывов).
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, Вумудщзук, Вы писали:
>>>Вполне нормально. Народ двигает таким образом FF. Плохого ничего не вижу В>>не знаю, что они там двигают, но после таких предъяв я б забил на этот сайтик баальшой болт,
A>Э нет. Если тебе нужен AWStats, то придётся тебе забить болт на свою гордость. А если тебе AWStats не нужен, ты вообще туда не пойдёшь.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Pzz, Вы писали:
Pzz>>Нет, не имеет. Старые драйвера не перестают работать. Появляется лишь возможность доделать их, чтобы получить новую функциональность. C>Имеет. Старые драйвера перестают работать (из-за того, что некоторые предположения, которые принимали авторы драйверов перестают работать). И НЕТ возможности доделать многие из них (производителю они не интересны, а исходника нет).
Я, вообще, в подробности не вдавался, но мне показалось, что tickless kernel — это ядро, которое не просыпается на каждый тик таймера. При условии, что никто в системе не пытается просыпаться на каждый тик таймера.
Т.е., старые драйвера должны таки работать. Но если драйвер, вместо того, чтобы просыпаться каждые N миллисекунд с единственной целью что-нибудь проверить и заснуть, будет использовать явные нотификации об интересных ему событиях, а таймеры заказывать тогда и только тогда, когда ему действительно нужна задержка на определенное время, то это способствует экономии батарейки.
Я где-то ошибаюсь? Что конкретно ломается при переходе на tickless kernel?
C>>>У меня уже работает Проблемы заметил только с аудиопроигрывателем, но их уже пофиксили. Думаю, что за ближайщие 5-6 месяцев большую часть исправят. Pzz>>А FireFox? C>А что с ним? У меня прекрасно работает, KDE/GNOME и остальные программы — тоже.
Фокс время от времени (достаточно часто) просыпается, чтобы я не знаю что сделать.
Вообще, с точки зрения user space ничего не поменялось, кроме возможности сэкономить батарейку. Которой можно и не воспользоваться. Заставить всех воспользоваться этой возможностью путем внесения несовместимых изменений в API — это означает испытать пользовательскую лояльность на прочность. Гораздо гуманннее было бы совместимость оставить, и начать вести "доску позора" со списком программ, которые кушают батарейку сверх нужды, и рекомендациями, чем эти программы можно заменить.
Pzz>>Hint: соплярис какой-нибудь, или MacOS, имеет достаточно похожую на линух драйверную модель, но при этом выдерживает бинарную совместимость. C>МакОС ругают из-за тормознутости ядра (там туча слоев трансляции). Кроме того, там все пишет почти только Эппл. Солярку тоже за это ругают.
Только это плата не за стабильный ABI, а за то, что мозгов было очень много, когда архитектуру ядра дизайнили.
Насчет Мака я не очень понимаю — там часть драйверов прямо в BSD'ное ядро втыкается, а часть — через разнообразные Маковские прослойки.
C>>>В следующей ревизии, кстати, вроде собираются его в официальное ядро начинать пихать. Pzz>>И бинарный HAL им не помешает? C>Так вроде бы его переписали?
Есть альтернативный HAL в исходниках (основанной на скраденной из Atheros'а документации). Но он не успевает поддерживать новые чипы. Поэтому его никто не использует, кроме совсем уж энтузазистов.
Atheros сам явно не торопится раскрывать свои секреты. Прикрываются они требованиями FCC, которые явно запрещают продавать радиопродукты, в которых пользователь может подкрутить мощность радиопередатчика. Поскольку мощность выбирается софтом, а не железом, публикация HAL'а в исходниках нарушила бы это требование. Как с этим борется Intel, я не знаю. Возможно, у них радивом управляет чип или фирмварий.
C>>>Это если дров нет в стандартной поставке. Такая ситуация встречается уже все реже и реже. Pzz>>С wifi до сих пор полные кранты. C>Посмотрим что через годик будет.
Не, ну нельзя же бежать с отставанием в 10 лет от рынка аппаратуры.
C>>>По большей части качество нормальное. Хотя бы из-за того, что для кода делают хоть какой-то review. Pzz>>Ну и для винды оно по большей части нормальное. Хотя бы из-за того, что мелкософт настаивает на прогоне кучи тестов, прежде чем подписать драйвер. C>Про WHQL не надо — это чисто тест "для галочки". Он просто гарантирует, что драйвера не упадут сразу после установки.
Сетевой WHQL — очень дотошный. С другими я близко дела не имел. Причем начиная с какой-то версии, он еще научился объяснять понятными словами, что именно его не устраивает.
Здравствуйте, Cyberax, Вы писали:
AJD>>Ctrl+Shift, действительно, часто не удобно. Но не из-за того что не удобно нажимать, а из-за того что в винде при работе в редакторах Ctrl+Shift используется для выделения текста. C>Так если выделять текст, то раскладка не переключается.
Обычно не переключается, но время от времени мне удавалась так нажимать, что переключалась . Я плюнул и перешел на Alt-Shift.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Pzz, Вы писали:
Pzz>Я, вообще, в подробности не вдавался, но мне показалось, что tickless kernel — это ядро, которое не просыпается на каждый тик таймера. При условии, что никто в системе не пытается просыпаться на каждый тик таймера.
Не совсем так. В tickless-ядре вообше не используется периодический таймер. Используется специальный "будильник", которому дается указание разбудить процессор, когда настанет время для следующего события.
Дает заметную экономия энергии — у меня на ноуте потребление упало с 25 ватт до 20 ватт.
Pzz>Я где-то ошибаюсь? Что конкретно ломается при переходе на tickless kernel?
В ядре есть такая магическая переменная "jiffies", которая обновляется во время каждого отсчета таймера. Она стала работать немного по-другому, и из-за этого ряд драйверов, которые использовали тот факт, что она идет с достаточно постоянной скоростью, вдруг перестали работать.
C>>А что с ним? У меня прекрасно работает, KDE/GNOME и остальные программы — тоже. Pzz>Фокс время от времени (достаточно часто) просыпается, чтобы я не знаю что сделать.
И что?
Pzz>Вообще, с точки зрения user space ничего не поменялось, кроме возможности сэкономить батарейку. Которой можно и не воспользоваться. Заставить всех воспользоваться этой возможностью путем внесения несовместимых изменений в API — это означает испытать пользовательскую лояльность на прочность. Гораздо гуманннее было бы совместимость оставить, и начать вести "доску позора" со списком программ, которые кушают батарейку сверх нужды, и рекомендациями, чем эти программы можно заменить.
Проблема в том, что без поддержки драйверов tickless бессмысленен.
Доска почета/позора, кстати, есть: http://lesswatts.org
C>>МакОС ругают из-за тормознутости ядра (там туча слоев трансляции). Кроме того, там все пишет почти только Эппл. Солярку тоже за это ругают. Pzz>Только это плата не за стабильный ABI, а за то, что мозгов было очень много, когда архитектуру ядра дизайнили. Pzz>Насчет Мака я не очень понимаю — там часть драйверов прямо в BSD'ное ядро втыкается, а часть — через разнообразные Маковские прослойки.
Там все еще хуже. У них используется "гибридное" ядро на основе Mach'а. В результате, там тормозит создание потоков, переключение контекстов и вообще много чего еще.
На десктопе это не так заметно (так как сравнивать не с чем), а вот на серверных benchmark'ах MacOS X очень сильно сливает.
C>>Посмотрим что через годик будет. Pzz>Не, ну нельзя же бежать с отставанием в 10 лет от рынка аппаратуры.
"Лучше день потерять, а потом за 5 минут долететь" (c) мультфильм
C>>Про WHQL не надо — это чисто тест "для галочки". Он просто гарантирует, что драйвера не упадут сразу после установки. Pzz>Сетевой WHQL — очень дотошный. С другими я близко дела не имел. Причем начиная с какой-то версии, он еще научился объяснять понятными словами, что именно его не устраивает.
Я просто помню сколько у меня глючило WHQL-certified дров на видеокарты.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, netch80, Вы писали:
C>>>Тут не согласен. Из-за отсутствия фиксированого ABI и бинарных драйверов сейчас ядро Линукса развивается просто с первой космической скоростью. N>>Перевожу на русский — развивается в самостоятельном полёте в отрыве от реальности. N>>) C>Но с какой скоростью! В Линуксе сейчас де-факто фич больше, чем в любом другом ядре. И виртуализаций несколько штук (UML, XEN, KVM, Iguest), скоро будет система контейнеров (пока в виде внешних патчей есть OpenVZ и vserver). Недавно адский планировщик еще добавился. Со стороны десктопа — хорошая поддержка ACPI, эксперименты в сторону правильного hibernate. Ну и так далее.
C>Многие драйвера зависели от jiffies, поэтому иногда они слегка переставали работать. Я как-то смотрел diff — куча мелких фиксов в дровах была с этим связана.
А что, линуксоидам не хватило ума подкручиваыь jiffies в правильно положение после каждого пробуждения? Что-то слабо верится...
N>>Если серьёзно подходить к вопросу ABI compatibility, то он решается в любой системе практически при любом изменении интерфейса. Да, старое может работать неэффективно, может работать через переходники, эти переходники будут занимать место и время, но главное, что оно _будет_ работать. Есть много методов для обеспечения такой совместимости. Методы инициализации интерфейса. Поля версий и размеров структур. И так далее... C>Я видел изменения в USB-стеке в Линуксе и в слое MTD-устройств (когда добавлял поддержку более нового ядра для одной платы). Многие из них сильно несовместимы, так как изменяют семантику поведения окружения. Можно, конечно, было бы добавить слои эмуляторов и переходников. Но тогда получился бы жуткий монстрик, наподобии ядра Windows.
Во-первых, виндовсное ядро не так уж монструозно. Существенное усложнение в нем происходит от того, что в UNIX'е все запросы ввода-вывода обрабатываются путем вызова метода драйвера на контексте процесса, а винда использует полностью асинхронную модель жизни: на каждый запрос создается IRP и втыкается в очередь драйвера, а потом асинхронно завершается.
Юниксовский подход хорош своей простотой, но у него есть свои недостатки. Например, уже запрошенный ввод-вывод нельзя прервать, не прерывая потока. Асинхронный ввод-вывод смотрится иностранцем.
Кроме того, мелкософтовские ребята совершили явную ошибку, заставив каждый драйвер самому заниматься поддержанием своих очередей, и прочими интересными вещами (типа power mamanement'а), которые можно было бы сделать один раз и навсегда для всех, и 90% драйверов стандартное решение устроило бы — можно было бы не городить свой самодельный огород. Сейчас они эту ошибку постепенно исправляют, WDF называется.
Во-вторых, ну ладно, USB у нас bleeding edge. Но хренова туча всего уже стабилизировалась — давайте хоть там сделаем стабильный ABI. Ну зачем у нас 7 #ifdef'ов внутри структуры sk_buff? Нам что, пары десятков байтов жалко в сетевом пакете? Хрен с этими байтами, давайте лучше ABI стабилизируем.
C>Проблема в том, что если разрешить бинарные драйвера, то: C>1. Исчезнут многие OpenSource-драйвера.
С какой радости они исчезнут? Они могут исчезнуть, только если их место займут бинарные драйвера, значительно превосходящие их по качеству.
Стабильный ABI в user space не приводит же к исчезновению опенсорсовых приложений.
C>2. От бинарных драйверов будет не избавиться, даже с 90% долей рынка.
Ну и пусть себе. Это чисто политический вопрос. Разве закрытые приложения в user space кому-то мешают? Точно то же относится и к драйверам.
C>3. Фига производители сразу так бросятся писать драйверы. X.org дает достаточно стабильный ABI — а нормальных драйверов от ATI и NVIDIA пришлось ждать много лет.
Стабильный драйверный ABI хорош уже тем, что не надо пересобирать драйвера каждый раз, когда поменялось ядро. Сейчас даже опенсорсовые драйвера, которые не входят в дистрибутив ядра — большой геморрой.
Представляешь, если бы замена ядра приводила бы к необходимости пересобирать весь user land. Кому такая система была бы нужна? А в чем содержательно разница между 3rd party user space программучиной и 3rd party драйвером?
Re[3]: Ответ сразу всем опенсорсникам, ведущим со мной тут д
IE 6 IE 7 Firefox 2 Opera 9
тэги
td 62% 62% 78% 71%
th 62% 62% 78% 71%
tr 77% 77% 91% 86%
Cell alignment attributes 37% 37% 68% 68%
css (I - incomplete)
@import I I Y Y
@media I I Y Y
E I I Y Y
E F I I Y Y
:hover I I Y Y
background 56% 58% Y 83%
border 58% 61% Y ≈100%
margin 50% 60% Y Y
overflow 42% 50% 92% Y
padding 50% 63% Y Y
ну и так далее
M>>C точки зрения пользователя: M>>- очень легко загнать IE в GDI handle limit (где-то на 200-м табе что-ли)
KV>Честно — тяжело могу себе представить, зачем мне открывать 200 табов. Я и 20 — крайне редко достигаю.
Я тоже Но у нас по работе некоторым приходится
Ну и в ЖЖ недавно пробегало — кто сколько держит табов открытыми. Довольно много было таких, кто не меньше 150 держит открытыми
M>>Для себя я лично решил так:
M>>- Опера для всего M>>- Файрфокс для разработки M>>- ИЕ для проверки результатов разработки и на тот 0,001% случаев, когда сайт действительно IE-only (ActiveX там..)
KV>И согласно моей логике — трижды заниженный уровень безопасности на машине
Здравствуйте, Cyberax, Вы писали:
Pzz>>Я, вообще, в подробности не вдавался, но мне показалось, что tickless kernel — это ядро, которое не просыпается на каждый тик таймера. При условии, что никто в системе не пытается просыпаться на каждый тик таймера. C>Не совсем так. В tickless-ядре вообше не используется периодический таймер. Используется специальный "будильник", которому дается указание разбудить процессор, когда настанет время для следующего события.
Ну так и в обычном ядре просто так на таймерное прерывание не сядешь. Можно заказать таймер на определенное время. То, что "разбрасывалка" таймеров научилась не просыпаться на каждый тик, казалось бы — факт из ее личной жизни.
Pzz>>Я где-то ошибаюсь? Что конкретно ломается при переходе на tickless kernel? C>В ядре есть такая магическая переменная "jiffies", которая обновляется во время каждого отсчета таймера. Она стала работать немного по-другому, и из-за этого ряд драйверов, которые использовали тот факт, что она идет с достаточно постоянной скоростью, вдруг перестали работать.
Я не понимаю. Если драйвер спит, то ему все равно, что происходит с jiffies. Важно, чтобы когда он проснулся, jiffies оказалось в правильном положении.
Казалось бы, заметить неравномерность jiffies можно, только поставив аппаратный breakpoint на его изменение. Что вряд ли кто-то делает
C>>>А что с ним? У меня прекрасно работает, KDE/GNOME и остальные программы — тоже. Pzz>>Фокс время от времени (достаточно часто) просыпается, чтобы я не знаю что сделать. C>И что?
А то, что tickless что-то дает, только если он позволяет выключать процессор на бОльшие интервалы времени, чем между тиками. Совершенно неважно, кто просыпается, драйвера или user land — если кто-то это постоянно делает, то экономии электричества не получается.
Pzz>>Вообще, с точки зрения user space ничего не поменялось, кроме возможности сэкономить батарейку. Которой можно и не воспользоваться. Заставить всех воспользоваться этой возможностью путем внесения несовместимых изменений в API — это означает испытать пользовательскую лояльность на прочность. Гораздо гуманннее было бы совместимость оставить, и начать вести "доску позора" со списком программ, которые кушают батарейку сверх нужды, и рекомендациями, чем эти программы можно заменить. C>Проблема в том, что без поддержки драйверов tickless бессмысленен.
И без поддержки user land — тоже. Одной маленькой пакостной програмки, которая неприменно хочет просыпаться 100 раз в секунду, хватит, чтобы весь tickless пошел нафиг. И совершенно не важно, кто это делает, безумный драйвер, который чего-нибудь поллит в цикле с небольшими задержками, или безумная аппликуха, которая делает то же самое.
C>>>МакОС ругают из-за тормознутости ядра (там туча слоев трансляции). Кроме того, там все пишет почти только Эппл. Солярку тоже за это ругают. Pzz>>Только это плата не за стабильный ABI, а за то, что мозгов было очень много, когда архитектуру ядра дизайнили. Pzz>>Насчет Мака я не очень понимаю — там часть драйверов прямо в BSD'ное ядро втыкается, а часть — через разнообразные Маковские прослойки. C>Там все еще хуже. У них используется "гибридное" ядро на основе Mach'а. В результате, там тормозит создание потоков, переключение контекстов и вообще много чего еще.
Я знаю, да. Причем некоторые драйвера живут в Mach'е, некоторые в BDS, и выглядят, как нормальные BSD'ные, а некоторые в BSD, но используют C++'ную прокладку, чтобы в BSD втыкаться. Например, сетевые драйвера используют именно 3-й вариант.
Ужоснах
C>>>Посмотрим что через годик будет. Pzz>>Не, ну нельзя же бежать с отставанием в 10 лет от рынка аппаратуры. C>"Лучше день потерять, а потом за 5 минут долететь" (c) мультфильм
Угу. Если к тому времени вообще будет иметь смысл лететь.
Пока что линух на лабтопе сосет с нервными причмокиваниями. Причем не только из-за powersave. Но, например, и из-за сети. Ну не предусмотрено в линуксном мире, что подключение к сети может постоянно меняться, и что из 2-х подключенных интерфейсов нормальный выход в и-нет может быть только у одного (и разумеется, не у того, за который линух случайным образом зацепился, в плане роутить именно туда по дефолту, и общаться с DNS-сервером, который проанонсировали именно с той стороны по DHCP).
C>>>Про WHQL не надо — это чисто тест "для галочки". Он просто гарантирует, что драйвера не упадут сразу после установки. Pzz>>Сетевой WHQL — очень дотошный. С другими я близко дела не имел. Причем начиная с какой-то версии, он еще научился объяснять понятными словами, что именно его не устраивает. C>Я просто помню сколько у меня глючило WHQL-certified дров на видеокарты.
Видеодрайвера вообще пишет какая-то антидрайверная мафия. Они нигде хорошо не работают
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, netch80, Вы писали:
C>>>Тут не согласен. Из-за отсутствия фиксированого ABI и бинарных драйверов сейчас ядро Линукса развивается просто с первой космической скоростью. N>>Перевожу на русский — развивается в самостоятельном полёте в отрыве от реальности. N>>) C>Но с какой скоростью! В Линуксе сейчас де-факто фич больше, чем в любом другом ядре. И виртуализаций несколько штук (UML, XEN, KVM, Iguest), скоро будет система контейнеров (пока в виде внешних патчей есть OpenVZ и vserver). Недавно адский планировщик еще добавился. Со стороны десктопа — хорошая поддержка ACPI, эксперименты в сторону правильного hibernate. Ну и так далее.
Угу, "а теперь со всей этой фигнёй мы попытаемся взлететь".
Сколько старых драйверов выкидывается потому, что их некому апдейтить?
C>А что плохого в HPET? Просто интересно?
http://www.livejournal.com/users/netch/39976.html
многословно, но идея понятна.
N>>Но при чём тут драйвера? Они обычно заказывали себе таймауты. Если на что-то и влияет отсутствие тиков, то это на устройство callwheel'а (или как оно там зовётся в Linux) центральной системы таймаута, его надо менять на деревья. Драйверам же должно быть пофиг. Более того, если какой-то драйвер сдуру решил ждать тика — это можно и сэмулировать. C>Многие драйвера зависели от jiffies, поэтому иногда они слегка переставали работать. Я как-то смотрел diff — куча мелких фиксов в дровах была с этим связана.
Никто не мешал им сохранить jiffies в старой роли.
N>>Если серьёзно подходить к вопросу ABI compatibility, то он решается в любой системе практически при любом изменении интерфейса. Да, старое может работать неэффективно, может работать через переходники, эти переходники будут занимать место и время, но главное, что оно _будет_ работать. Есть много методов для обеспечения такой совместимости. Методы инициализации интерфейса. Поля версий и размеров структур. И так далее... C>Я видел изменения в USB-стеке в Линуксе и в слое MTD-устройств (когда добавлял поддержку более нового ядра для одной платы). Многие из них сильно несовместимы, так как изменяют семантику поведения окружения. Можно, конечно, было бы добавить слои эмуляторов и переходников. Но тогда получился бы жуткий монстрик, наподобии ядра Windows.
Да нет там особого монстризма.
C>Посмотри какие изменения произошли с Линуксом за 5 лет (с 2002 года) — если бы мы все еще использовали драйверы 2002 года, то у нас на каждый чих захватывался бы Big Kernel Lock. Да, и куча драйверов просто не работала бы с SMP.
Во-первых, BKL уже захватывался достаточно редко.
Во-вторых, ну а почему нет? Если система работает со старым драйвером, пусть даже медленно — это лучше, чем она совсем не работает.
N>>И это только одна сторона. А тонкости чипсетов? А SATA на ICH*, которая на каждой второй материнке чуть другая? C>Так всегда так — новая технология (SATA) в течение пары-тройки лет поддерживается "урывками". Сейчас уже достаточно стабильно работает.
Я ещё понимаю, если эти "урывки" по причине производителя. Ну кривые у него руки, потому что иных не бывает. Но если одновременно есть работающие драйвера для Windows и нет таких для Linux, я обижаюсь.
N>>Я верю, что Коксу нет проблем купить именно то железо, которое у него поддерживается. Но массовой от этого система не станет. А линуксовые ядерщики, вместо того, чтобы проявить ситуативную разумную гибкость и хоть тушкой, хоть чучелом, хоть в виде кучи .obj кодов, но протащить чужие драйвера — а затем, получив от этого дополнительные 5-15% рынка, начать уже обосновывать необходимость разработки драйверов в открытом виде и давить своей долей рынка — сейчас требуют нереального, и получат в лучшем случае фигу с маслом. C>Проблема в том, что если разрешить бинарные драйвера, то: C>1. Исчезнут многие OpenSource-драйвера.
Не вижу причины к этому.
C>2. От бинарных драйверов будет не избавиться, даже с 90% долей рынка.
А зачем от них избавляться? Драйвер нужен для того, чтобы он работал. Если производитель психологически не готов открыть драйвер — пусть делает закрытый.
C>3. Фига производители сразу так бросятся писать драйверы. X.org дает достаточно стабильный ABI — а нормальных драйверов от ATI и NVIDIA пришлось ждать много лет.
Это одна узкая область.
C>Мы это видим сейчас на Windows. Для XP 64-bit, например, драйверов очень мало — хотя там и стабильный ABI (forward-compatible с Vista, по большей части). А в Линуксе переход на x64 по большей части прошел совершенно безболезненно.
Да, это аргумент. Но часто ты предполагаешь такие суровые переходы?
C>Лично из моей практики — устройства с драйверами с закрытым кодом для Линукса у меня всегда создавали больше всего проблем (вплоть до выкидывание этого устройства, как в случае с аппаратным Promise RAIDом).
Потому что общий уровень компетентности производителя ниже. Но почему нет альтернативы этому выбрасыванию?
Здравствуйте, Pzz, Вы писали:
C>>Многие драйвера зависели от jiffies, поэтому иногда они слегка переставали работать. Я как-то смотрел diff — куча мелких фиксов в дровах была с этим связана. Pzz>А что, линуксоидам не хватило ума подкручиваыь jiffies в правильно положение после каждого пробуждения? Что-то слабо верится...
Проблема в том, что пробуждение может быть в середине отсчета таймера. То есть, нет возможности сделать изменение jiffies'ов регулярным.
Собственно, поэтому jiffies сейчас считается deprecated — от него будут постепенно избавляться даже в обычном (не-tickless-ядре).
Pzz>Во-первых, виндовсное ядро не так уж монструозно. Существенное усложнение в нем происходит от того, что в UNIX'е все запросы ввода-вывода обрабатываются путем вызова метода драйвера на контексте процесса, а винда использует полностью асинхронную модель жизни: на каждый запрос создается IRP и втыкается в очередь драйвера, а потом асинхронно завершается.
Не совсем так. IPR может обрабатываться в контексте вызывающего процесса (из-за чего возникают постоянные проблемы с местом на стеке ). Просто для IO предусмотрена возможность отложить выполнение запроса в worker thread.
Pzz>Юниксовский подход хорош своей простотой, но у него есть свои недостатки. Например, уже запрошенный ввод-вывод нельзя прервать, не прерывая потока. Асинхронный ввод-вывод смотрится иностранцем.
Так асинхронный вывод нужен в уж очень редких случаях.
Pzz>Кроме того, мелкософтовские ребята совершили явную ошибку, заставив каждый драйвер самому заниматься поддержанием своих очередей, и прочими интересными вещами (типа power mamanement'а), которые можно было бы сделать один раз и навсегда для всех, и 90% драйверов стандартное решение устроило бы — можно было бы не городить свой самодельный огород. Сейчас они эту ошибку постепенно исправляют, WDF называется.
WDF — это скорее логическое продолжение WDM. Там просто добавляются многие новые фичи.
Pzz>Во-вторых, ну ладно, USB у нас bleeding edge. Но хренова туча всего уже стабилизировалась — давайте хоть там сделаем стабильный ABI. Ну зачем у нас 7 #ifdef'ов внутри структуры sk_buff? Нам что, пары десятков байтов жалко в сетевом пакете? Хрен с этими байтами, давайте лучше ABI стабилизируем.
Жалко, например, для ATM-ячеек размерами в 53 байта каждая.
C>>Проблема в том, что если разрешить бинарные драйвера, то: C>>1. Исчезнут многие OpenSource-драйвера. Pzz>С какой радости они исчезнут? Они могут исчезнуть, только если их место займут бинарные драйвера, значительно превосходящие их по качеству.
С такой, что фирмам не захочется поддерживать их. А насчет "превосходящих по качеству" — хахахахахахаха.
Pzz>Стабильный ABI в user space не приводит же к исчезновению опенсорсовых приложений.
Так как нет зависимости от секретных данных производителей.
C>>2. От бинарных драйверов будет не избавиться, даже с 90% долей рынка. Pzz>Ну и пусть себе. Это чисто политический вопрос. Разве закрытые приложения в user space кому-то мешают? Точно то же относится и к драйверам.
Не относится — это совсем разные вещи. Вместо закрытого приложения я обычно могу взять открытое, с драйвером у меня обычно не будет такой возможности.
C>>3. Фига производители сразу так бросятся писать драйверы. X.org дает достаточно стабильный ABI — а нормальных драйверов от ATI и NVIDIA пришлось ждать много лет. Pzz>Стабильный драйверный ABI хорош уже тем, что не надо пересобирать драйвера каждый раз, когда поменялось ядро. Сейчас даже опенсорсовые драйвера, которые не входят в дистрибутив ядра — большой геморрой.
Ну не знаю — патчи в ядро накладываются элементарно, запуском одного скрипта. Если сам строишь ядро — то перестроить внешние драйверы можно без проблем. Ну и дистрибутивы могут паковать драйвера в виде зависимостей ядра.
Pzz>Представляешь, если бы замена ядра приводила бы к необходимости пересобирать весь user land. Кому такая система была бы нужна? А в чем содержательно разница между 3rd party user space программучиной и 3rd party драйвером?
Ну.... Gentoo так и делает примерно
Здравствуйте, Pzz, Вы писали:
Pzz>Во-первых, виндовсное ядро не так уж монструозно. Существенное усложнение в нем происходит от того, что в UNIX'е все запросы ввода-вывода обрабатываются путем вызова метода драйвера на контексте процесса, а винда использует полностью асинхронную модель жизни: на каждый запрос создается IRP и втыкается в очередь драйвера, а потом асинхронно завершается. Pzz>Юниксовский подход хорош своей простотой, но у него есть свои недостатки. Например, уже запрошенный ввод-вывод нельзя прервать, не прерывая потока. Асинхронный ввод-вывод смотрится иностранцем.
Ну почему же. "Уже запрошенный" ввод-вывод нормально прерывается сигналом, если он на то рассчитан. Непрерываемость дискового I/O — всего лишь артефакт лени его изобретателей аккуратно разобраться с владением буферами. Можно и сделать прерывание со стороны. Вопрос лишь в том, чтобы правильно выбрать, где сделать wakeup:))
Асинхронный — просто не сделали изначально нормально. Тот же kqueue фактически изображает из себя при его использовании с AIO правильный completion port.
Pzz>Во-вторых, ну ладно, USB у нас bleeding edge. Но хренова туча всего уже стабилизировалась — давайте хоть там сделаем стабильный ABI. Ну зачем у нас 7 #ifdef'ов внутри структуры sk_buff? Нам что, пары десятков байтов жалко в сетевом пакете? Хрен с этими байтами, давайте лучше ABI стабилизируем.
sk_buff — это таки очень странное место, я его не понимаю.:(
Pzz>Стабильный драйверный ABI хорош уже тем, что не надо пересобирать драйвера каждый раз, когда поменялось ядро. Сейчас даже опенсорсовые драйвера, которые не входят в дистрибутив ядра — большой геморрой. Pzz>Представляешь, если бы замена ядра приводила бы к необходимости пересобирать весь user land. Кому такая система была бы нужна? А в чем содержательно разница между 3rd party user space программучиной и 3rd party драйвером?
Здравствуйте, Pzz, Вы писали:
Pzz>Вообще, с точки зрения user space ничего не поменялось, кроме возможности сэкономить батарейку. Которой можно и не воспользоваться.
Основная цель, как я понимаю, другая — если есть виртуальных машин дофига и больше, экономится уже не батарейка, а реальная мощность.
Pzz> Заставить всех воспользоваться этой возможностью путем внесения несовместимых изменений в API — это означает испытать пользовательскую лояльность на прочность. Гораздо гуманннее было бы совместимость оставить, и начать вести "доску позора" со списком программ, которые кушают батарейку сверх нужды, и рекомендациями, чем эти программы можно заменить.
Помнишь цитату про то, что Unix тщательно выбирает себе друзей?;))
Здравствуйте, netch80, Вы писали:
N>Ну почему же. "Уже запрошенный" ввод-вывод нормально прерывается сигналом, если он на то рассчитан. Непрерываемость дискового I/O — всего лишь артефакт лени его изобретателей аккуратно разобраться с владением буферами. Можно и сделать прерывание со стороны. Вопрос лишь в том, чтобы правильно выбрать, где сделать wakeup
Прерывается вместе с потоком. Не слишком-то удобно. Вообще, вся конструкция юниксовских сигналов не слишком-то удобная.
В Венде вон тоже IRP'ы за каким-то хреном изначально были привязаны к потоку, который их породил. Т.е., запускаем overlapped I/O, завершаем поток, и все — Венда зачем-то cancel'ит IRP. В Висте, наконец, одумались, и стало возможно породить запрос в одном потоке, а разбираться с ним в другом.
N>Асинхронный — просто не сделали изначально нормально. Тот же kqueue фактически изображает из себя при его использовании с AIO правильный completion port.
Насколько я понимаю, я не могу заказать асинхронный write, и пойти заниматься своими делами. Там где могу, это делается отдельным потоком (спрятанным внутри libc). Что убивает идею асинхронного в/в как очень эффективного способа заставить систему ввода-вывода работать параллельно с моей задачей.
Здравствуйте, netch80, Вы писали:
Pzz>>Вообще, с точки зрения user space ничего не поменялось, кроме возможности сэкономить батарейку. Которой можно и не воспользоваться.
N>Основная цель, как я понимаю, другая — если есть виртуальных машин дофига и больше, экономится уже не батарейка, а реальная мощность.
Ну это, наверное, тоже. Лабтопщику сэкономленные 5 ватт ничуть не менее важны, чем виртуальному сервернику — 5 киловатт.
Хотя бапки за это только виртуальщики готовы заплатить, согласен.
Pzz>> Заставить всех воспользоваться этой возможностью путем внесения несовместимых изменений в API — это означает испытать пользовательскую лояльность на прочность. Гораздо гуманннее было бы совместимость оставить, и начать вести "доску позора" со списком программ, которые кушают батарейку сверх нужды, и рекомендациями, чем эти программы можно заменить.
N>Помнишь цитату про то, что Unix тщательно выбирает себе друзей?)
Про то, над ними потом издеваеться будут, там не было написано
Здравствуйте, Pzz, Вы писали:
N>>Асинхронный — просто не сделали изначально нормально. Тот же kqueue фактически изображает из себя при его использовании с AIO правильный completion port. Pzz>Насколько я понимаю, я не могу заказать асинхронный write, и пойти заниматься своими делами. Там где могу, это делается отдельным потоком (спрятанным внутри libc). Что убивает идею асинхронного в/в как очень эффективного способа заставить систему ввода-вывода работать параллельно с моей задачей.
Почему, вроде бы можешь. Ну а еще со splice()'ом и sendfile() вообще сказка получается...
Здравствуйте, Cyberax, Вы писали:
C>>>Многие драйвера зависели от jiffies, поэтому иногда они слегка переставали работать. Я как-то смотрел diff — куча мелких фиксов в дровах была с этим связана. Pzz>>А что, линуксоидам не хватило ума подкручиваыь jiffies в правильно положение после каждого пробуждения? Что-то слабо верится... C>Проблема в том, что пробуждение может быть в середине отсчета таймера. То есть, нет возможности сделать изменение jiffies'ов регулярным.
1. Можно было бы и сохранить это, округляя все запрошенные интервалы до старого тика
2. Рассчитывать на то, что время в ядре течет непрерывно, могут только индусы. Любой драйвер может быть прерван в любой момент аппаратным прерыванием. А в preemptable ядре еще и просто переключением процессов
C>Собственно, поэтому jiffies сейчас считается deprecated — от него будут постепенно избавляться даже в обычном (не-tickless-ядре).
А что вместо него?
Pzz>>Во-первых, виндовсное ядро не так уж монструозно. Существенное усложнение в нем происходит от того, что в UNIX'е все запросы ввода-вывода обрабатываются путем вызова метода драйвера на контексте процесса, а винда использует полностью асинхронную модель жизни: на каждый запрос создается IRP и втыкается в очередь драйвера, а потом асинхронно завершается. C>Не совсем так. IPR может обрабатываться в контексте вызывающего процесса (из-за чего возникают постоянные проблемы с местом на стеке ). Просто для IO предусмотрена возможность отложить выполнение запроса в worker thread.
Это не очень рекомендуется делать. В венде драйвера можно связывать в стеки, и нет гарантии, что в тот момент, когда IRP достанется твоему драйверу ты все еще находишься на контексте процесса, который его породил.
Pzz>>Юниксовский подход хорош своей простотой, но у него есть свои недостатки. Например, уже запрошенный ввод-вывод нельзя прервать, не прерывая потока. Асинхронный ввод-вывод смотрится иностранцем. C>Так асинхронный вывод нужен в уж очень редких случаях.
Асинхронный ввод-вывод позволяет заставить систему ввода-вывода в ядре работать параллельно пользовательскому процессу. Т.е., если мы хотим выжать максимальную производительность, он таки нужен. Другой вопрос, что венда настолько успешно умудряется тормозить о разные интересные места, что выигрыш часто почти не заметен.
Pzz>>Кроме того, мелкософтовские ребята совершили явную ошибку, заставив каждый драйвер самому заниматься поддержанием своих очередей, и прочими интересными вещами (типа power mamanement'а), которые можно было бы сделать один раз и навсегда для всех, и 90% драйверов стандартное решение устроило бы — можно было бы не городить свой самодельный огород. Сейчас они эту ошибку постепенно исправляют, WDF называется. C>WDF — это скорее логическое продолжение WDM. Там просто добавляются многие новые фичи.
Не только. Они еще попытались упростить многие вещи. Например, теперь больше не надо писать 1000 строк всякой мути для управления power state, без чего WDM-драйвер просто не заведется, и что все бездумно таскают друг у друга. Добавились удобные очереди запросов. Ну и т.п.
Pzz>>Во-вторых, ну ладно, USB у нас bleeding edge. Но хренова туча всего уже стабилизировалась — давайте хоть там сделаем стабильный ABI. Ну зачем у нас 7 #ifdef'ов внутри структуры sk_buff? Нам что, пары десятков байтов жалко в сетевом пакете? Хрен с этими байтами, давайте лучше ABI стабилизируем. C>Жалко, например, для ATM-ячеек размерами в 53 байта каждая.
Эта пара десятков байт даже на фоне остальной структуры смотрится, как небольшая часть. А ATM'ные пакетики не надо собирать в SKB'ках по одной SKB'ке на пакетик. Тем более, что насколько я помню, линух вам не BSD, и сетевой стек все равно хочет видеть в SKB полный сетевой пакет (т.е., все 1500 байт), а не кучу маленьких кусочков — т.е., перепаковывать все равно придется.
C>>>1. Исчезнут многие OpenSource-драйвера. Pzz>>С какой радости они исчезнут? Они могут исчезнуть, только если их место займут бинарные драйвера, значительно превосходящие их по качеству. C>С такой, что фирмам не захочется поддерживать их. А насчет "превосходящих по качеству" — хахахахахахаха.
Их и сейчас поддерживают не фирмы. Не представляю, каким образом фирмы могут заставить тех ребят, которые сейчас поддерживают драйвера, больше этого не делать.
Pzz>>Стабильный ABI в user space не приводит же к исчезновению опенсорсовых приложений. C>Так как нет зависимости от секретных данных производителей.
У нас уже появился опенсорсовый Скайп?
C>>>2. От бинарных драйверов будет не избавиться, даже с 90% долей рынка. Pzz>>Ну и пусть себе. Это чисто политический вопрос. Разве закрытые приложения в user space кому-то мешают? Точно то же относится и к драйверам. C>Не относится — это совсем разные вещи. Вместо закрытого приложения я обычно могу взять открытое, с драйвером у меня обычно не будет такой возможности.
Всегда можно взять железку, для которой есть опенсорсовый драйвер. А если его нет ни для одной железки в классе, то по крайней мере ситуация не хуже, чем сейчас.
Обрати внимание, что для Мака есть опенсорсовые драйвера, хотя этого никто специально не енфорсит.
Pzz>>Стабильный драйверный ABI хорош уже тем, что не надо пересобирать драйвера каждый раз, когда поменялось ядро. Сейчас даже опенсорсовые драйвера, которые не входят в дистрибутив ядра — большой геморрой. C>Ну не знаю — патчи в ядро накладываются элементарно, запуском одного скрипта. Если сам строишь ядро — то перестроить внешние драйверы можно без проблем. Ну и дистрибутивы могут паковать драйвера в виде зависимостей ядра.
Элементарно они накладываются на plain vanilla kernel. А не на ядро, уже обработанное редхатовским напильником.
Мое личное желание собирать ядра своими руками пропало несколько лет назад. С тех пор, как ядра из коробки научились достаточно гладко работать. В жизни есть более интересные занятия, чем пересобирать линуксячие ядра.
Если драйвера действительно 3rd party, то дистрибутивы их не пакуют. Соотсветственно, между выходом очередного ядра и тем, как вендор сподобится пересобрать под него драйвера, проходит некоторое время. Иногда равное бесконечности.
Разнообразие дистрибутивов, помноженное на разнообразие ядер внутри каждого дистрибутива не добавляет вендорам железа желания поддерживать линух.
Pzz>>Представляешь, если бы замена ядра приводила бы к необходимости пересобирать весь user land. Кому такая система была бы нужна? А в чем содержательно разница между 3rd party user space программучиной и 3rd party драйвером? C>Ну.... Gentoo так и делает примерно
Здравствуйте, Pzz, Вы писали:
C>>Проблема в том, что пробуждение может быть в середине отсчета таймера. То есть, нет возможности сделать изменение jiffies'ов регулярным. Pzz>1. Можно было бы и сохранить это, округляя все запрошенные интервалы до старого тика
Приводило к division by zero.
Pzz>2. Рассчитывать на то, что время в ядре течет непрерывно, могут только индусы. Любой драйвер может быть прерван в любой момент аппаратным прерыванием. А в preemptable ядре еще и просто переключением процессов
Тем не менее, рассчитывали.
C>>Собственно, поэтому jiffies сейчас считается deprecated — от него будут постепенно избавляться даже в обычном (не-tickless-ядре). Pzz>А что вместо него?
Ничего Там сейчас инфраструктура для работы с HPET.
C>>Не совсем так. IPR может обрабатываться в контексте вызывающего процесса (из-за чего возникают постоянные проблемы с местом на стеке ). Просто для IO предусмотрена возможность отложить выполнение запроса в worker thread. Pzz>Это не очень рекомендуется делать. В венде драйвера можно связывать в стеки, и нет гарантии, что в тот момент, когда IRP достанется твоему драйверу ты все еще находишься на контексте процесса, который его породил.
Я знаю, но сама по себе возможность существует.
Pzz>Асинхронный ввод-вывод позволяет заставить систему ввода-вывода в ядре работать параллельно пользовательскому процессу. Т.е., если мы хотим выжать максимальную производительность, он таки нужен. Другой вопрос, что венда настолько успешно умудряется тормозить о разные интересные места, что выигрыш часто почти не заметен.
Асинхронный IO полезен только когда IO делает какой-то внешний механизм типа DMA, позволяющий разгрузить процессор. А это не так уж часто доступно. Ну и в Линуксе для этого в лучших традициях есть sendfile() и splice().
C>>WDF — это скорее логическое продолжение WDM. Там просто добавляются многие новые фичи. Pzz>Не только. Они еще попытались упростить многие вещи. Например, теперь больше не надо писать 1000 строк всякой мути для управления power state, без чего WDM-драйвер просто не заведется, и что все бездумно таскают друг у друга. Добавились удобные очереди запросов. Ну и т.п.
Надо будет посмотреть, когда следующая Windows выйдет
Pzz>Эта пара десятков байт даже на фоне остальной структуры смотрится, как небольшая часть. А ATM'ные пакетики не надо собирать в SKB'ках по одной SKB'ке на пакетик. Тем более, что насколько я помню, линух вам не BSD, и сетевой стек все равно хочет видеть в SKB полный сетевой пакет (т.е., все 1500 байт), а не кучу маленьких кусочков — т.е., перепаковывать все равно придется.
AFAIR, максимальный пакет не требуется (иначе все бы загнулось с jumbo-фреймами на гигабитных картах).
C>>С такой, что фирмам не захочется поддерживать их. А насчет "превосходящих по качеству" — хахахахахахаха. Pzz>Их и сейчас поддерживают не фирмы. Не представляю, каким образом фирмы могут заставить тех ребят, которые сейчас поддерживают драйвера, больше этого не делать.
Нет. Как раз большая часть драйверов в ядре поддерживается компаниями-изготовителями (или разработчиками, которым они платят).
C>>Так как нет зависимости от секретных данных производителей. Pzz>У нас уже появился опенсорсовый Скайп?
Да, называется Google Talk В смысле — я обычно могу использовать аналогичную по функциональности систему.
Pzz>Всегда можно взять железку, для которой есть опенсорсовый драйвер. А если его нет ни для одной железки в классе, то по крайней мере ситуация не хуже, чем сейчас.
Не совсем — большая часть проблем с железками, которые навязывают поставщики (т.е. которые идут на большинстве железа).
Pzz>Обрати внимание, что для Мака есть опенсорсовые драйвера, хотя этого никто специально не енфорсит.
Интересно, сколько их там всего?
Здравствуйте, Cyberax, Вы писали:
C>>>Проблема в том, что пробуждение может быть в середине отсчета таймера. То есть, нет возможности сделать изменение jiffies'ов регулярным. Pzz>>1. Можно было бы и сохранить это, округляя все запрошенные интервалы до старого тика C>Приводило к division by zero.
О как. А что же и на что они делили?
C>>>Собственно, поэтому jiffies сейчас считается deprecated — от него будут постепенно избавляться даже в обычном (не-tickless-ядре). Pzz>>А что вместо него? C>Ничего Там сейчас инфраструктура для работы с HPET.
Ну а время-то как узнать текущее? Причем желательно, чтобы это было дешево.
Pzz>>Асинхронный ввод-вывод позволяет заставить систему ввода-вывода в ядре работать параллельно пользовательскому процессу. Т.е., если мы хотим выжать максимальную производительность, он таки нужен. Другой вопрос, что венда настолько успешно умудряется тормозить о разные интересные места, что выигрыш часто почти не заметен. C>Асинхронный IO полезен только когда IO делает какой-то внешний механизм типа DMA, позволяющий разгрузить процессор. А это не так уж часто доступно. Ну и в Линуксе для этого в лучших традициях есть sendfile() и splice().
О как. Я навскидку могу в своем компутере придумать только одно место, где нет никакого DMA. Это клавиатура — она у меня не USB, а PS/2. Настояшшая, IBM'овская, весом 5 килограмм
Насчет sendfile(), ну не всем же надо именно файлы посылать или копировать с места на место...
C>>>WDF — это скорее логическое продолжение WDM. Там просто добавляются многие новые фичи. Pzz>>Не только. Они еще попытались упростить многие вещи. Например, теперь больше не надо писать 1000 строк всякой мути для управления power state, без чего WDM-драйвер просто не заведется, и что все бездумно таскают друг у друга. Добавились удобные очереди запросов. Ну и т.п. C>Надо будет посмотреть, когда следующая Windows выйдет
Посмотреть на что?
Следующая версия виндовс уже вышла, WDF есть и для XP. Смотреть надо, когда выйдет следующая версия индусских драйверописателей
Pzz>>Эта пара десятков байт даже на фоне остальной структуры смотрится, как небольшая часть. А ATM'ные пакетики не надо собирать в SKB'ках по одной SKB'ке на пакетик. Тем более, что насколько я помню, линух вам не BSD, и сетевой стек все равно хочет видеть в SKB полный сетевой пакет (т.е., все 1500 байт), а не кучу маленьких кусочков — т.е., перепаковывать все равно придется. C>AFAIR, максимальный пакет не требуется (иначе все бы загнулось с jumbo-фреймами на гигабитных картах).
Да, там можно приаттачить к SKB'ке странички памяти. Но этот метод не для ATM'ных фреймов
Pzz>>Их и сейчас поддерживают не фирмы. Не представляю, каким образом фирмы могут заставить тех ребят, которые сейчас поддерживают драйвера, больше этого не делать. C>Нет. Как раз большая часть драйверов в ядре поддерживается компаниями-изготовителями (или разработчиками, которым они платят).
Если у кого-то уже есть опенсорсный драйвер, какой смысл его закрывать? Все секреты-то уже опубликованы тем самым.
C>>>Так как нет зависимости от секретных данных производителей. Pzz>>У нас уже появился опенсорсовый Скайп? C>Да, называется Google Talk В смысле — я обычно могу использовать аналогичную по функциональности систему.
Гуглотолк не умеет звонить на внешние номера. И дырки в NAT'е он пробивать почти не умеет. По крайней мере, его опенсорсная инкарнация.
И это, кстати, связанные вещи. Потому что бизнес-модель Скайпа заключается в предоставлении дешевых платных звонков на обычные телефоны. Чтобы не остаться без штанов, и в то же время предоставлять бесплатные звонки с компутера на компутер, они вынуждены гнать траффик не через сервера.
А бизнес-модель гуглотолка заключается в том, чтобы 1) привести всех на gmail 2) рассказать гуглу, кто с кем знаком 3) за счет этого увеличить качество контекстной рекламы. На рекламе гугл зарабатывает столько, что ему все равно, как ходит траффик.
Pzz>>Обрати внимание, что для Мака есть опенсорсовые драйвера, хотя этого никто специально не енфорсит. C>Интересно, сколько их там всего?
Я не знаю. Но у Мака меньше разнообразие железа, т.к. вендор ровно один.
Re[4]: Ответ сразу всем опенсорсникам, ведущим со мной тут д
Ну правда — лень
M>>>C точки зрения пользователя: M>>>- очень легко загнать IE в GDI handle limit (где-то на 200-м табе что-ли)
KV>>Честно — тяжело могу себе представить, зачем мне открывать 200 табов. Я и 20 — крайне редко достигаю.
M>Я тоже Но у нас по работе некоторым приходится M>Ну и в ЖЖ недавно пробегало — кто сколько держит табов открытыми. Довольно много было таких, кто не меньше 150 держит открытыми
ок, надо будет протестить. просто интересно
M>>>Для себя я лично решил так:
M>>>- Опера для всего M>>>- Файрфокс для разработки M>>>- ИЕ для проверки результатов разработки и на тот 0,001% случаев, когда сайт действительно IE-only (ActiveX там..)
KV>>И согласно моей логике — трижды заниженный уровень безопасности на машине
M> Проблем не было ни разу.
Здравствуйте, DOOM, Вы писали:
DOO>Caps Lock — это исторический метод переключения, который был придуман задолго до появления первых версий винды. Почему же MS это проигнорировал, заставив пользователя менять привычки — загадка.
Метод Alt+F10 был придуман еще раньше. CapsLock впервые появился где-то в драйвере alfa (именно так, через f). А мы использовали драйвер клавиатуры, отзывавшийся на RightShift — RUS, LeftShift — LAT. С тех пор мне именно такой раскладки не хватает. Хотя понимаю, если работать более, чем с двумя языками одновременно, это неудобно.
). Просто для IO предусмотрена возможность отложить выполнение запроса в worker thread.
