Как человек, весьма много работавший с ETW, хочу ответственно заявить, что автор статьи совершенно не понимает о чем говорит. И дело даже не в самом ETW API (которое, скажем прямо, далеко от идеального) — дело в непонимании кучи БАЗОВЫХ вещей.
Начнем с того, что автор пытается использовать низкоуровневое API и с удивлением обнаруживает, что оно… НИЗКОУРОВНЕВОЕ. Ну явно какие то дебилы писали. Использовать к примеру StartKernelTrace было бы можно, но как же тогда писать возмущенную статью. Если нужно более гибкое, но высокоуровневое API, можно использовать WPRControl (это тем более удобно, что тот же самый профайл можно будет запускать отдельно от собственной программы, а также менять состав собираемого лога без перекомпиляции — простой правкой конфигурационного файла).
Возмущение по поводу GUID вообще не в кассу. Здесь человеку нужно почитать о размещении значимых типов в C/C++ и единицах трансляции. Отличие INITGUID в том, что оно заставляет макрос DEFINE_GUID определять переменную (с выделением места в data секции для текущей единицы трансляции). По умолчанию (без INITGUID) данный макрос только объявляет (extern) переменную и предоставляет линкеру позаботиться о поиске определения (и, соответственно, размещения). Да-да, тупой Майкрософт «не смог найти способ внедрить их в заголовочные файлы (я могу насчитать несколько возможных способов, но, я полагаю, им не понравился не один из них)». На минуточку, здесь прозвучало предложение внедрять ОПРЕДЕЛЕНИЯ переменных (то есть выделение памяти для них) в заголовочне файлы ПО УМОЛЧАНИЮ. Конечно же, что может быть лучше заголовочных файлов с непустым вкладом в объектный файл? Ведь всегда можно налепить сверху хак вроде __declspec(selectany). Динамически выделяемую память, кстати, за собой тоже можно не чистить — достаточно просто прибить процесс и никто и не заметит утечек.
Возмущение по поводу ограниченного количества «флагов» в «kernel trace» провайдере забавны в свете того, что вот прямо сейчас вон там из 33, а «xperf -providers K» из Windows 8.1 SDK выдает список из 55 возможных флагов (это только публичная часть — возможно для «внутреннего потребления» их еще больше).
Предложенные варианты API забавны, ибо совершенно не попадают в сценарии использования ETW. Самое главное требование — низкая стоимость (околонулевая в случае, когда на событие никто не подписан и не более пары тысяч тактов, если подписан). При этом необходимо обеспечить возможность работы на *всех* IRQL (к примеру есть возможность писать в лог с IPI или CLOCK уровней, когда не только диспетчер не работает, но и большинство прерываний от устройств замаскированы). При этом все должно продолжать работать на многопроцессорных системах (из чего следует, что использование любых видов блокировок запрещено). Необходимо иметь возможность писать в кольцевой буфер (подумайте о флаге REFSET который трейсит все ОБРАЩЕНИЯ к памяти — хотите ли Вы в пользовательском режиме обрабатывать все такие события? В реальном времени?). Нужно иметь возможность начать лог до старта не только первого пользовательского процесса, который мог бы в ETWBeginTrace, а и до старта, собственно, ядра (да-да, winload умеет писать в ETW лог — предлагаю угадать как он это делает). Это только то, что пришло в голову прямо сейчас (мне даже представлять не хочется этап сбора требований в команде, которая разрабатывала этот компонент).
Собственно разделение сессий трассировки и потребителей трейса — вполне логичное следствие даже тех поверхностных требований, которые я уже привел. Поэтому и разделение StartTrace/OpenTrace — трейс запускается в сессии, а потреблять его может кто угодно (собственно, это ОСНОВНОЙ режим работы API — запуск трейса xperf/wpr на тестовой/проблемной машине и анализ лога на машине разработчика — я даже и не припомню когда бы мне пришлось сталкиваться с «realtime» трейсами).
Ну, не совсем. Очевидно, что Вы не хотите, чтобы любой процесс мог украсть отслеживание лога ядра у другого процесса. Поэтому Microsoft решила, что лучшим решением проблемы будет просто запрещение доступа до лога ядра всем процессам, кроме тех, которые имеют права администратора.
Это даже комментировать не хочется. Ну конечно, канал «утечки» системной информации не имеет никакого значения для того, что требуется права администратора. Это было сделано исключительно для того, чтоб никто не мог вырвать сессию.
Кстати, по поводу «безумия». SystemTraceProvider и его же сессия — действительно выделены в отдельный специальный случай, что выглядит несколько некрасиво. Но, как и многие другие компромиссы, этот был сделан ради производительности — уж сильно много всего трейсит данный провайдер. Для остальных провайдеров API более универсально, но за универсальность, как обычно платят производительностью. Начиная с Win8, его можно включить до восьми раз. В принципе в моей практике почти всегда хватало одного. Исключения — это всякие когда запущен какой нибудь Process Explorer/Process Hacker (я активно исследую что-либо) и при этом мне хочется собрать трейс. Если включить эти случаи, то мне изредка нужно 2-3 сессии. И при этом я, в отличие от автора статьи, действительно не один год провел ковыряясь в производительности.
Я не совсем понял, что имелось в виду под «скроллинга курсорами клавиатурными». В любом случае, все используют только часть существующей функциональности, поэтому эти 9 плагинов реализуют только те фичи оперы, которыми я активно пользовался, которые были «в пальцах» и их отсутствие сильно раздражало.
Из нюансов перехода — пришлось повозиться с настройками общесистемных шрифтов (linux, fontconfig): Opera и Chromium что-то химичат с шрифтами, каждый по-своему, поэтому в них всё более-менее нормально отображалось, а Firefox, как выяснилось, чётко следует общесистемным настройкам, без самодеятельности. В принципе это скорее хорошо, только вот я с удивлением обнаружил, что у меня общесистемные настройки fontconfig ни к чёрту, и пришлось повозиться.
Экспорт/импорт закладок и RSS, само собой.
Ну и пользователям OperaMail вероятно смотреть в сторону Thunderbird.
Плагины:
Brief (RSS-читалка, альтернативы Bamboo и NewsFox) — не так удобно, как встроенная в Opera, но жить можно
Основной недостаток всей это радости — количество настроек у некоторых плагинов просто пугает, иногда даже кажется, что у всей оперы было меньше настроек, чем у плагинов файрфокса.
Что понравилось — набор плагинов для сетевой гигиены у файрфокса на порядок круче:
Начнем с того, что автор пытается использовать низкоуровневое API и с удивлением обнаруживает, что оно… НИЗКОУРОВНЕВОЕ. Ну явно какие то дебилы писали. Использовать к примеру StartKernelTrace было бы можно, но как же тогда писать возмущенную статью. Если нужно более гибкое, но высокоуровневое API, можно использовать WPRControl (это тем более удобно, что тот же самый профайл можно будет запускать отдельно от собственной программы, а также менять состав собираемого лога без перекомпиляции — простой правкой конфигурационного файла).
Возмущение по поводу GUID вообще не в кассу. Здесь человеку нужно почитать о размещении значимых типов в C/C++ и единицах трансляции. Отличие INITGUID в том, что оно заставляет макрос DEFINE_GUID определять переменную (с выделением места в data секции для текущей единицы трансляции). По умолчанию (без INITGUID) данный макрос только объявляет (extern) переменную и предоставляет линкеру позаботиться о поиске определения (и, соответственно, размещения). Да-да, тупой Майкрософт «не смог найти способ внедрить их в заголовочные файлы (я могу насчитать несколько возможных способов, но, я полагаю, им не понравился не один из них)». На минуточку, здесь прозвучало предложение внедрять ОПРЕДЕЛЕНИЯ переменных (то есть выделение памяти для них) в заголовочне файлы ПО УМОЛЧАНИЮ. Конечно же, что может быть лучше заголовочных файлов с непустым вкладом в объектный файл? Ведь всегда можно налепить сверху хак вроде __declspec(selectany). Динамически выделяемую память, кстати, за собой тоже можно не чистить — достаточно просто прибить процесс и никто и не заметит утечек.
Возмущение по поводу ограниченного количества «флагов» в «kernel trace» провайдере забавны в свете того, что вот прямо сейчас вон там из 33, а «xperf -providers K» из Windows 8.1 SDK выдает список из 55 возможных флагов (это только публичная часть — возможно для «внутреннего потребления» их еще больше).
Предложенные варианты API забавны, ибо совершенно не попадают в сценарии использования ETW. Самое главное требование — низкая стоимость (околонулевая в случае, когда на событие никто не подписан и не более пары тысяч тактов, если подписан). При этом необходимо обеспечить возможность работы на *всех* IRQL (к примеру есть возможность писать в лог с IPI или CLOCK уровней, когда не только диспетчер не работает, но и большинство прерываний от устройств замаскированы). При этом все должно продолжать работать на многопроцессорных системах (из чего следует, что использование любых видов блокировок запрещено). Необходимо иметь возможность писать в кольцевой буфер (подумайте о флаге REFSET который трейсит все ОБРАЩЕНИЯ к памяти — хотите ли Вы в пользовательском режиме обрабатывать все такие события? В реальном времени?). Нужно иметь возможность начать лог до старта не только первого пользовательского процесса, который мог бы в ETWBeginTrace, а и до старта, собственно, ядра (да-да, winload умеет писать в ETW лог — предлагаю угадать как он это делает). Это только то, что пришло в голову прямо сейчас (мне даже представлять не хочется этап сбора требований в команде, которая разрабатывала этот компонент).
Собственно разделение сессий трассировки и потребителей трейса — вполне логичное следствие даже тех поверхностных требований, которые я уже привел. Поэтому и разделение StartTrace/OpenTrace — трейс запускается в сессии, а потреблять его может кто угодно (собственно, это ОСНОВНОЙ режим работы API — запуск трейса xperf/wpr на тестовой/проблемной машине и анализ лога на машине разработчика — я даже и не припомню когда бы мне пришлось сталкиваться с «realtime» трейсами).
Это даже комментировать не хочется. Ну конечно, канал «утечки» системной информации не имеет никакого значения для того, что требуется права администратора. Это было сделано исключительно для того, чтоб никто не мог вырвать сессию.
Кстати, по поводу «безумия». SystemTraceProvider и его же сессия — действительно выделены в отдельный специальный случай, что выглядит несколько некрасиво. Но, как и многие другие компромиссы, этот был сделан ради производительности — уж сильно много всего трейсит данный провайдер. Для остальных провайдеров API более универсально, но за универсальность, как обычно платят производительностью. Начиная с Win8, его можно включить до восьми раз. В принципе в моей практике почти всегда хватало одного. Исключения — это всякие когда запущен какой нибудь Process Explorer/Process Hacker (я активно исследую что-либо) и при этом мне хочется собрать трейс. Если включить эти случаи, то мне изредка нужно 2-3 сессии. И при этом я, в отличие от автора статьи, действительно не один год провел ковыряясь в производительности.
Русскоязычные:
codeforces.ru
acm.timus.ru
russiancodecup.ru/tasks — примеры задач с Russian Code Cup
Англоязычные:
www.topcoder.com — no comments :)
uva.onlinejudge.org — знаменитый сайт по онлайн-контестам
www.puzzleup.com — проект похожий на «Проект Эйлер»
www.hackerrank.com — также похож на «Проект Эйлер»
www.careercup.com — тут даны примеры задач с интервью, но, в целом, подойдет, чтобы размять мозг
www.geeksforgeeks.org — похож на предыдущий
learn.hackerearth.com — также есть примеры интервью с задачами, плюс где-то в Resources есть задачки
www.interviewstreet.com/recruit2 — челленджи. Минус сайта — он платный, но есть trial-период
codercareer.blogspot.ru — примеры задач
www.shyamsundergupta.com/canyoufind.htm — задачи на стыке математики и программирования
www.primepuzzles.net — аналогично предыдущему
www.azspcs.net — оптимизационные задачи комбинаторного хар
Из нюансов перехода — пришлось повозиться с настройками общесистемных шрифтов (linux, fontconfig): Opera и Chromium что-то химичат с шрифтами, каждый по-своему, поэтому в них всё более-менее нормально отображалось, а Firefox, как выяснилось, чётко следует общесистемным настройкам, без самодеятельности. В принципе это скорее хорошо, только вот я с удивлением обнаружил, что у меня общесистемные настройки fontconfig ни к чёрту, и пришлось повозиться.
Экспорт/импорт закладок и RSS, само собой.
Ну и пользователям OperaMail вероятно смотреть в сторону Thunderbird.
Плагины:
Основной недостаток всей это радости — количество настроек у некоторых плагинов просто пугает, иногда даже кажется, что у всей оперы было меньше настроек, чем у плагинов файрфокса.
Что понравилось — набор плагинов для сетевой гигиены у файрфокса на порядок круче:
Referer:при переходе с одного сайта на другой