Comments 15
А что из С++17 реально используется?
С первого взгляда, там и С++11 могло бы хватить, но я пару файлов всего глянул.
С первого взгляда, там и С++11 могло бы хватить, но я пару файлов всего глянул.
Мелочи, типа [[fallthrough]]. В ядерном коде с нововведениями не разойтись, но выставил сразу поддержку последнего черновика C++ (формально, уже C++20), чтобы при попытке обновить стандарт не возникло неприятных неожиданностей и варнингов. 99%, конечно же, C++11.
Так оно того стоило? Далеко не все горят желанием и возможностью обновлять тулчейн по желанию. Может, стоило макросом закрыть для «бедных»?
Что кстати с клангом для сборки драйверов, не знаете? Там по моему с SEH у них нестыковки по прежнему.
Что кстати с клангом для сборки драйверов, не знаете? Там по моему с SEH у них нестыковки по прежнему.
Я сторонник использования новейшего стека технологий, и использование устаревшего стандарта было бы ударом по моим перфекционистическим чувствам) А вообще, коль скоро драйвера в подавляющем количестве пишут на C без плюсов, уже сам факт использования C++ в API может добавить неудобств тем, кто захочет перенести часть функций в уже существующий продукт. А если писать с нуля — тогда и смысла нет привязываться к старым стандартам, когда ничто не мешает сразу использовать всё самое новое.
Про клэнг ничего не могу сказать — не пробовал. Но, судя по постам на unknowncheats, им успешно собирают драйвера с поддержкой STL из коробки. А как разруливают исключения — не знаю. Но, раз клэнг используют в ядре, с сехами проблем быть не должно. С другой стороны, какие есть причины собирать им ядерные модули и не лучше ли использовать официальный тулчейн?
Про клэнг ничего не могу сказать — не пробовал. Но, судя по постам на unknowncheats, им успешно собирают драйвера с поддержкой STL из коробки. А как разруливают исключения — не знаю. Но, раз клэнг используют в ядре, с сехами проблем быть не должно. С другой стороны, какие есть причины собирать им ядерные модули и не лучше ли использовать официальный тулчейн?
Я правильно понимаю, что это предназначено исключительно для прототипирования и ни в коем случае нельзя оставлять на production?
Зависит от используемого функционала. Например, функции для работы с IO, MSR, чтение\запись памяти (в т.ч. ядерной) совершенно безопасны для продакшна и сделаны со всеми необходимыми проверками и ловушками исключительных ситуаций (например, с учётом, что приложение может попытаться освободить память или поменять её права доступа, пока мы с ней работаем). Но функции для, скажем, прямых манипуляций с Mdl небезопасны по самой своей сути: если приложение создало отображение и по каким-то причинам закрылось, не сделав анмаппинг — гарантированно получим BSOD при попытке отдать системе смапленные адреса. Такие функции я бы не рекомендовал использовать в юзермодном коде в реальных продуктах. Нужно смотреть, что именно требуется сделать и какие вообще пути для решения есть.
Что касается ядерной части, вполне можно использовать драйвер или API как готовый шаблон для написания своих ядерных компонентов в продакшн.
Если интересует надёжность каких-то конкретных частей драйвера — спрашивайте, обсудим.
Что касается ядерной части, вполне можно использовать драйвер или API как готовый шаблон для написания своих ядерных компонентов в продакшн.
Если интересует надёжность каких-то конкретных частей драйвера — спрашивайте, обсудим.
Честно говоря, вопрос был, скорее, риторический. :) Просто при первом взгляде напомнило описываемое в статье Драйвер компьютерной игры Street Fighter V отключает встроенный механизм защиты Windows, поэтому мне показалось, что было бы полезно описать некие меры предосторожности, которые, вероятно, есть. То есть речь не только о safety, но в большей мере о security.
К слову, такой же способ исполнения пользовательского кода в Ring0 используется и у меня: отключаем SMEP, сохраняем FPU-контекст и прыгаем на юзермодный код внутри __try..__except-блока (см. KbExecuteShellCode). А сейчас пишу обновление, чтобы напрямую работать с PTE-записями из юзермода (т.е., сможем открыть юзермоду всё ядерное пространство). С точки зрения секьюрности — полное ай-ай-ай! Но основная цель драйвера и заключается в том, чтобы максимально упростить выполнение необходимого кода в ядре и делать то, что нельзя.
ХР64 поддерживается? Собирать можно Mingw64? Есть желание скрестить с открытыми дровами на радеон с полярисом.
Mingw работает на ХР, есть пакеты и для линукса, т.е. разработку можно вести где угодно. Я пропустил момент, когда можно было купить новые gtx 960/970 за небольшие деньги, сижу пока с радеоном 6850.
Проект — перенос открытых драйверов для радеон полярис.
Этот проект актуален и для владельцев 7ки — через год и она устареет.
Проект — перенос открытых драйверов для радеон полярис.
Этот проект актуален и для владельцев 7ки — через год и она устареет.
А почему именно ХР? Судя по карте, железо позволяет обновиться до Win10 и использовать официальный тулчейн без проблем, не заморачиваясь с поддержкой легаси. Или проблема именно в специфике открытых драйверов?
Sign up to leave a comment.
The Kernel-Bridge Framework: мостик в Ring0