1) Из того, что точно помню — не сходились тесты для HMAC на базе ГОСТ 34.11-94.
2) Одно из предложений — дать возможность публичного обсуждения проектов, разместив текстовые документы на github (или поднять на ТК26 gitlab). Учитывать комментарии, принимать пулл-реквесты (закрытй форум это конечно хорошо, но не всегда). Публиковать окончательные документы в txt-виде как основном. Во многих проектах, связанных с ASN.1 структурами и расширением стандартных структур/контейнеров есть неоднозначные моменты. Принимать исправления и выпускать errata как для RFC. То есть в целом наладить похожий, открырый для сообщества процесс.
3) Ниже про Магму откомментировали уже. Рекомендации типа, — «внимательно читайте стандарт», — это конечно хорошо, но стандарт он на то и стандарт, что должен быть в достаточной степени однозначным и недвусмысленным. Мы же не юриспруденцией занимаемся :-)
Согласен, отечественные стандарты это функции с секретом :-) От ТК-26 вообще не знаю чего ожидать, вроде бы должны способствовать стандартизации, но по факту — документы корявые, тестовые примеры не всегда сходяться… Был на нескольких заседаниях комиссии — такое впечатление, что попал на диссертационный совет годов 80-х, ей богу :-D
С Магмой тоже находимся в непонимании — то ли 89-й гост, то ли что-то новое. Ещё до стандартизации ставили вопрос о порядке байтов, но что-то вменяемого нам никто не ответил.
В стандарте своеобразная трактовка операции сложения по модулю 2^32-1. Должно быть:
a + b (mod 2^32) ::= { a + b, if (a + b) < 2^32; a + b - 2^32, elsewhere }
a + b (mod 2^32 - 1) ::= { a + b, if (a + b) < 2^32; a + b - 2^32 + 1, elsewhere }
К сожалению, это частая ошибка при реализации ГОСТ 28147-89.
Интересно было бы сравнить. Мы заказываем у вас наборчик, но требуемая для наших задач точность у них не достигается, поэтому вряд ли сейчас будем смотреть. В любом случае: больше решений, хороших и разных!
Олег, мне понятна ваша страсть к прекрасному, а также стремление поучать и наставлять. Это либо проходит в определённом возрасте, либо приобретает забавные весьма формы. Ваша стилистика, она «как бэ намекаэ», да.
Что касается г-на Jerry Cooperstein, то похоже он внёс весь свой вклад в развитие ядра Linux в эпоху доисторического материализма, т.е. когда git'а ещё не было. Я что-то не нашёл ни одного его коммита и упоминания его персоны в исходниках ядра. Подскажите, где посмотреть чем он так знаменит, кроме посредственной и давно утратившей актуальности книги, а также должности Training Program Director в Linux Fondation? Кажется, у вас много общего — оба два любите чему-то поучать :-)
Далее, относительно вашего опуса:
во-первых, там эта функция нужна только для чтения… не обязательно там что-то «лочить»…
Снимаю шляпу, оригинально. Именно потому что что-то там читаем и не нужно лочить. Браво.
Отсюда вывод напрашивается сам собой — «бумажный» тренер тренирует бумажное стадо. Ну понятно же, что вы в принципе не в теме ядерной разработки. Не практик ни разу. Так и пишите в начале статьи, — «я, автор, не разбираюсь в предмете, но мне интересно и я хочу услышать ваши комментарии по поводу ...».
Ну и напоследок вам с г-ном Jerry Cooperstein'ом пару вопросов:
1. Что будет если в момент поиска устройства с использованием __dev_get_by_name кто-то выгрузит драйвер сетевой карты?
2. Что будет если в ходе работы вашего модуля кто-то выгрузит модуль сетевой карты родительского устройства?
3. Почему RTNL-lock захватывается только на момент установки/снятия обработчика?
Подскажу ответ на 3-й вопрос: кто-то словил ассерт от ядра, тогда как в аналогичной ситуации при вызове __dev_get_by_name без лока ядро варнинг не кидает. Отсюда, собственно, выводы. Пионэры :-)
__dev_get_by_name ничего не лочит, её нельзя использовать вот просто так. Как результат — получите кучу проблем. Рядом же есть функция dev_get_by_name, которая и по списку аккуратно ходит и на выходе dev_hold над найденным устройством делает. Пионэры.
Опыт практических и внедрённых программных разработок около 40 лет, на 20-ти языках программирования.
Преподаватель-тренер международной софтверной компании Global Logic. Постоянный автор публикаций IBM Developer Works.
Около 10 лет научный редактор переводных книг издательства компьютерной литературы «Символ-Плюс», Санкт-Петербург.
Повеселило. Листал я как-то бумажный экземпляр книги этого издательства. Ужоснах. Научные редакторы и тренеры-международники, убейтесь. Короче, Олежка, тренеруй лохов, читай про COW и пеши исчо. Хабр ждёт тебя.
Аффтар, ты слишком пафосен. Изучай матчасть, твой rw_enable и трюки с CR0 опасны на реальных системах, если не понимаешь что делаешь. А ты, как видно, не понимаешь. Почитай про preemption. Ну и меня почтитай: habrahabr.ru/users/milabs/topics. И меньше пафоса, соглашусь с khim.
2) Одно из предложений — дать возможность публичного обсуждения проектов, разместив текстовые документы на github (или поднять на ТК26 gitlab). Учитывать комментарии, принимать пулл-реквесты (закрытй форум это конечно хорошо, но не всегда). Публиковать окончательные документы в txt-виде как основном. Во многих проектах, связанных с ASN.1 структурами и расширением стандартных структур/контейнеров есть неоднозначные моменты. Принимать исправления и выпускать errata как для RFC. То есть в целом наладить похожий, открырый для сообщества процесс.
3) Ниже про Магму откомментировали уже. Рекомендации типа, — «внимательно читайте стандарт», — это конечно хорошо, но стандарт он на то и стандарт, что должен быть в достаточной степени однозначным и недвусмысленным. Мы же не юриспруденцией занимаемся :-)
github.com/sftp/gost28147/commit/bb382c79c954ff413b633fab4a511afd43ce150a
С Магмой тоже находимся в непонимании — то ли 89-й гост, то ли что-то новое. Ещё до стандартизации ставили вопрос о порядке байтов, но что-то вменяемого нам никто не ответил.
В стандарте своеобразная трактовка операции сложения по модулю
2^32-1. Должно быть:К сожалению, это частая ошибка при реализации ГОСТ 28147-89.
Вот обсуждение этой проблемы, найденной мной в gostcrypto:
github.com/rudonick/crypto/issues/1
Что касается г-на Jerry Cooperstein, то похоже он внёс весь свой вклад в развитие ядра Linux в эпоху доисторического материализма, т.е. когда git'а ещё не было. Я что-то не нашёл ни одного его коммита и упоминания его персоны в исходниках ядра. Подскажите, где посмотреть чем он так знаменит, кроме посредственной и давно утратившей актуальности книги, а также должности Training Program Director в Linux Fondation? Кажется, у вас много общего — оба два любите чему-то поучать :-)
Далее, относительно вашего опуса:
Снимаю шляпу, оригинально. Именно потому что что-то там читаем и не нужно лочить. Браво.
Отсюда вывод напрашивается сам собой — «бумажный» тренер тренирует бумажное стадо. Ну понятно же, что вы в принципе не в теме ядерной разработки. Не практик ни разу. Так и пишите в начале статьи, — «я, автор, не разбираюсь в предмете, но мне интересно и я хочу услышать ваши комментарии по поводу ...».
Ну и напоследок вам с г-ном Jerry Cooperstein'ом пару вопросов:
1. Что будет если в момент поиска устройства с использованием __dev_get_by_name кто-то выгрузит драйвер сетевой карты?
2. Что будет если в ходе работы вашего модуля кто-то выгрузит модуль сетевой карты родительского устройства?
3. Почему RTNL-lock захватывается только на момент установки/снятия обработчика?
Подскажу ответ на 3-й вопрос: кто-то словил ассерт от ядра, тогда как в аналогичной ситуации при вызове __dev_get_by_name без лока ядро варнинг не кидает. Отсюда, собственно, выводы. Пионэры :-)
__dev_get_by_name ничего не лочит, её нельзя использовать вот просто так. Как результат — получите кучу проблем. Рядом же есть функция dev_get_by_name, которая и по списку аккуратно ходит и на выходе dev_hold над найденным устройством делает. Пионэры.
Повеселило. Листал я как-то бумажный экземпляр книги этого издательства. Ужоснах. Научные редакторы и тренеры-международники, убейтесь. Короче, Олежка, тренеруй лохов, читай про COW и пеши исчо. Хабр ждёт тебя.
stackoverflow.com/questions/15275059/whats-the-purpose-of-x86-cr0-wp-bit