Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 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