Кто-нибудь пользует OACR при сборке под WDK? От него есть какой-то толк? Если у меня проекты с незапамятных времен собираются с /W4 /Wp64 /Wall — он может к этому добавить что-нибудь полезное?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Кто-нибудь пользует OACR при сборке под WDK? От него есть какой-то толк? Если у меня проекты с незапамятных времен собираются с /W4 /Wp64 /Wall — он может к этому добавить что-нибудь полезное?

Да, может. Особенно, если не поленится и написать нормальные SAL нотации ( не просто __in и __out ) ко всем функциям. Но даже и без этого — все равно может. К примеру найдет забытое освобождение спинлока. Но учитывая, что имеется "традиционное недовольство любовью MS к черезжопным и ненадежным решениям вместо простых и надежных!", это доставит только батхерт и очередное недовольство . Так что смело отключай .

Здравствуйте, <Аноним>, Вы писали:

А>К примеру найдет забытое освобождение спинлока.

Только в том случае, если спинлок был захвачен через KeAcquireSpinlock*, или даже тогда, когда KeAcquireSpinlock* завернут во врапперные класс или функцию?

ЕМ>Только в том случае, если спинлок был захвачен через KeAcquireSpinlock*, или даже тогда, когда KeAcquireSpinlock* завернут во врапперные класс или функцию?
За cplusplus не скажу, никогда не исользовал его. А вот если на С обернуть KeAcquireSpinlock во враппер, то можно с помощью SAL нотации указать, что возвращается захваченный объект синхронизации и будет проверено, чтобы клиент корректно его освободил. Для тех, кто пишет WDM ( или KMDF ) драйвера, есть еще более мощный тул — driver static verifier. Это статический верификатор. Он проверит все варианты вызова функции, на разных IRQL, с разными аргументами.

Здравствуйте, <Аноним>, Вы писали:

А>За cplusplus не скажу, никогда не исользовал его.

Ужас. Я уже и забыл, как в чистом C-синтаксисе писать, это ж издевательство.

А>А вот если на С обернуть KeAcquireSpinlock во враппер, то можно с помощью SAL нотации указать, что возвращается захваченный объект синхронизации и будет проверено, чтобы клиент корректно его освободил.

Не, это уже чрезмерно. Вот ежели б можно было для каждой функции указать, на каком IRQL работает она сама, и на каких IRQL ее можно вызывать, и чтоб проверялка сама трассировала все возможные пути вызова — вот это было б круто.

А>Для тех, кто пишет WDM ( или KMDF ) драйвера, есть еще более мощный тул — driver static verifier. Это статический верификатор. Он проверит все варианты вызова функции, на разных IRQL, с разными аргументами.

Почему только для WDM? Чем WDM текстуально отличается от legacy?

ЕМ>Не, это уже чрезмерно. Вот ежели б можно было для каждой функции указать, на каком IRQL работает она сама, и на каких IRQL ее можно вызывать, и чтоб проверялка сама трассировала все возможные пути вызова — вот это было б круто.
ЕМ>Почему только для WDM? Чем WDM текстуально отличается от legacy?

Обработкой PnP? А вообще, я под WDM я имел в виду драйвер железки, сделанный по все правилам WDM — c обработкой Pnp, ф. AddDevice и.т.д. ( в отличие от какого нибудь файлового фильтра, у которого используется некое специфичное API ). Потому как static verifier работает довольно тупо: у него есть набор точек входа, о которых он знает: DriverEntry, AddDevice, Dispatch, ISR. И вот он попытается начиная от точки входа пройти все возможное дерево вызовов, проверяя все условия. Как правило, все вызовы "терминиурется" на каких либо вызовах ядра, где с помошью этого вашего SAL а все описано. К примеру, из описания ExAllocatePoolWithTag

__drv_when(((PoolType&0x1))!=0, __drv_maxIRQL(APC_LEVEL))
__drv_when(((PoolType&0x1))==0, __drv_maxIRQL(DISPATCH_LEVEL))

Соответственно, при проверке через OACR он просечет, что в вызов ExAllocatePool( PagedPool .... ) может случится на DISPATCH_LEVEL, если только написать явную чушь, вроде этого вызова под спинлоком. А статик верифаер может просечь, что идет нарушение IRQL путем верификации кода.

Чем это все лучше, чем PAGED_CODE() ? Только тем, что ошибка будет найдена при компиляции и это хорошо.

Возвращаясь к "почему WDM ( и KMDF )?". К примеру, разаработчик WFP сallout драйвера лишен привилегии использования static verifier, потому как верифаер "не поймет", что точка входа задается регистрацией callout а и 95% кода — вся логика — не будет проверена, проверят только DriverEntry. То же самое касается файловых фильтров, объектовых фильтров и.т.д. На самом деле, еще NDIS miniports поддерживаются — все функции, зареганные через NdisMRegisterMiniportDriver будут верифицироваться.

Здравствуйте, <Аноним>, Вы писали:

А>Потому как static verifier работает довольно тупо: у него есть набор точек входа, о которых он знает: DriverEntry, AddDevice, Dispatch, ISR. И вот он попытается начиная от точки входа пройти все возможное дерево вызовов, проверяя все условия.

Странно, а что ему мешает получить из пользовательского конфига список этих самых точек входа для любого драйвера? Вот это я и называю "черезжопными" решениями.

ЕМ>Странно, а что ему мешает получить из пользовательского конфига список этих самых точек входа для любого драйвера? Вот это я и называю "черезжопными" решениями.

Можно и из пользовательского.
вот к примеру: ddkroot\7600.16385.1\tools\sdv\rules\WDM

Лично я не в силах так с ходу написать собственные правила верификации.

В любом случае, я же предупредил — Вас ждет батхерт

Здравствуйте, <Аноним>, Вы писали:

ЕМ>>Странно, а что ему мешает получить из пользовательского конфига список этих самых точек входа для любого драйвера? Вот это я и называю "черезжопными" решениями.

А>Можно и из пользовательского.
А>вот к примеру: ddkroot\7600.16385.1\tools\sdv\rules\WDM
А>Лично я не в силах так с ходу написать собственные правила верификации.

Так и я такое с ходу не напишу. А все потому, что подход черезжопный. Вместо того, чтобы сделать универсальное расширяемое средство, опять наспех склепали что-то однобокое и узкоспецифическое.

Вспомните, какой геморрой был с конфигурациями проектов в VS до шестой включительно, и как изящно и удобно стало с ними работать после введения наследуемых Property Sheets в VS 2003.

По-хорошему, проверялку давным-давно нужно было включить в компилятор — он-то разбирает код полностью, и дерево вызовов строит, и виртуальные функции отслеживает, и т.п. Наружу вынести правила на каком-нибудь простеньком язычке. И получился бы великий верификатор всех времен и народов, а не эти уродливые поделия, прибитые сбоку ржавыми гвоздями.

Здравствуйте, Аноним, Вы писали:

ЕМ>>Только в том случае, если спинлок был захвачен через KeAcquireSpinlock*, или даже тогда, когда KeAcquireSpinlock* завернут во врапперные класс или функцию?
А Для тех, кто пишет WDM ( или KMDF ) драйвера, есть еще более мощный тул — driver static verifier. Это статический верификатор. Он проверит все варианты вызова функции, на разных IRQL, с разными аргументами.

У него есть недостаток.Не работает с файлами *.cpp.

ЕМ> А все потому, что подход черезжопный. Вместо того, чтобы сделать универсальное расширяемое средство, опять наспех склепали что-то однобокое и узкоспецифическое.

Это все — тяжелое детство проекта. Даже само название на это намекает: OACR = microsoft Office Automated Code Review tool.

E> У него есть недостаток.Не работает с файлами *.cpp.

это достоинство )). c++ — недоразумение, ни один современный фреймворк не делает на него ставку )). Единственное достоинство плюсов — поражать воображение гиков. И вот эти пораженные люди, вместо того чтобы писать код и выполнять свои задачи, изобретают какие то неимоверные шаблоны. Любой питон по гибкости и мощности даст фору плюсам. Си код обгонит по скорости ( и выполнения, и написания ). Си-шарп — будет действительно безопасным. Хоть одна причина, чтоб писать на плюсах? Тем более драйвера, для которых нет ни контейнеров, ни стандартной плюсовой либы. При всем уважении, Ваш К.О.

Здравствуйте, <Аноним>, Вы писали:

А>это достоинство )). c++ — недоразумение, ни один современный фреймворк не делает на него ставку )). Единственное достоинство плюсов — поражать воображение гиков. И вот эти пораженные люди, вместо того чтобы писать код и выполнять свои задачи, изобретают какие то неимоверные шаблоны.
А, сразу видно ниасилившего. Или фаната. Что в общем то почти равнозначно.
С++ не обязывает "изобретать какие то неимоверные шаблоны", чтоб ты знал на будущее.

А> Любой питон по гибкости и мощности даст фору плюсам.
Особенно в написании драйверов, которое обсуждается в этом топике.

А>Си код обгонит по скорости ( и выполнения, и написания ).
Ни выполнения ни тем более написания. Я лично терпеть не могу писать на чистом С по причине того, что там где на С++ быстро пишется пара строк с использованием RAII + простые классы-хэлперы, на С приходится заниматься закатом солнца вручную.
Вменяемыми разработчиками из С++ используется только тот сабсет, что реально нужен в данном конкретном месте, а не наворачивается говноархитектура по принципу "надо применить тут всё, и понавороченнее и на все случаи жизни".
Ну и конечно же вменяемо написанный С код конечно же обгонит укуренный говнокод на С++. Но вменяемый С++ не уступит (а то и обгонит за счёт большего пространства для манёвра у С++ компилятора в определённых случаях) вменяемый С код.
Не надо начинать городить ненужные абстракции, вот и весь секрет.

А> Си-шарп — будет действительно безопасным.
От дурости человеческой даже он не способен спасти. Группа индусов с американским гражданством меня как то в этом убедила личным примером.

А> Хоть одна причина, чтоб писать на плюсах?
В разы удобнее выражать свои мысли в виде кода чем на С.

А>Тем более драйвера
А пацаны то и не знают, и потому спокойно пишут драйвера с использованием С++. Вот у нас в проекте уже две штуки таких.

А>для которых нет ни контейнеров, ни стандартной плюсовой либы.
О боги! Нет контейнеров кроме STL и нельзя писать на С++ не используя все функции из "плюсовой либы"!!!
А я то и не знал!

Где вы все этих глупостей понабрались?
ЗАБУДЬ и про STL и про мифическую плюсовую либу.
НЕ надо их использовать там, для чего они не предназначены.
С++ НЕ обязывает тебя использовать только именно их.

ЕМ>По-хорошему, проверялку давным-давно нужно было включить в компилятор — он-то разбирает код полностью, и дерево вызовов строит, и виртуальные функции отслеживает, и т.п. Наружу вынести правила на каком-нибудь простеньком язычке. И получился бы великий верификатор всех времен и народов, а не эти уродливые поделия, прибитые сбоку ржавыми гвоздями.
идея овладевает массами — не так давно я на недоделанность oacr ругался: http://redplait.blogspot.com/2011/01/blog-post_09.html

Здравствуйте, <Аноним>, Вы писали:

А>c++ — недоразумение

Винда — еще большее недоразумение, и что?

А>ни один современный фреймворк не делает на него ставку ))

Исключительно из-за того, что "делать ставку" — это закладываться на поддержку многоуровневых иерархий классов и шаблонов, а между разными реализациями до сих пор нет полной совместимости во всех тонкостях.

А>И вот эти пораженные люди, вместо того чтобы писать код и выполнять свои задачи, изобретают какие то неимоверные шаблоны.

Так это в любой сфере популярно. Помнится, одно время было модно в схемотехнике соревноваться, кто транзистор применит наиболее извращенным способом — просто ради интереса. И надо отметить, что кое-какие полезные последствия у этих извращений таки имелись.

А>Си код обгонит по скорости ( и выполнения, и написания ).

Это смотря как писать и чем компилить.

А>Хоть одна причина, чтоб писать на плюсах?

• Более выразительный синтаксис (определение переменной/константы непосредственно перед использованием, локальные переменные в for/if/while, автоматическое создание временных объектов, перегрузка, операторы и т.п.[/*]
  
• Более строгий контроль типов.[/*]
  
• Возможность упрятать в класс серию функций с типовыми параметрами.[/*]
  
• Возможность по-человечески работать с объектами, наследуемыми один от другого.[/*]

Это только то, что вспомнилось навскидку. При грамотном применении дает не менее, а порой и более компактный объектный код, чем на C.

А>Тем более драйвера, для которых нет ни контейнеров, ни стандартной плюсовой либы.

Ограниченная поддержка плюсов в виндовом ядре существует аж со времен Win2k. То есть, десять лет, как. Хотя лично я пользую свою CRT, чтобы максимальная часть кода могла переноситься между kernel и user modes.