Комментарии 101
Спасибо, мож когда пригодится
НЛО прилетело и опубликовало эту надпись здесь
И как же вы предлагаете контролировать размер стека? Что делать при переполнении? Обычное приложение можно довольно спокойно прибить, а вот с ядром вряд ли такое получится.
Кстати, вот неплохая ссылка, где объясняются причины введения такого ограничения:
msmvps.com/blogs/kernelmustard/archive/2004/08/30/12543.aspx
Да, насколько я знаю, в линуксе стек ядра тоже ограничен, только не 12К, а то ли 8К, то ли 4К.
Кстати, вот неплохая ссылка, где объясняются причины введения такого ограничения:
msmvps.com/blogs/kernelmustard/archive/2004/08/30/12543.aspx
Да, насколько я знаю, в линуксе стек ядра тоже ограничен, только не 12К, а то ли 8К, то ли 4К.
НЛО прилетело и опубликовало эту надпись здесь
Узнать — не проблема. А как контролировать? Ну вот хочет некий код в ядре разместить что-то на стеке, а стек кончился. Что делаем?
Пишем «Kernel BUG: fucking buggy driver «name»», где name — название модуля, сожравшего больше стековых записей, чем остальные.
Как-нибудь так, например…
Как-нибудь так, например…
Чтобы написать это тоже нужно вызвать какие-то функции, а стек, на минуточку, уже кончился. Вызвать никакую функцию нельзя. Создавать никаких пеерменных нельзя. Неизвестно, в каком стостоянии в данный момент находится система — может, стек кончился как раз в процессе вывода какого-то сообщения и мы новым вызовом загоним все в глубокую рекурсию. Ну и?
В том же Линуксе (размер стека 8КБ), узнать текущую заполненность стека можно всегда, достаточно проделать операцию AND c ESP и 0xFFFFF000.
И что это даст? Проблема-то не в том, чтобы узнать, что стек кончился, а в том, что делать в такой ситуации.
Вы двумя постами выше спросили как контролировать стек. Я показал способ которым программист может контролировать использование стека. Что делать? Оптимизировать! Даже 4КБ стека это очень много. При правильном подходе этого более чем достаточно.
В моей терминологии вы показали, как «узнать», а не как «контролировать». :)
Речь ведь шла о том, что система не должна падать при нехватке места. Вот я и написал, что узнать о такой нехватке легко, а «контролировать» поведение кода, который в этом виноват — сложно. Сам код должен уметь вести себя хорошо, чтобы не завалить систему. В этом я с вами абсолютно согласен. А сделать универсальную защиту от плохого кода невозможно.
Речь ведь шла о том, что система не должна падать при нехватке места. Вот я и написал, что узнать о такой нехватке легко, а «контролировать» поведение кода, который в этом виноват — сложно. Сам код должен уметь вести себя хорошо, чтобы не завалить систему. В этом я с вами абсолютно согласен. А сделать универсальную защиту от плохого кода невозможно.
Я не о том. Вы выше написали что возможна ситуация когда неизвестно в каком состоянии находится система и узнать это, возможно, уже нельзя, так как мы неможем создать переменные, вызвать функции и вообще вгоним себя в рекурсию. Я же вам написал о том, как в любом случае можно узнать о состоянии стека в Linux, вот и все.
По-поводу система недолжна падать, невозможно универсальную защиту и т.п. я думаю тут с вами все согласны :)
По-поводу система недолжна падать, невозможно универсальную защиту и т.п. я думаю тут с вами все согласны :)
НЛО прилетело и опубликовало эту надпись здесь
Вы, видимо, плохо себе представляете, о чем идет речь. Драйвер закрыть не выйдет — это вам не просто приложение, он работает как часть ядра. Если взять ваш пример с бутербродами, то человек чтобы не подавиться должен вовремя отрубить себе руки, которые суют бутерброды в рот.
А переполнение буфера — совсем из другой оперы.
А переполнение буфера — совсем из другой оперы.
НЛО прилетело и опубликовало эту надпись здесь
К переполнению чего может привести еще не запущеный драйвер? Мы тут про стек, вроде, говорили. То есть, про код, который уже выполняется. Причем переполнение стека может произойти вовсе не в драйвере, а в самом ядре. Что-то вы весьма странно выражаетесь.
НЛО прилетело и опубликовало эту надпись здесь
А откуда мы узнаем сколько будет драйвер жрать? Машину времени в каждый комп встраивать?
prefast знаете? Статические средства анализа кода еще никто не отменял.
Статические средства анализа дают порядком как ложных срабатываний, так и пропусков. Задачку соответсвующую знаете?
Так неизвестно же заранее, кто сколько жрет. Речь о размере стека, а не кода. Разницу между ними знаете?
НЛО прилетело и опубликовало эту надпись здесь
Судя по тому, что вы пишете выше, вы совершенно не представляете, что такое стек и для чего он нужен.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Не ругайте сильно человека, он только на первом курсе и прошёл только «Типы и структуры данных», а ассемблер у него будет на втором курсе. :-)
У Аркадия и Бориса Стругацких есть замечательная цитата:
Ubi nihil vales, ibi nihil velis (где ты ни на что не способен, там ты не должен ничего хотеть).
Поэтому нет нужды с такой агрессивностью бросаться переводить стрелки на Microsoft (якобы они недосмотрели), когда не понимаешь, о чём идёт речь.
У Аркадия и Бориса Стругацких есть замечательная цитата:
Ubi nihil vales, ibi nihil velis (где ты ни на что не способен, там ты не должен ничего хотеть).
Поэтому нет нужды с такой агрессивностью бросаться переводить стрелки на Microsoft (якобы они недосмотрели), когда не понимаешь, о чём идёт речь.
Так это вы вместо того, чтобы попробовать разобраться в предмете спора, делаете высказывания, говорящие о вашей некомпетентности.
То что вы говорите о стеке, в принципе, правильно. Только это не тот стек, о котором сейчас идет речь. Если действительно интересно разобраться, почитайте где-нибудь, как на практике реализуется вызов функций и хранение локальных переменных. Никакого отношения к стеку-контейнеру из языков высокого уровня это не имеет.
То что вы говорите о стеке, в принципе, правильно. Только это не тот стек, о котором сейчас идет речь. Если действительно интересно разобраться, почитайте где-нибудь, как на практике реализуется вызов функций и хранение локальных переменных. Никакого отношения к стеку-контейнеру из языков высокого уровня это не имеет.
Гыгы. По поводу наездов и спрово позволю себе процитировать Вас, глубокоуважаемый:
habrahabr.ru/blogs/microsoft/43143/#comment_1068371
Скажу так, что бы такой недоразвитый индивидум, страдающий гермофродитизмом как ты, понял меня. ТЫ ДЫБИЛ И ТВОЕ МЕСТО НА ПАМОЙКЕ! ТЫ МОЖЕШЬ КУПИТЬ 5 ДИПЛОМОВ, НО К ВСЕОБЩЕЙ РАДОСТИ НЕСПОСОБЕН КУПИТЬ ДАШ МАЛУЮ ДОЛЮ МОЗГА!..
ИДИ ВЫЕБИ СЕБЯ В ЗАД ВАНТУСОМ.
habrahabr.ru/blogs/microsoft/43143/#comment_1068371
Скажу так, что бы такой недоразвитый индивидум, страдающий гермофродитизмом как ты, понял меня. ТЫ ДЫБИЛ И ТВОЕ МЕСТО НА ПАМОЙКЕ! ТЫ МОЖЕШЬ КУПИТЬ 5 ДИПЛОМОВ, НО К ВСЕОБЩЕЙ РАДОСТИ НЕСПОСОБЕН КУПИТЬ ДАШ МАЛУЮ ДОЛЮ МОЗГА!..
ИДИ ВЫЕБИ СЕБЯ В ЗАД ВАНТУСОМ.
Это всё доводы в пользу микроядер. На практике разница невелика: ну убъёте вы драйвер сетевухи в тот момент, когда он заблокирует 100MB памяти, что дальше? Комп, скорее всего, придётся перезагружать…
P.S. Почему ядро не сможет освободить память? Очень просто: куча современных устройств (в том числе сетевухи, адаптеры НЖМД, видеокарты и прочая) используют DMA, что обозначает что без общения с драйвером захваченную им память лучше не освобождать, а если он помер, то power cycle — практически единственный выход.
P.S. Почему ядро не сможет освободить память? Очень просто: куча современных устройств (в том числе сетевухи, адаптеры НЖМД, видеокарты и прочая) используют DMA, что обозначает что без общения с драйвером захваченную им память лучше не освобождать, а если он помер, то power cycle — практически единственный выход.
Не единственный. Если например были выделенны области памяти для DMA трансферов с сетевой картой, и контроллер уже настроен и сыпет прерывания, то можно просто рестартнуть контроллер и он забудет обо всех DMA дескрипторах, о которых знал :) Это ситуация, которая специфична для конкретного железа, по этому самый простой выход — иметь отдельную функцию резета контроллера, в случае если драйвер посыпался и его надо выгрузить. Функцию такую, необходимо размещать отдельно в памяти от драйвера, чтобы драйвер можно было без ущерба выгрузить.
И это лишь как пример. Таких можно придумать сотни. Ведь если драйвер где-то помрет, то случившийся какой-нибудь интеррапт лукап и глобальный фриз всея системы, ситуацию никак не спасет.
И это лишь как пример. Таких можно придумать сотни. Ведь если драйвер где-то помрет, то случившийся какой-нибудь интеррапт лукап и глобальный фриз всея системы, ситуацию никак не спасет.
Если например были выделенны области памяти для DMA трансферов с сетевой картой, и контроллер уже настроен и сыпет прерывания, то можно просто рестартнуть контроллер и он забудет обо всех DMA дескрипторах, о которых знал :)Он может много о чём забыть. Даже если всего лишь 10GBit контроллер. А если это WiFi или ADSL-модем, то он может вообще отказаться работать после ресета просто потому что противоположная сторона откажется с вами общаться — по крайней мере на протяжении некоторого времени. Нужна длительная и сложная процедура реинициализации… А если вы используете iSCSI…
В общем функция восстановления работоспособности устройства зачастую крайне непроста и вовсе не факт что простое решение (убить и перезагрузить всю систему) не является наилучшим выходом — даже в случае микроядра. А если у вас не микроядро — так это точно самый разумный выход.
А никто и не говорил, что это панацея. Это может помочь в большом количестве случаев, но не во всех. Гигабитные сетевые контроллеры, тв тюнеры, звуковые карты находят гораздо больше применений нежели ADSL модемы (они вообще внешние, и все USB драйвера давно пора вынести в USER space, что уже потихоньку делается) и iSCSI контроллеры (а WiFi драйвера после релоада отлично подхватывают базу :) ).
Если брать такие экзотические случаи как iSCSI, то на серверах такого уровня стабильность должна быть очень высокой, и драйвер просто не имеет право падать :)
Если брать такие экзотические случаи как iSCSI, то на серверах такого уровня стабильность должна быть очень высокой, и драйвер просто не имеет право падать :)
Мальчик, иди делать уроки. И не мешай дядям обсуждать важные проблемы.
Либо кидать багчек, либо анлоадить драйвер.
Та же Vista не прощает многих ошибок, которая прощала ХР, например ошибок с IRQL'ями (вызов функции на DISPATCH, когда нужно на PASSIVE).
Та же Vista не прощает многих ошибок, которая прощала ХР, например ошибок с IRQL'ями (вызов функции на DISPATCH, когда нужно на PASSIVE).
Анлоадить драйвер — это оставить потенциальную дырку в безопасности системы. Т.е. можно (потенциально) убить любой драйвер (а он может что-то там защищать) в системе переполнив его стек…
Я вас умоляю, код работающей в режиме ядра, найдет уйму других возможностей для перехвата, подмены, маскировки и прочего, не трогая ваш драйвер. А стек еще аккуратно надо уметь переполнять, дабы не завалить систему полностью.
И ваше предложение анлоадить драйвер как раз оставляет возможность аккуратно переполнить стек и выключить драйвер из цепочки обработчиков без уведомления прикладных программ, которые могут требовать наличие этого драйвера для соблюдения безопасности. Уж лучше обрушить систему…
Не стоит к «уйме возможностей» добавлять еще одну.
Не стоит к «уйме возможностей» добавлять еще одну.
Простите, я, может, чего и не понял, но о каких дыркам в безопастности системы идёт речь, если мы (злоумышленники) уже можем выполнять код в режиме ядра?
Очень просто: вы можете убить какой-нибудь чужой драйвер, который в этот момент используется каким-нибудь LSASS'ом… Ожидать что люди, пишущие драйвера будут об этом думать по меньшей мере наивно…
Я имею ввиду, если у нас уже доступ к ядру, то машина уже наша, какя разница, как убивать другой драйвер?
Драйвера зачастую можно убить не имея доступа к ядру. Просто, скажем, всунув флешку или CD с «правильным образом изувеченной» файловой системой (был подобный бажок в драйвере iso9660 — его вроде исправили, но кто сказал что он — последний?)…
Мы говорим о разных вещах.
Я утверждал, что высказывание «Анлоадить драйвер — это оставить потенциальную дырку в безопасности системы. Т.е. можно (потенциально) убить любой драйвер (а он может что-то там защищать) в системе переполнив его стек… » не справдедливо, ибо, если злоумышленник имеет доступ к ядру, то говорить о дырках в безопасности глупо — машина уже принадлежит злоумышленнику.
Я утверждал, что высказывание «Анлоадить драйвер — это оставить потенциальную дырку в безопасности системы. Т.е. можно (потенциально) убить любой драйвер (а он может что-то там защищать) в системе переполнив его стек… » не справдедливо, ибо, если злоумышленник имеет доступ к ядру, то говорить о дырках в безопасности глупо — машина уже принадлежит злоумышленнику.
Это все видимо сугубо индивидуально, но я не считаю это серьезным упущением при всей дырявости IA32 архитектуры: когда можно с легкостью сделать коллгейт из юзермода в кернел мод и хукнуть обработку syscall'ов, или повесить свой обработчик smi и творить все что угодно (это ведь по сути режим с такими же правами, как и real/protected mode).
«Возможность с лёгкостью сделать коллгейт из юзермода в кернелмод или повесить обработчик SMI» — это дырявость не IA32, а Windows. И как и любые дыры в программах эти дыры могут быть залатаны. То, что это непросто не повод создавать дополнительную кучу дыр…
Это не дыры в Windows, имея root access в *nix можно сделать тоже самое, потому как можно легко замапить любой кусок физической памяти.
Если вы имеете root access, то вы имеете всю систему — так устроен *nix (есть, правда, SELinux, но он пока сыроват). Но в Linux можно спокойно работать не имея root'ового доступа, а в Windows — только в теории, на приктике не получается…
У вас странная практика. Всё, что надо, делаю из под Limited аккаунта в XP. Программы, которые не поднимаются (некоторые игры, серьёзные пакеты типа SPSS) запускаются без сложностей через Run As…
В Vista вообще никаких проблем.
В Vista вообще никаких проблем.
Я знаю одно крупное предприятие с несколькими десятками тысяч работников в нескольких странах, на котором используются практические одинаковые Lenovo-PC с установленной Windows XP, пользователи которых имеют только пользовательский доступ к компу c кучей ограничений, и, знаете, это предприятие успешно функционирует несколько лет, и я не слышал ещё ни об одном случае «заражения вирусами» на нём. Вот вам практика :)
Подсчитать сколько нам нужно памяти в стеке для того, чтобы вывести сообщение об ошибке и опустить планку допустимого размера стека на соответствующую величину (т.е. всегда оставлять небольшой запас для сообщения о том, что стек кончился).
Или такое поведение не может быть реализовано?
Или такое поведение не может быть реализовано?
Снова не поняли. Ладно, пусть у нас есть запас и сообщение мы можем попробовать вывести. С риском впасть в рекурсию — ведь при новом вызове мы снова увидим, что стек кончается и снова попытаемся об этом сообщить. Но, допустим, это мы как-то побороли.
Что дальше делать с тем кодом, которому не хватило стека? Продолжать работать он не может. Убить его нельзя — это и есть ядро. Выводим сообщение и останавливаем систему? Так именно это и делается.
Что дальше делать с тем кодом, которому не хватило стека? Продолжать работать он не может. Убить его нельзя — это и есть ядро. Выводим сообщение и останавливаем систему? Так именно это и делается.
Как раз таки вы меня не поняли :)
То что систему при переполнении стека «уже не спасти» — это и так понятно. Я говорил о том, что вполне возможно организовать какие-то действия, которые будут предприняты перед падением ядра (своего рода «завещание») — вывод сообщения, сохранение дампа памяти и т. д. То есть это всё вполне делается. Мой предыдущий комментарий — мое несогласие с тем, что якобы нельзя делать то, что выше предложил stolen.
То что систему при переполнении стека «уже не спасти» — это и так понятно. Я говорил о том, что вполне возможно организовать какие-то действия, которые будут предприняты перед падением ядра (своего рода «завещание») — вывод сообщения, сохранение дампа памяти и т. д. То есть это всё вполне делается. Мой предыдущий комментарий — мое несогласие с тем, что якобы нельзя делать то, что выше предложил stolen.
Ваша проблема в том, что вы не разбираетесь в вопросе… Ваша среда это веб — php,css,htm etc… вы думаете, что все так просто и легко, а на самом деле все уже за нас обдумали и сделали… гораздо более умные умы.
А кто его контролировать-то будет? Это же ядро.
Так и есть, ядрёный стек — две или одна страницы.
Интересная ссылка, узнал новое.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
чуток обновил статью, написал пару слов про Double Fault
Спасибо за статью, думаю, что пригодиться. На самом деле, лучше при старте выделять какой-нибудь пул и уже покусочку откусывать данные оттуда.
Сам сейчас пытаюсь отладить драйвер. Иногда зачастую при заходе в NdisMIndicateReceivePackets система просто зависает без единого багчека :)
Сам сейчас пытаюсь отладить драйвер. Иногда зачастую при заходе в NdisMIndicateReceivePackets система просто зависает без единого багчека :)
может я чего то не понимаю, но зачем ложить массивы в стек?
НЛО прилетело и опубликовало эту надпись здесь
опять же, может я чиво то не понимаю, да я собственно и не знаю что вы там делаете, но мне вот интерестно, неужели обращение к данным в куче медленее чем к данным в стеке? почему бы при инициализации драйвера, как уже кто то выше писал, не выделить страничку-другую сразу под данные и потихоньку писать/читать от туда?
НЛО прилетело и опубликовало эту надпись здесь
под виндоус никада драйверов не писал, но осмеюсь предположить что там тоже можно выключить прерывания, создав таким образом критическую секцию и проблема синхронизации потоков лишится. если память заканчивается — алгоритм динамического массива. сначала поднатужится чуток, потом станет попроще. и еще, я так понял, что у вас несколько потоков и у каждого в стеке массив? если они не зависимы ничто не помешает так же выделить память при инициализации каждого потока, т.е каждому например по 4к (получатся разные страници) и тогда ниче синхронизировать не надо будет. вопщем очень тяжело говорить о чем либо не зная вашей задачи :) а за инфу спасибо, может когда нибудь понадобиться
под виндоус никада драйверов не писал, но осмеюсь предположить что там тоже можно выключить прерывания, создав таким образом критическую секциюЕсли займётесь подобным в обработчике прерываний то с большой вероятностью получите не критическую секцию, а Deadlock.
и еще, я так понял, что у вас несколько потоков и у каждого в стеке массив? если они не зависимы ничто не помешает так же выделить память при инициализации каждого потока, т.е каждому например по 4кОтличная идея! Гениальная! А если у вас 10'000 потоков? Тяжёлые Java-программы и больше могут породить. Угробить 40MB оперативки только на то, чтобы один массив в пару килобайт там завести?
Нет, вероятнее всего потребуется заводить по массиву на процессор или пул завестии следить за тем, чтобы они вовремя освобождались выделялись. В общем много радостей.
не надо мне приводить ссылки, я прекрасно знаю что такое deadlock. а критическая секция (сritical section) — это один из способов его избежать, думаю следуя вашей же ссылке все найдется.
речь идет о ядре, откуда там у вас тяжелые ява программы? бред какойто. я так и не понял вашу схему — то ли у вас один поток с массивом в стэке и он переполняется, толи у вас там несколько трэдов и у каждой свой массив, я запутался. поделитесь пожалуйста, если не секрет, что и как!
и объясните, если не сложно, почему выключение _фсех_ прерывание в обработчике приведет к деадлоку
речь идет о ядре, откуда там у вас тяжелые ява программы? бред какойто. я так и не понял вашу схему — то ли у вас один поток с массивом в стэке и он переполняется, толи у вас там несколько трэдов и у каждой свой массив, я запутался. поделитесь пожалуйста, если не секрет, что и как!
и объясните, если не сложно, почему выключение _фсех_ прерывание в обработчике приведет к деадлоку
не надо мне приводить ссылки, я прекрасно знаю что такое deadlock. а критическая секция (сritical section) — это один из способов его избежать, думаю следуя вашей же ссылке все найдется.Дьявол, как всегда, в деталях. В обработчике прерываний прирывания уже запрещены — но в этом-то и беда. Если вы возжелаете обратиться к странице памяти, которая, скажем, живёт на диске, а прерывания запрещены — получите классический deadlock и никто вам не поможет. То, что вы называете critical section в обычных, не ядерных программах прерываний не запрещает, так что там такие финты невозможны.
…
и объясните, если не сложно, почему выключение _фсех_ прерывание в обработчике приведет к деадлоку
речь идет о ядре, откуда там у вас тяжелые ява программы?Тяжёлые ява-программы будут исполняться на компьютере, а не в ядре, конечно. Но для каждого потока в тяжёлой ява-программе будет создан отдельный поток ядра (отсюда, собственно, эти драконовские ограничения на размер стека). Есть ещё отдельные потоки для обслуживания прерываний но создаются и убиваются системой, с ними всё ещё сложнее. Собственно «нормальным» программистам очень тяжело писать «ядрёные вещи» (в частности драйвера) ибо они привыкли контролировать ситуацию — а ядро ситуацию нифига не контролирует. Контролирует всё программы, запущенные на компе, я ядро — это Фигаго: им командуют два господина. Программы, запущенные на компьютере и железо — а оно пытается им всем угодить. Иногда не получается и тогда «тарелки сыплются на пол».
Дьявол, как всегда, в деталях. В обработчике прерываний прирывания уже запрещены — но в этом-то и беда. Если вы возжелаете обратиться к странице памяти, которая, скажем, живёт на диске, а прерывания запрещены — получите классический deadlock и никто вам не поможет.Это все детали реализации. Можно выделить память в NonPagedPool и легко с ней работать.
Да и вообще, если вернутся к оригинальному вопросу: большинство драйверов однопоточны и синхронизацию доступа к общему пулу выполнять не нужно. Если все-таки они многопоточны, то можно использовать те же спин локи. И они не дороги, если вы не используйте их очень часто. А если используете часто, то имеет место быть множественные частые аллокации памяти, и этот случай надо оптимизировать отдельно, и возникает он редко, потому как частые аллокации памяти — уже не есть гуд, они сьедают много перфоманса.
Ну не надо мне рассказывать про решения этих проблем — на эту тему куча книжек написана. Умных и не очень. И, разумеется, там есть много решений этих проблем — с разными плюсами и минусами. Речь тут шла про то, что при программировании внутри ядра про многие приёмы и привычки из userspace программирования нужно забыть.
Всё как бы просто: программы в userspace имеют «старшего брата» — ядро. Оно и поможет и научит и, в случае чего, по ушам надаёт. А в ядре межда вами и железом — хиленький набор функций и всё. Микроядра дают чуть бо́льшую защиту, но разница не кардинальная…
На самом деле микроядра — это вообще шаг не в ту сторону. В 90% случаев «зависший комп» — это не компьютер где запаниковало ядро. BSOD'ы и kernel panic в последнее время не так часто случаются. Но с точки зрения обычного пользователя «сдохший» rpc-helper (Windows) или какой-нибудь nscd-сервер (Linux) — это «сдохший комп»! И тут дела обстоят куда хуже, чем с ядром. Хватит вам уже заниматься ядром — разберитесь лучше с остальной системой!!!
Всё как бы просто: программы в userspace имеют «старшего брата» — ядро. Оно и поможет и научит и, в случае чего, по ушам надаёт. А в ядре межда вами и железом — хиленький набор функций и всё. Микроядра дают чуть бо́льшую защиту, но разница не кардинальная…
На самом деле микроядра — это вообще шаг не в ту сторону. В 90% случаев «зависший комп» — это не компьютер где запаниковало ядро. BSOD'ы и kernel panic в последнее время не так часто случаются. Но с точки зрения обычного пользователя «сдохший» rpc-helper (Windows) или какой-нибудь nscd-сервер (Linux) — это «сдохший комп»! И тут дела обстоят куда хуже, чем с ядром. Хватит вам уже заниматься ядром — разберитесь лучше с остальной системой!!!
Простите, но вы тоже вдаетесь в пространные обсуждения, которые не имеют отношения к теме :)
Так или иначе, если говорить о микроядрах… С точки зрения пользователя, главное чтобы все работало. Если вдруг издох rpc-helper, то система должна его сама восстановить (службы ведь она кое как поднимает). Вопрос рекреации системы, ядра, драйвера и т.д. очень важен и его давно изучают на равне с темой микроядер. Как показала теория, главное правильное проектирование и реализация. Что покажет практика — покажет будущее.
Так или иначе, если говорить о микроядрах… С точки зрения пользователя, главное чтобы все работало. Если вдруг издох rpc-helper, то система должна его сама восстановить (службы ведь она кое как поднимает). Вопрос рекреации системы, ядра, драйвера и т.д. очень важен и его давно изучают на равне с темой микроядер. Как показала теория, главное правильное проектирование и реализация. Что покажет практика — покажет будущее.
А оно уже научилось русскоязычные имена XML тегов понимать? Или так, до сих пор инглиш онли?
Эх, а ведь есть хорошие разработки (и будут) связанные с настоящими микроядрами, так что будем надеятся на светлое будущее, когда микроядра будут не только на железках где нужен риалтайм, а на десктопах…
Микроядра на десктопе смысла не имеют ибо DMA. Если изменить спецификацию — то всё может быть, но кто будет этим заниматься и зачем?
Ну понятно, что до десктопов ещё далеко… Сейчас на рынке микроядер основной игрок это qnx, ибо реалтайм. У линукса к сожалению, не смотря на всякие патчи, с риалтаймом всё плохо. Вообще вот проектик jarios.org/, который метит стать open source альтернативой qnx.
на самом деле помимо qnx есть еще довольно много микроядер. вот это разрабатывается главным образом в нашем унивре, есть целое семейство таких микроядер с отличиями в реализации. по личному опыту могу сказать что вполне работоспособно, под него легко писать, есть даже pre-virtualization проект, линукс очень не плохо работает сверху. кстати, если не ошибаюсь, дма у нас реализован :) это не проблема для микроядра
Ну я слышал немного о l4, и единственное мнение: «нафиг c++» :) Ну суть не в этом, суть в том, что потихоньку помаленьку ядра развиваются, так что может быть когда-нибудь…
В таком случае лучше вообще не использовать стек. Если этот ресурс непредсказуем и не контролируем. Передача параметров — через регистры, статические массивы — все вынесены в сегмент данных (сегмент данных то у драйверов есть?).
регистров не напасешься :(
Это смотря как их использовать. Если туда тупо все пихать — возможно и нет.
Выделяете в сегменте даных виртуальный стек, в который у вас влезет все что нужно передать. Делаете передачу параметров хитро — например до N просто через регистры, при >N два регистра отдаете на работу с виртуальным стеком. В одном храните начало, в другом — количество записей. Или можно сделать структурированное хранилище. В любом случае вы знаете заранее — сколько вам нужно места под параметры, и если это сделать на уровне компилятора — то даже вручную считать не понадобится. Где-то такое даже было сделано (новое хорошо забытое старое), но слишком уж хорошо забыто — не припомню никак где :)
Выделяете в сегменте даных виртуальный стек, в который у вас влезет все что нужно передать. Делаете передачу параметров хитро — например до N просто через регистры, при >N два регистра отдаете на работу с виртуальным стеком. В одном храните начало, в другом — количество записей. Или можно сделать структурированное хранилище. В любом случае вы знаете заранее — сколько вам нужно места под параметры, и если это сделать на уровне компилятора — то даже вручную считать не понадобится. Где-то такое даже было сделано (новое хорошо забытое старое), но слишком уж хорошо забыто — не припомню никак где :)
Нет, ну 10 Кб стека это правда много. Зачем столько использовать?
На всякий случай отвечу — для будущих поколений
"!analyze -v" для double fault-ов прямым текстом говорит: «возможно у вас переполнился стек» — стоит читать что говорит отладчик
Во-вторых, ограниченность kernel-mode стека — одна из первых вещей, которые узнает kernel-developer. Непонятно, как так получилось, что ни Вы ни Ваш «более опытный товарищ» этого не знали
Ну и в-третьих KeExpandKernelStackAndCallout. Хотя для этого придется подождать пока XP сойдет со сцены (надеюсь недолго осталось). А пока — WorkItem-ы/Worker thread-ы и вперед
"!analyze -v" для double fault-ов прямым текстом говорит: «возможно у вас переполнился стек» — стоит читать что говорит отладчик
Во-вторых, ограниченность kernel-mode стека — одна из первых вещей, которые узнает kernel-developer. Непонятно, как так получилось, что ни Вы ни Ваш «более опытный товарищ» этого не знали
Ну и в-третьих KeExpandKernelStackAndCallout. Хотя для этого придется подождать пока XP сойдет со сцены (надеюсь недолго осталось). А пока — WorkItem-ы/Worker thread-ы и вперед
Вот, информация, которая касается лимитов на размер стека — msdn.microsoft.com/en-us/library/windows/hardware/ff565536(v=vs.85).aspx. В ядре существует различные лимиты. Интересным является поведение при нехватке памяти подкачиваемой или неподкачиваемой. Может, например, быть BSOD 0x000000F4, когда один из системных процессов не смог выделить память тогда как в User Mode это все заканчивается лишь сообщением об ошибке, позже мы можем удалить процесс который вызвал утечку и работать в системе далее. Я веду к тому, что программирование в kernel mode — это большая ответственность за код, поэтому нужно очень внимательно относится ко многим вещам. Меня, например, поражает то, как иногда пишется ПО для kernel mode, например, в некоторых антивирусах в драйверах вычисляется md5 файлов и т.д. Бр-р-р.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Маленькая, но очень коварная засада с программированием в kernelspace-е в ОС MS Windows