Здравствуйте, ononim, Вы писали:

O>Кроме того просто тупо может быть ситуация когда память, выделенная на PSASSIVE_LEVEL будет использоваться на DISPATCH_LEVEL.

Ничего, что я процитирую цитируемый же пост про "проверки IRQL"?

делать их в мемберах аллокатора (это наверное и идеологически правильней — при доступе к памяти)

O> Так что

Не вижу причинно-следственной связи. Для тех случаев нужны другие типы аллокаторов.

O> концепция "дефолтового" аллокатора в ядре неприменима.

А еще баят, что Стандарт врёт и состояние в аллокаторе хранить — можно.

O>>Кроме того просто тупо может быть ситуация когда память, выделенная на PSASSIVE_LEVEL будет использоваться на DISPATCH_LEVEL.
GN>Ничего, что я процитирую цитируемый же пост про "проверки IRQL"?
GN>

делать их в мемберах аллокатора (это наверное и идеологически правильней — при доступе к памяти)

И чем это проверки в мемберах аллокатора помогут при доступе к уже выделенной памяти, когда никакие мемберы аллокатора ваще никаким боком не используюся ?

O>> Так что
GN>Не вижу причинно-следственной связи. Для тех случаев нужны другие типы аллокаторов.
То есть, таки нужны "другие" аллокаторы

O>> концепция "дефолтового" аллокатора в ядре неприменима.
GN>А еще баят, что Стандарт врёт и состояние в аллокаторе хранить — можно.
А мне пофиг че там стандарт говорит. Но если какой нить девелопер даже в Сшном коде у меня на проекте в кернелмоде напишет чтото типа

void *malloc(size_t sz) {return ExAllocatePool( PagedPool, sz); }

то получит по рукам. Ибо нефиг. Но таких кернелдевелоперов у нас слава Богу нету

Здравствуйте, ononim, Вы писали:

O>И чем это проверки в мемберах аллокатора помогут при доступе к уже выделенной памяти, когда никакие мемберы аллокатора ваще никаким боком не используюся ?

Лучше скажи, какое это отношение имеет к запрету дефолтных аллокаторов? Ровно так же кто-то сохранит где-то указатель полученный кашерной функцией, и разыменует его из другого участка на высоком IRQL.

У аллокатора есть

pointer address(reference x) const;

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

O>>> Так что
GN>>Не вижу причинно-следственной связи. Для тех случаев нужны другие типы аллокаторов.
O>То есть, таки нужны "другие" аллокаторы

Неужели из нужности одних как-то очевидна ненужность других?

O>>> концепция "дефолтового" аллокатора в ядре неприменима.
GN>>А еще баят, что Стандарт врёт и состояние в аллокаторе хранить — можно.
O>А мне пофиг че там стандарт говорит.

Позиция ясна, стандарт говорит что это

Автор: ononim
Дата: 22.02.10

нельзя

O> Но если какой нить девелопер даже в Сшном коде у меня на проекте в кернелмоде напишет чтото типа
O>

O>void *malloc(size_t sz) {return ExAllocatePool( PagedPool, sz); } 
O>

O>то получит по рукам. Ибо нефиг. Но таких кернелдевелоперов у нас слава Богу нету

"Нефиг" это мантра, а не причина.

O>>И чем это проверки в мемберах аллокатора помогут при доступе к уже выделенной памяти, когда никакие мемберы аллокатора ваще никаким боком не используюся ?
GN>Лучше скажи, какое это отношение имеет к запрету дефолтных аллокаторов? Ровно так же кто-то сохранит где-то указатель полученный кашерной функцией, и разыменует его из другого участка на высоком IRQL.
GN>У аллокатора есть

pointer address(reference x) const;

Он то есть, вот только им никто не пользуется

GN>Напомню, что вопрос касался контейнеров, где аллокатор может быть использован при доступе.
Ну то есть обычныйvector уже пролетает

O>>>> Так что
GN>>>Не вижу причинно-следственной связи. Для тех случаев нужны другие типы аллокаторов.
O>>То есть, таки нужны "другие" аллокаторы
GN>Неужели из нужности одних как-то очевидна ненужность других?
Именно. Если нужны аллокаторы типа А, Б и С нельзя из них выделять какой то "главный" ака "дефолтовый" класс.


O>> Но если какой нить девелопер даже в Сшном коде у меня на проекте в кернелмоде напишет чтото типа
O>>

O>>void *malloc(size_t sz) {return ExAllocatePool( PagedPool, sz); } 
O>>

O>>то получит по рукам. Ибо нефиг. Но таких кернелдевелоперов у нас слава Богу нету
GN>"Нефиг" это мантра, а не причина.
Эта мантра называется bad practice.

Здравствуйте, ononim, Вы писали:

GN>>У аллокатора есть

pointer address(reference x) const;

O>Он то есть, вот только им никто не пользуется

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

GN>>Напомню, что вопрос касался контейнеров, где аллокатор может быть использован при доступе.
O>Ну то есть обычныйvector уже пролетает

Пролетают placement new и т.п. "аллокаторы" где нет возможности инкапсулировать проверки в принципе, а не какой-то конкретный вектор, куда у разработчиков руки не дошли.

Где уж пролетает обычный vector — так это в проектах без дефольного аллокатора (поскольку вектор его использует).

И я повторю свой вопрос — зачем отправлять пользователя в пешее путешествие рядом с этим вектором?

GN>>Неужели из нужности одних как-то очевидна ненужность других?
O>Именно. Если нужны аллокаторы типа А, Б и С нельзя из них выделять какой то "главный" ака "дефолтовый" класс.

Спасибо, пример помог вскрыть сифизм. "Главный" и "по умолчанию" — ортогональные сущности.

GN>>"Нефиг" это мантра, а не причина.
O>Эта мантра называется bad practice.

Достаточно повторяться, я уже сделал вывод, что причина не может быть озвучена в силу как субъективных, так и объективных причин

GN>То есть — в имеющихся реализациях STL не используется? Дык они вобще-то на работу в ядре и не расчитаны, браво, пример очень к месту. Появление проверок — вопрос времени, а не изменения дизайна — разница между этими "мелочами" ясна?
Ну то есть уже пришли к тому что имеющиеся STL тоже не подходят

GN>>>Напомню, что вопрос касался контейнеров, где аллокатор может быть использован при доступе.
O>>Ну то есть обычныйvector уже пролетает
GN>Пролетают placement new и т.п. "аллокаторы" где нет возможности инкапсулировать проверки в принципе, а не какой-то конкретный вектор, куда у разработчиков руки не дошли.
GN>Где уж пролетает обычный vector — так это в проектах без дефольного аллокатора (поскольку вектор его использует).
Вектор использует тот аллокатор, который ему передали 2м шаблонным параметром. Если передали, конечно.

GN>>>Неужели из нужности одних как-то очевидна ненужность других?
O>>Именно. Если нужны аллокаторы типа А, Б и С нельзя из них выделять какой то "главный" ака "дефолтовый" класс.
GN>Спасибо, пример помог вскрыть сифизм. "Главный" и "по умолчанию" — ортогональные сущности.
Не надо искать в словах софизмы и скрытые смыслы. Главный, по умолчанию, preffered в данном случае одно и тоже. И если уж возникают споры по поводу значения слов в какой то сущности, то такая сущность в кернелмоде тем более не нужна — там все должно быть предельно ясным.

GN>>>"Нефиг" это мантра, а не причина.
O>>Эта мантра называется bad practice.
GN>Достаточно повторяться, я уже сделал вывод, что причина не может быть озвучена в силу как субъективных, так и объективных причин
Причина — сокрытие от разработчика деталей, которые он ОБЯЗАН видеть перед своими глазами.

Здравствуйте, ononim, Вы писали:

O>Ну то есть уже пришли к тому что имеющиеся STL тоже не подходят

Констатация очевидного факта, который не имеет отношения к делу

Да, существующие STL неработоспособны в ядре. Исходя из этих причин делается альтернативный велосипед, где кстати дефолтный аллокатор есть. На следующей итерации разработки будут добавлены и проверки IRQL в аллокаторе (это польза, что я извлёк из данного топика).

И эта существующая реализация STL позволяет написать vector<int> v; в коде драйвера. Это позволяет, в частности, взять уже готовый отлаженный код и использовать без переделок. Повторное использование кода — очевидный плюс, снижающий стоимость разработки.

Каких-то минусов, увеличивающих стоимость разработки я так и не увидел

GN>>Где уж пролетает обычный vector — так это в проектах без дефольного аллокатора (поскольку вектор его использует).
O>Вектор использует тот аллокатор, который ему передали 2м шаблонным параметром. Если передали, конечно.

Реализованный по Стандарту вектор безусловно использует какой-то аллокатор, если явно не указан, то дефолтный.

template <class T, class Allocator = allocator<T> > class vector;

Запретив дефолтный аллокатор, получим:
1) несоответсвие со Стандартом.
2) неперносимость исходного С++ кода.

Что же прелагается в замен?

O>Не надо искать в словах софизмы и скрытые смыслы. Главный, по умолчанию, preffered в данном случае одно и тоже.

preffered в ядре это подкачиваемый пул (как наиболее дешёвый) что соответствует дефолтному аллокатору. Главный — не знаю что такое, может быть непосредственно с физической памятью работает?

O> И если уж возникают споры по поводу значения слов в какой то сущности

Не вижу предмета для спора, кроме как "была подмена исходных данных, или нет"

O> то такая сущность в кернелмоде тем более не нужна — там все должно быть предельно ясным.

Ага, выходит, что С++ вообще неприемлим в ядре, например, из-за повсеместного использования RAII? И С неприемлим, поскольку скрывает некоторые детали. Real man code in hex!

O>Причина — сокрытие от разработчика деталей, которые он ОБЯЗАН видеть перед своими глазами.

Ок, принимается.

Наличие документации не решит эту пробему?

Разработчик видит что используется дефолтный аллокатор, читает (один раз!) откуда будет аллокация, при необходимости меняет аллокатор.

Пока вижу здесь одну проблему — разработчик плохо понимает что такое STL и алокаторы в частности. Суть данной проблемы в том, что кто-то перепутал разработчика на С++ с разработчиком на языке "С/С++".

Здравствуйте, gear nuke, Вы писали:





GN>Главный — не знаю что такое, может быть непосредственно с физической памятью работает?


У тебя много энтузиазма для этой проблемы, что хорошо.Но я бы посоветовал тебе поработать практически с kernel.

Здравствуйте, eagersh, Вы писали:

E>У тебя много энтузиазма для этой проблемы, что хорошо.

Спасибо, но энтузиазм в решении общей проблемы временами пропадает, особенно под давлением невнятного пессимизма относительно частных проблем, как упомянутый

void* operator new(std::size_t) throw(std::bad_alloc);// ууу как же никто не вспомнил среди проблем такую жирную

и как следствие std::allocator<>

E>Но я бы посоветовал тебе поработать практически с kernel.

Пожалуйста, конкретнее, с чем стоит попрактиковаться?

E>>Но я бы посоветовал тебе поработать практически с kernel.

GN>Пожалуйста, конкретнее, с чем стоит попрактиковаться?

Напиши ка нам ядро ОС на STL. На меньшее мы даже плевать не согласны!

GN>Спасибо, но энтузиазм в решении общей проблемы временами пропадает, особенно под давлением невнятного пессимизма относительно частных проблем, как упомянутый
GN>

void* operator new(std::size_t) throw(std::bad_alloc);// ууу как же никто не вспомнил среди проблем такую жирную

и как следствие std::allocator<>
Ну во-первых в ядре на PASSIVE_LEVE даже SEH возможен
Во-вторых исключения могут быть реализованы компилятором без участия оси. Раз уж мы отказались от обычных STL, осталось отказаться от "обычных" компиляторов

E>>Но я бы посоветовал тебе поработать практически с kernel.
GN>Пожалуйста, конкретнее, с чем стоит попрактиковаться?
Сделай х64 beep.sys, который под вистой х64 будет спикером пищать

Здравствуйте, ononim,

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

O>Ну во-первых в ядре на PASSIVE_LEVE даже SEH возможен

Я с удовольствием послушаю, чем и как может помочь возможность использовать SEH при выбросе bad_alloc. Не раз встречал в сети упоминания этой возможности и сам так когда-то думал. Решений до сих пор не знаю.

Есть одно но: не надо писать, что поверх SEH следует реализовать диспетчер C++ исключений. Именно это я подразумевал, написав throw(std::bad_alloc)

O>Во-вторых исключения могут быть реализованы компилятором без участия оси. Раз уж мы отказались от обычных STL, осталось отказаться от "обычных" компиляторов

Каким компилятором следует воспользоваться и как?

Есть ли у этого способа преимущества перед реализацией независимого от ОС диспетчера С++ исключений для MSVC?

O>Сделай х64 beep.sys, который под вистой х64 будет спикером пищать

Я ошибаюсь, или такой драйвер будет содержать пару WRITE_PORT_UCHAR и не иметь места для STL? Тогда к чему это

Здравствуйте, TarasCo, Вы писали:

TC>Напиши ка нам ядро ОС на STL. На меньшее мы даже плевать не согласны!

Всё своим чередом — сначала STL, потом остальное

GN>В этой теме должна быть упомянута хоть одна проблема new, поэтому я и привёл в качестве примера спецификатор throw. Не странно ли, что это сделал защитник new, а не оппонетны?
O>>Ну во-первых в ядре на PASSIVE_LEVE даже SEH возможен
GN>Я с удовольствием послушаю, чем и как может помочь возможность использовать SEH при выбросе bad_alloc. Не раз встречал в сети упоминания этой возможности и сам так когда-то думал. Решений до сих пор не знаю.
Ну как бы в студии C++ исключения, включая bad_alloc, реализованы поверх возможности использовать SEH

GN>Есть одно но: не надо писать, что поверх SEH следует реализовать диспетчер C++ исключений. Именно это я подразумевал, написав throw(std::bad_alloc)
Почему бы и нет, если задокументировать что 'our kernel STL — passive level only'

O>>Во-вторых исключения могут быть реализованы компилятором без участия оси. Раз уж мы отказались от обычных STL, осталось отказаться от "обычных" компиляторов
GN>Каким компилятором следует воспользоваться и как?
Да фиг их знает, как-то таких исследований не проводил. Но уж точно не MSVC

GN>Есть ли у этого способа преимущества перед реализацией независимого от ОС диспетчера С++ исключений для MSVC?
А можно посмотреть на реализацию "независимого от ОС диспетчера С++ исключений для MSVC" ?

O>>Сделай х64 beep.sys, который под вистой х64 будет спикером пищать
GN>Я ошибаюсь, или такой драйвер будет содержать пару WRITE_PORT_UCHAR и не иметь места для STL? Тогда к чему это
Ну дык. Драйвер это в общем случае это не сложный piece of soft с кучей бизнеслогики, а софтинка, которая железом управляет. И как бы все. А всякие тяжелые антивирусные драйвера — это уже от лукавого и совсем не mainstream так сказать.

Здравствуйте, ononim, Вы писали:

O>Ну как бы в студии C++ исключения, включая bad_alloc, реализованы поверх возможности использовать SEH

Что есть в Студии, расчитано на юзермод. Отсюда и ограничение ниже:
GN>>Есть одно но: не надо писать, что поверх SEH следует реализовать диспетчер C++ исключений. Именно это я подразумевал, написав throw(std::bad_alloc)
O>Почему бы и нет, если задокументировать что 'our kernel STL — passive level only'

Потому что STL (а тем более остальная чать стандартной библиотеки С++) может аллоцировать в неподкачиваемом пуле и свободно с ним работать

То, что следует документировать ограничения на IRQL для какие-то конкретных функцй я писал еще здесь внизу

Автор: gear nuke
Дата: 24.02.10

.

O>>>Во-вторых исключения могут быть реализованы компилятором без участия оси. Раз уж мы отказались от обычных STL, осталось отказаться от "обычных" компиляторов
GN>>Каким компилятором следует воспользоваться и как?
O>Да фиг их знает, как-то таких исследований не проводил.

Ясно, лишь бы чето написать

O> Но уж точно не MSVC

Хоть одна причина?

GN>>Есть ли у этого способа преимущества перед реализацией независимого от ОС диспетчера С++ исключений для MSVC?
O>А можно посмотреть на реализацию "независимого от ОС диспетчера С++ исключений для MSVC" ?

Я вообще знаю всего одну реализацию, которую можно посмотреть и она пока поверх диспетчера ОС. Технических проблем в реализации не вижу.

O>Ну дык. Драйвер это в общем случае это не сложный piece of soft с кучей бизнеслогики, а софтинка, которая железом управляет. И как бы все. А всякие тяжелые антивирусные драйвера — это уже от лукавого и совсем не mainstream так сказать.

Вывод из этого такой: в ряде случаев С++ в драйвере не даёт никаких преимуществ. Не вижу какой либо связи с запретом на new или в чём мне следует "поработать практически с kernel".

Здравствуйте, gear nuke, Вы писали:

O>>Ну дык. Драйвер это в общем случае это не сложный piece of soft с кучей бизнеслогики, а софтинка, которая железом управляет. И как бы все. А всякие тяжелые антивирусные драйвера — это уже от лукавого и совсем не mainstream так сказать.

GN>Вывод из этого такой: в ряде случаев С++ в драйвере не даёт никаких преимуществ. Не вижу какой либо связи с запретом на new или в чём мне следует "поработать практически с kernel".
ononim немного поскромничал назвав драйвера софтинкой.Просто в разработке драйверов к дополнению обычных programming skills надо понимать по крайней мере архитектуру hardware.Надо знать также архитектуру OS и чем больше ты знаешь OS тем лучше.Особенно это относится к Windows так как фактически в этой среде ты работаешь с black box.А для этих целей понадобится reverse engineering.
В целом С++ не очень надо in kernel development, но бывают и большые проэкты.И это не только разработка например file system .Лично я бы с удовольствием использовал STL in device driver так как имею опыт работы с STL in application programming. Тебе надо в любом случае опыт разработки в кернел если ты хочешь разработать такие вещи.Хотя бы для тестирования.
Возьми пример из WDK — \WinDDK\...\src\general\toaster. Он включает bus driver, functional driver and filter driver. Это будет тебе достаточно для тестирования.Используй также Driver Verifier для тестирования. Toaster включает себя примеры для WDM и WDF.Попробуй использовать обои среды. На MASM промелькнуло сообщение что кто то собирается делать похожее что и ты.

Здравствуйте, eagersh,

E>В целом С++ не очень надо in kernel development, но бывают и большые проэкты.И это не только разработка например file system .Лично я бы с удовольствием использовал STL in device driver так как имею опыт работы с STL in application programming.
--
Не вижу особых проблем аккуратного использования STL в драйверах.

Попробуйте найти в google groups известное сообщение Gary Nebbett'a "better timer performance than KeSetTimerEx(...)", там есть пример использования std::map (и это 1999 год!). Numega, в последних своих версиях Driver Studio, поставляла полную библиотеку STL для работы в kernel mode. Так что вполне можете попробовать, тем более если у Вас есть определенный опыт.

C уважением,
Геннадий Майко.

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

ГМ>Numega, в последних своих версиях Driver Studio, поставляла полную библиотеку STL для работы в kernel mode.

Судя по тому, что контекст исключения сохраняется в глобальных переменных:

.text:00000164 ; int __stdcall HandleCppException(int, int, int, int, struct _s_FuncInfo *, __int32, int)

.text:0000017D                 mov     eax, dword ptr ds:_EHExceptionRecord * g_CurrentException
.text:00000182                 test    eax, eax
.text:00000184                 jz      loc_266
.text:0000018A                 mov     [ebp+arg_0], eax
.text:0000018D                 mov     eax, dword ptr ds:_CONTEXT * g_CurrentContext

выполнение кода в arbitrary thread context невозможно.

Другая проблема связана с прекращением продаж, DS 3.2 можно найти в сети и сейчас, но легальность использования не ясна.

Здравствуйте, eagersh, Вы писали:

E>Просто в разработке драйверов к дополнению обычных programming skills надо понимать по крайней мере архитектуру hardware.

Если говорить о стандартизации доступа к оборудованию, что это относится не к С++, а к С (TR 18037: Embedded C рассматривает такие вещи, как address spaces & I/O hardware addressing).

E>Надо знать также архитектуру OS и чем больше ты знаешь OS тем лучше.

Некоторое понимание есть, но это овольно широкая область, и не ясно в каком месте следует углубляться.

E>Особенно это относится к Windows так как фактически в этой среде ты работаешь с black box.А для этих целей понадобится reverse engineering.

Windows не является black-box, поскольку исполняемые файлы доступны и выпоняются локально, в том числе и трассируются. Так же есть символы, которые сильно упрощают reverce code engineering. Хоть в RE и нет предела совершенству, но я всё таки был первый, кто опубликовал практически полностью рабочий диспетчер С++ исключений (в том числе и для ядра винды) На сколько я знаю, он остаётся единственным.

E> Тебе надо в любом случае опыт разработки в кернел если ты хочешь разработать такие вещи.Хотя бы для тестирования.

Мне кажется, что в стандатрной библиотеке C++ довольно мало вещей, которые требуют тестирования именно в KM.

Вообще, одной из основных целей создания KM STL было упрощение тестирования, за счёт тестов части кода в UM (а для кода, который принципиально не может быть протестирован в UM, часто вообще не могут быть сделаны даже KM unit tests). В частности сборка с такой STL и прогон TUT selftest позволяет говорить об отсутствии по крайней мере некоторого количества багов.

E>Возьми пример из WDK — \WinDDK\...\src\general\toaster. Он включает bus driver, functional driver and filter driver. Это будет тебе достаточно для тестирования.Используй также Driver Verifier для тестирования. Toaster включает себя примеры для WDM и WDF.Попробуй использовать обои среды.

Тостер содержит мало функционала и болше подходит для не-STL части ontl, когда-нибудь дорастём и до её рефакторинга и включения тостера как примера, а пока не хватает FAQ, документации, тестов и энтузиазма

E>На MASM промелькнуло сообщение что кто то собирается делать похожее что и ты.

Можно подробнее?

А зачем все время вставлять англицкие слова? Формально это нарушение правил конфы.