Comments 24
Шутка про уехавшую цитату.
Я так вижу.
Неплохая серия статей, одно только напрягает: постоянный повтор дурацкого тезиса «в программировании последнее дело спрашивать «зачем?», нужно спрашивать «как?»» — мой опыт показывает, что как-раз-таки вопрос «зачем» это первый вопрос, который нужно себе задавать при программировании. Самый главный, в общем-то — без ответа на него не стоит делать вообще ничего. Именно отказ от ответа на этот вопрос приносит с собой 99% разнообразных сложностей и глюков. И, в частности, в данном случае даже после завершения серии так и не стало понятнее — к чему все эти сложности и к чему покрывать себе дорожку плотным слоем граблей, когда есть куча других способов (начиная от упомянутых в статье /proc, /sys и кончая ioctl'ом).
P.S. Я понимаю что иногда приходится-таки «забивать шурупы молотком» (ну там найти нормальную работу не удалось или срочно нужно сделать что-то к выставке), но обычные люди подобными эпизодами своей жизни редко гордятся и уж тем более не пишут статьи, которые объясняют, что «так и нужно делать»…
P.S. Я понимаю что иногда приходится-таки «забивать шурупы молотком» (ну там найти нормальную работу не удалось или срочно нужно сделать что-то к выставке), но обычные люди подобными эпизодами своей жизни редко гордятся и уж тем более не пишут статьи, которые объясняют, что «так и нужно делать»…
ну там найти нормальную работу не удалось или срочно нужно сделать что-то к выставке
А что?
И впрямь вот такая беда?
Может помощь какая нужна?… материальная ;-)
Аффтар, ты слишком пафосен. Изучай матчасть, твой rw_enable и трюки с CR0 опасны на реальных системах, если не понимаешь что делаешь. А ты, как видно, не понимаешь. Почитай про preemption. Ну и меня почтитай: habrahabr.ru/users/milabs/topics. И меньше пафоса, соглашусь с khim.
и трюки с CR0 опасны на реальных системах,
Н-да…
Вы слышите меня, стены?
Как я понимаю, предметного обсуждения этой «опасности» мы не услышим…
По поводу «опасности» трюков с CR0 я слышал десятки раз и в разных компаниях, поэтому это действительно стоит уточнения:
— речь о том, что в SMP между изменением CR0 и следующей записьж в защищённую область RAM может произойти перепланирование потока выполнения на другой процессор…
— … может…, но вероятность такого события примерно равна вероятности рождения сверхновой во Вселенной: если непрерывно развлекаться тем, что только загружать-выгружать модуль, то такое можно будет наблюдать… ну раз в 1000 лет… если кто доживёт
— но факт такой возможности настолько на виду, настолько это элементарно, что его сразу же указывают как только речь об этом заходит… т.е. говорится такое не для обсуждения предмета, а чтобы сказать «какой же я умный»… ну не могут разные люди слово в слово повторять эту элементарщину — это как пыанэр-зубрила, который руку тянет: «и я, и я, и я ...»
— и в чём выражается эта «опасность» если она и случится: операционную систему подвесите? вообще её инсталляцию снесёте? компьютер у вас задымится и выгорит ярким пламенем?… Нет, всего лишь не загрузится ваш собственный модуль с сообщением Оооps…
— и лечится это так же элементарно, как и объясняется: запрет прерываний на время записи на локальном процессоре на котором выполняется операция (и в коде приводимом это есть)…
— и давно это известно и описано… в этой вот, например, публикации: WP: Safe or Not? (на которую и ссылка показывалась где-то в предыдущей части… но это же читать надо!)
— речь о том, что в SMP между изменением CR0 и следующей записьж в защищённую область RAM может произойти перепланирование потока выполнения на другой процессор…
— … может…, но вероятность такого события примерно равна вероятности рождения сверхновой во Вселенной: если непрерывно развлекаться тем, что только загружать-выгружать модуль, то такое можно будет наблюдать… ну раз в 1000 лет… если кто доживёт
— но факт такой возможности настолько на виду, настолько это элементарно, что его сразу же указывают как только речь об этом заходит… т.е. говорится такое не для обсуждения предмета, а чтобы сказать «какой же я умный»… ну не могут разные люди слово в слово повторять эту элементарщину — это как пыанэр-зубрила, который руку тянет: «и я, и я, и я ...»
— и в чём выражается эта «опасность» если она и случится: операционную систему подвесите? вообще её инсталляцию снесёте? компьютер у вас задымится и выгорит ярким пламенем?… Нет, всего лишь не загрузится ваш собственный модуль с сообщением Оооps…
— и лечится это так же элементарно, как и объясняется: запрет прерываний на время записи на локальном процессоре на котором выполняется операция (и в коде приводимом это есть)…
— и давно это известно и описано… в этой вот, например, публикации: WP: Safe or Not? (на которую и ссылка показывалась где-то в предыдущей части… но это же читать надо!)
Опыт практических и внедрённых программных разработок около 40 лет, на 20-ти языках программирования.
Преподаватель-тренер международной софтверной компании Global Logic. Постоянный автор публикаций IBM Developer Works.
Около 10 лет научный редактор переводных книг издательства компьютерной литературы «Символ-Плюс», Санкт-Петербург.
Повеселило. Листал я как-то бумажный экземпляр книги этого издательства. Ужоснах. Научные редакторы и тренеры-международники, убейтесь. Короче, Олежка, тренеруй лохов, читай про COW и пеши исчо. Хабр ждёт тебя.
stackoverflow.com/questions/15275059/whats-the-purpose-of-x86-cr0-wp-bit
На самом деле тут я с Олегом готов согласиться: вы не за то уцепились. Проблема всей этой техники не в том, что она может конфликтовать с COW. Всё гораздо хуже. Вся эта серия статей при всей своей неплохой проработанности и видимой грамотности является исключительно вредной. Её можно рассматривать разве что как пародию на Ойстера. Для помещения на полке рядом со стишками:
Почему? О чём это я? А очень просто: как я уже сказал вопрос «зачем» — это то, с чего нужно начинать.
Итак: где и куда мы можем применить эту технику? Зачем она нужна? И кому?
При разработке какой-нибудь встроенной системы? Нет смысла: если мы контролируем устройство всей системы, а, стало быть, и ядра, то там не нужно производить странные выкрутасы с таблицей системных вызовов, можно просто взять и добавить системый вызов, если уж он нам так нужен. Можно даже попросить номер у разработчиков ядра, если так уж приспичило! К примеру разработчики ядра категорически отказались в своё время поддерживать стандарт STREAMS, но выделили парочку системных вызовоа для Caldera'ы. Понятно, что в этом случае у вас будет нормальная заглушка в ядре, которую вы сможете перекрыть в нужный момент и все описанные ужасы будут не очень-то и нужны.
При разработке модуля для какой-нибудь железяки? Мало смысла, неудобно: так как мы не контролируем всю систему, то наш «любимый» системный вызов может захватить кто-то ещё — а особенно весело будет если он захватит его после нас и попробует по каким-то причинам всё-таки иногда вызывать старый адрес… (люди, работавшие с TSR-программами в DOS могут с содроганием вспомнить «старые добрые» времена, когда попытка выгрузить программу из памяти вешала всю систему… люди, тогда не жившие, смогут пережить все эти «прелести» заново)…
Ладно — но ведь это можно разрулить! Вопрос: как? Мы хотим, чтобы нашим творением можно было бы как-то пользоваться, то нужно будет придумать альтернативный способ указания нашей компоненте в userspace номера того syscall'а, куда мы вешаемся… это уже какая-та инсталляцию Sound Blaster'а до появления Plug-and-Play получается! Или SCSI… А там уже и до вопросов типа «у нас есть три устройства, но какой-то идиот-конструктор решил, что все три могут иметь только адреса 5 или 6… какое из них нам вскрыть, чтобы попробовать что-то внутри перепаять?» рукой подать.
Можно, конечно, номер системного вызова через файл в /sys передать… но тогда непонятно что мешает просто там же и данные для создания драйвера оставить и через IOCTLы всё сделать…
А автор все эти вопросы, котороые куда важнее технической части серии статей «заметает под ковёр»: ну я типа рассказал, как в доманшних условиях вскипятить нитроглицерин в кастрюльке и смылся в кусты… если что пойдёт не так — я не виноват! Нет уж, извините, виноват: мы в отчете за тех, кого приручили.
Дико видеть такое отношение «преподавателя-тренера», если честно…
Если вы по коридоруНо все ли потенциальные читатели этого творения это понимают? Я очень сомневаюсь. Более того, я почти уверен, что некоторая часть читателей вполне может пойти и начать использовать эти подходы в своей деятельности. И? Чего потом? Это уже даже не смешно, это грустно.
Мчитесь на велосипеде,
А на встречу вам из ванной
Вышел папа погулять,
Не сворачивайте в кухню,
В кухне твердый холодильник.
Тормозите лучше в папу.
Папа мягкий. Он простит.
Почему? О чём это я? А очень просто: как я уже сказал вопрос «зачем» — это то, с чего нужно начинать.
Итак: где и куда мы можем применить эту технику? Зачем она нужна? И кому?
При разработке какой-нибудь встроенной системы? Нет смысла: если мы контролируем устройство всей системы, а, стало быть, и ядра, то там не нужно производить странные выкрутасы с таблицей системных вызовов, можно просто взять и добавить системый вызов, если уж он нам так нужен. Можно даже попросить номер у разработчиков ядра, если так уж приспичило! К примеру разработчики ядра категорически отказались в своё время поддерживать стандарт STREAMS, но выделили парочку системных вызовоа для Caldera'ы. Понятно, что в этом случае у вас будет нормальная заглушка в ядре, которую вы сможете перекрыть в нужный момент и все описанные ужасы будут не очень-то и нужны.
При разработке модуля для какой-нибудь железяки? Мало смысла, неудобно: так как мы не контролируем всю систему, то наш «любимый» системный вызов может захватить кто-то ещё — а особенно весело будет если он захватит его после нас и попробует по каким-то причинам всё-таки иногда вызывать старый адрес… (люди, работавшие с TSR-программами в DOS могут с содроганием вспомнить «старые добрые» времена, когда попытка выгрузить программу из памяти вешала всю систему… люди, тогда не жившие, смогут пережить все эти «прелести» заново)…
Ладно — но ведь это можно разрулить! Вопрос: как? Мы хотим, чтобы нашим творением можно было бы как-то пользоваться, то нужно будет придумать альтернативный способ указания нашей компоненте в userspace номера того syscall'а, куда мы вешаемся… это уже какая-та инсталляцию Sound Blaster'а до появления Plug-and-Play получается! Или SCSI… А там уже и до вопросов типа «у нас есть три устройства, но какой-то идиот-конструктор решил, что все три могут иметь только адреса 5 или 6… какое из них нам вскрыть, чтобы попробовать что-то внутри перепаять?» рукой подать.
Можно, конечно, номер системного вызова через файл в /sys передать… но тогда непонятно что мешает просто там же и данные для создания драйвера оставить и через IOCTLы всё сделать…
А автор все эти вопросы, котороые куда важнее технической части серии статей «заметает под ковёр»: ну я типа рассказал, как в доманшних условиях вскипятить нитроглицерин в кастрюльке и смылся в кусты… если что пойдёт не так — я не виноват! Нет уж, извините, виноват: мы в отчете за тех, кого приручили.
Дико видеть такое отношение «преподавателя-тренера», если честно…
Переход на личности — не ок.
Как приведённая ссылка подтверждает или опровергает заявление о том, что
Как приведённая ссылка подтверждает или опровергает заявление о том, что
трюки с CR0 опасны на реальных системах?
Надеюсь автор после всех комментариев еще будет писать статьи. Было познавательно.
еще будет писать статьи.
http://mylinuxprog.blogspot.com/2015/10/4.html
Sign up to leave a comment.
Добавить системный вызов. Часть 4 и последняя