или можно юзать исключительно NTшные?

Пример ситуации.
Есть код драйвера. Там есть минифильтр с каллбеками, который кладет данные в очередь, и отдельный поток, которые каждые n минут проверяет эту очередь, и если заполнена — то передает ее куда-то далее, и очищает\пересоздает очередь. В качестве очереди автор выбрал никакой не список, а просто PWCHAR фиксированной длины, и это, конечно, тоже решение, но, например, оно почти не поддается масштабированию. Надо бы его заменить списком.

Еще пример. Здесь случай уже несколько иной.
В реестре есть настройка — ключ строкового типа, который содержит список строк через разделитель. Логичнее еще в DriverEntry распарсить эту строку на linked list, чем парсить ее каждый раз снова и снова. Опять же нужен список.

Объединяет эти случаи одно — и там, и тут нужен список.

Но стоит ли торопиться сразу осваивать специальные списки NT, такие, как SINGLE_LIST_ENTRY?
И что, если между тем списки нужны еще на одной платформе — смежной по применению, но в корне отличающейся технически — такой, как микроконтроллеры? Там уж точно не пригодятся знания NT. То есть, тебе всё равно предстоит смотреть самодельные реализации списков на Си с гитхаба, выбирать какую-то из них и допиливать ее.
Приходится всерьез рассмотреть что-то вроде "кроссплатформенности", вернее — переносимости кода.

В основе переделки — замена malloc/free на ExAllocate***/ExFree***.

Менее очевидные нюансы:
— NT обычно требовательно к быстродействию. Ранее уже упоминались каллбеки, так они могут вызываться очень много где и очень много раз подряд. Чем быстрее они будут отрабатывать — тем лучше. Но разве что-то может быть быстрее, чем твоя собственная реализация linkedlist'а, где ты можешь реализовать любые свои хотелки, да и априори ничего дорогого там вроде нет?
— Синхронизация в NT более сложная. В тех же каллбеках иногда доступны лишь спинлоки и InterlockedExchange. Тем не менее, не видится проблем все это приспособить к списку — если уж он вообще годен в сложившейся ситуации как таковой.

Если тащить эти linkedlist'ы в драйвер все-таки решительно нельзя — то я готов с этим согласиться. Но ответ нужен аргументированный, чтобы знать почему, и уметь кому-нибудь объяснить.

Никакая NT, вместе со всей MS, не запретит вам писать свой код в драйвере. И если этот код будет дублировать функциональность каких то встроенных средств, представленных MS для драйверописателей, никоим образом не должно волновать процессор - ему всё равно, чей код исполнять (ваш или MS).

Списки не используют каких либо секретных знаний о ядре и/или интерфейсе ОС, так что вполне можете заменить их своими.


Эти списки были созданы MS для своих внутренних нужд (в ядре), и что бы добру не пропадать, их отдали также и драйверописателям.


Это сообщение отредактировал(а) xvr - 24.9.2018, 15:38

Драйвер, это ВСЕГДА потенциальный BSOD. Особенно если написан лично. Не надо лезть в ядро без необходимости (там гавяное АПИ ).


Вы не в теме. Винда тупо не загрузит твой драйвер если он не подписан. Можно отключить конечно, но для распространения не годится.
Код конечно не запретит писать, вот только он выполняться никогда не будет   

Это сообщение отредактировал(а) _zorn_ - 19.10.2018, 16:27

А если ТС в драйвере вместо своих linkedlist'ов будет использовать SINGLE_LIST_ENTRY то драйвер автоматически подпишется?   


И какое это имеет отношение к вопросу ТС?