Кей Сайверс (Kay Sievers (http://linuxplumbersconf.org/2011/ocw/users/33)), Леннарт Поттеринг (Lennart Poettering (http://linuxplumbersconf.org/2011/ocw/users/729)) и Харальд Хойер (Harald Hoyer (http://linuxplumbersconf.org/2011/ocw/users/51)), работающие в компании Red Hat, от лица всех программистов, занимающихся разработкой низкоуровневых компонентов на базе Linux-систем, направили в дискуссионный лист разработчиков ядра Linux письмо (https://lkml.org/lkml/2011/10/6/395) со списком возможностей, которые хочется видеть в будущих версиях ядра, но на реализацию которых у авторов инициативы нет времени или возможностей.
Список наиболее интересных и заслуживающих внимания возможностей:
- Интерфейс для запроса и модификации метки смонтированного FAT-раздела. В данный момент изменение метки, которая хранится в скрытой каталоговой записи внутри ФС, возможно только после размонтирования раздела и модификации его содержимого с помощью специальных инструментов.
- Реализация m...URL: https://lkml.org/lkml/2011/10/6/395
Новость: https://www.opennet.ru/opennews/art.shtml?num=31977
> Простой способ изменения аргументов командной строки во время работы процесса, что может быть использовано для помещения в имя процесса полезной информации или приложениями, которые ветвятся для запуска другого бинарного файла.А сейчас в чём сложность? Расскажите пожалуйста кто знает.
В том, что такая возможность желается нативно, в ядре. В большинстве никсов такого нет.
>А сейчас в чём сложность? Расскажите пожалуйста кто знает.Как минимум, сейчас при модификации argv нужно вписываться в длину и количество изначальных аргументов. Например,
strncpy(argv[0], "new_name", strlen(argv[0]))Если новое имя длиннее изначального, "хвост" придется обрезать, иначе повредится память.
Тем что в линухе нет setproctitle(3), который есть в bsd.
Нет, ну т.е. в линухе есть prctl с PR_SET_NAME, но он у меня срабатывал для top, но не для ps, например. В детали не лез.
Линух и БСД - разные ядра, не? В БСД пилят, что хотят, с маждонгом и гейшами.
Пасиба, кэп.
> Тем что в линухе нет setproctitle(3), который есть в bsd.Ох уж эти сказочники... Если http://git.altlinux.org/people/ldv/packages/?p=setproctitle.git нет в каком-либо ином нужном линуксе, пишите письма его разработчикам.
Разница между реализацией setproctitle в libc и в сторонней библиотеке не очивидна?
$ nm -D /lib/libc.so.7 | grep setproctitle
0000000000047f10 T setproctitle
>Разница между реализацией setproctitle в libc и в сторонней библиотеке не очивидна?С точки зрения рогометания перед пацанами во дворе - вполне. С точки зрения реального использования - нет.
Допустим, вы написали приложение на скриптовом языке. И хотите, чтоб ps показывал имя приложения, а не имя интерпретатора. Вобщем, решение находится, но оно очень костыльное.
Имхо, этот вопрос должен беспокоить разработчика интерпретатора скрипта, а не авторов скриптов.
> Имхо, этот вопрос должен беспокоить разработчика интерпретатора скрипта, а не авторов скриптов.А это кому больше надо?
Разработчикам perl, или тому, кто на этом perl пишет?
> А это кому больше надо?
> Разработчикам perl, или тому, кто на этом perl пишет?Хороший вопрос, так сразу и не ответишь.
Для простоты, возьмем условный оператор if в перле. Кому он больше нужен - авторам перла или авторам скриптов на перле?
лично мне не хватает аналога солярисовского gethrtime, штоп время узнавать без сискола. Меня не забанили на гугле,если что - я видел асмовские вставки. Хотелось бы иметь стандартный механизм.
> лично мне не хватает аналога солярисовского gethrtime, штоп время узнавать без сискола.
> Меня не забанили на гугле,если что - я видел асмовские вставки.
> Хотелось бы иметь стандартный механизм.А разве в линухе gettimeofday(2), getpid(2) не реализованы как fast syscall's без переключения контекста и int 0x80? Вроде же для каждого процесса там шарится страница, в которой как раз доступны эти значения? Или нужен более точный таймер?
так вообще реализованы все сисколы в 2.6
Ога, fork(2) реализован без переключения контекста?)
>> лично мне не хватает аналога солярисовского gethrtime, штоп время узнавать без сискола.
>> Меня не забанили на гугле,если что - я видел асмовские вставки.
>> Хотелось бы иметь стандартный механизм.
> А разве в линухе gettimeofday(2), getpid(2) не реализованы как fast syscall's без
> переключения контекста и int 0x80? Вроде же для каждого процесса там
> шарится страница, в которой как раз доступны эти значения? Или нужен
> более точный таймер?Для реалтайма, например, еще как нужен. Типа, реалтайм же поддежривается пингвинячьим ядром?
>реалтайм же поддежривается пингвинячьим ядром?Пока только в linux-rt ветке
http://catap.ru/blog/2011/06/15/linux-time-interval/
это системный вызов (clock_gettime).
Этот сисвызов живёт в VDSO.
> Этот сисвызов живёт в VDSO.А в Киеве - дядька. Вы прогуглили ключевые слова из ветки чуть выше? Это похвально.
Ваще давно пора разделить кернел на разные ветки - для десктопов, серверов и ещё различные типы компьютеров.
> Ваще давно пора разделить кернел на разные ветки - для десктопов, серверов и ещё различные типы компьютеров.И для системных программистов ;)
И получить через год пачку несовместимостей? Нет уж, спасибо. Линукс сейчас стандарт де-факто, и пусть он будет един.
> И получить через год пачку несовместимостей? Нет уж, спасибо. Линукс сейчас стандарт
> де-факто, и пусть он будет един.В каком месте он стандарт и где он един? Пальцем ткни в дистровотч.
Linux это ядро, а не дистр. И таки vanilla kernel - стандарт.
ога, стандарт, особенно между версиями, офигенный стандарт, когда 2.6.19 и 3.0.1 это два совершенно разных ядра. в джёппу такие стандарты.
>ога, стандарт, особенно между версиями, офигенный стандарт, когда 2.6.19 и 3.0.1 это два совершенно разных ядра. в джёппу такие стандарты.Ага. А еще POSIX.1 и POSIX.2 это два совершенно разных стандарта. В ту же задницу их.
Что ты можешь сделать на 2.6.19, но не получается на 3.0.1 ?
из каких соображений появилась такая бредовая мысль?
Чем отличается десктоп от сервера, кроме абстрактного назначения?Технически, разделение не требуется - конфигурация ядра решает.
Практически - пложение сущностей добавит лишнего геморроя и лишит гибкости.
Зачастую на десктопе надобятся казалось бы чисто серверные фичи, например тот же NAT по быстрому настроить чтобы соседа выпустить в интернет.
интересно, что не во всех свободных проектах прокатывает идея "собраться и написать всем свои идеи". Куча критики, типа, "если тебе надо, ты и делай!"
Собственно, куча критики будет и к этому посту.
А кто они такие? эти системные програмисты!
Враги какието! Зачем им фат???
>Враги какието! Зачем им фат???Тогда, главный враг - это Торвальдс. Который пропустил в ядро драйвер для FAT.
>Зачем им фат???фат нужен хомячкам. А программистам за удовлетворение прихотей хомячков платют денюжку.
>Кей Сайверс (Kay Sievers), Леннарт Поттеринг (Lennart Poettering) и Харальд Хойер (Harald Hoyer), работающие в компании Red Hat, от лица всех программистовА Леннарт всё не угомонится выступать от лица всех и вся. Ну чтож, жду с нетерпением, когда он начнёт говорить от лица Бога.
>Список наиболее интересных и заслуживающих внимания возможностей
Ну если это наиболее интересные и заслуживающие внимания возможности, то Роб Пайк пожалуй был прав ещё в далёком 2000-ом.
>А Леннарт всё не угомонится выступать от лица всех и вся. Ну чтож, жду с нетерпением, когда он начнёт говорить от лица Бога.Вообще-то, это письмо составлено по итогам конференции системных программистов Linux Plubmers. И в качестве "гонцов" были выбраны трое наиболее авторитетных и уважаемых разработчиков.
s/Plubmers/Plumbers
> если ..., то Роб Пайк пожалуй был прав ещё в далёком 2000-омВ чем был прав Роб Пайк?
А что, Сиверс уже в редхате работает? Afaik, полгода назад он работал в новелл и был одним из ведущих разработчиков суси.
Кому что, а лично мне бы сейчас пригодилась возможность принципиально запретить перезагрузку, откладывая все попытки в какой-нибудь лог. Т.е. запретить всякие там /proc/sysrq-trigger и всё-всё-всё. Есть у меня одна конфигурация на базе linux 3.0-rt + drbd + xen, которая приводит к внезапным перезагрузкам без каких-либо объяснений причин. И дело не в железе, проверено :)
Хотя, возможно, уже такое есть. Вполне допустимо, что я просто недостаточно тчательно искал. Кстати говоря, буду рад, если кто подскажет как такое сделать. ;)
> Хотя, возможно, уже такое есть. Вполне допустимо, что я просто недостаточно тчательно
> искал. Кстати говоря, буду рад, если кто подскажет как такое сделать.
> ;)Не работай от рута.
>Кому что, а лично мне бы сейчас пригодилась возможность принципиально запретить перезагрузку, откладывая все попытки в какой-нибудь лог.Еще хорошо бы запретить смерть, войну и голод, ага.
Если не хочется, чтобы система автоматически перезагружалась при панике - sysctl kernel/panic=0
Для вывода и сохранения лога при ошибках можно использовать netconsole.>Есть у меня одна конфигурация на базе linux 3.0-rt + drbd + xen, которая приводит к внезапным перезагрузкам без каких-либо объяснений причин
А вообще, знаете вы толк в мазохизме. RT-ветка вовсе не позиционируется как стабильная.
>>Кому что, а лично мне бы сейчас пригодилась возможность принципиально запретить перезагрузку, откладывая все попытки в какой-нибудь лог.
> Еще хорошо бы запретить смерть, войну и голод, ага.Вообще-то не вижу ничего сверхъестественного в отмене перезагрузок в большенстве ситуаций. Прошу простить мою тупость, конечно :)
> Если не хочется, чтобы система автоматически перезагружалась при панике - sysctl kernel/panic=0
Увы, конечно же, это уже пробовано. Проблема не в kernel panic, а в чём-то другом. А перезагрузка мгновенная, без каких-либо сообщений на экране.
>>Есть у меня одна конфигурация на базе linux 3.0-rt + drbd + xen, которая приводит к внезапным перезагрузкам без каких-либо объяснений причин
> А вообще, знаете вы толк в мазохизме. RT-ветка вовсе не позиционируется как
> стабильная.Да, я в курсе.
>Вообще-то не вижу ничего сверхъестественного в отмене перезагрузок в большенстве ситуаций.Похоже, что у вас перезагрузки происходят не из-за штатных механизмов обработки сбоев (в частности, таким механизмом является паника), а из-за каких-то ошибок в ядре. А ошибки как класс, запретить, к сожалению, нельзя.
Разве что какое-то приложение из юзерспейса самопроизвольно командует или триггеры дергает - тогда да, такой запрет мог бы помочь. Но тут гораздо проще не давать рута кому попало. К конце концов, есть же capabilities.
>>Вообще-то не вижу ничего сверхъестественного в отмене перезагрузок в большенстве ситуаций.
> Похоже, что у вас перезагрузки происходят не из-за штатных механизмов обработки сбоев
> (в частности, таким механизмом является паника), а из-за каких-то ошибок в
> ядре. А ошибки как класс, запретить, к сожалению, нельзя.
> Разве что какое-то приложение из юзерспейса самопроизвольно командует или триггеры дергает
> - тогда да, такой запрет мог бы помочь. Но тут гораздо
> проще не давать рута кому попало. К конце концов, есть же
> capabilities.Да, это понятно. Моя интуиция подсказывает, что проблема как-то связана с drbd. В дефолтном конфиге к drbd настроены аварийные перезагрузки, используя sysrq-trigger. В конфиге, конечно же, от этого уже ничего не осталось, однако окончательно разобраться было бы проще, если все штатные механизмы перезагрузок можно было бы временно заблокировать.
Если уж все равно собирается кастомное ядро - в данном случае можно отключить MAGIC_SYSRQ в конфиге ядра. Afaik, при этом файл sysrq-trigger создаваться не должен.Но вообще идея добавить управление доступом к этому механизму, в свете вышесказанного, звучит вполне здраво.
> Если уж все равно собирается кастомное ядро - в данном случае можно
> отключить MAGIC_SYSRQ в конфиге ядра. Afaik, при этом файл sysrq-trigger создаваться
> не должен.
> Но вообще идея добавить управление доступом к этому механизму, в свете вышесказанного,
> звучит вполне здраво.В Debian есть MAGIC_SYSRQ_DEFAULT_MASK, задав определённую маску
можно запретить или разрешить только нужные коды.
>В Debian есть MAGIC_SYSRQ_DEFAULT_MASK, задав определённую маску можно запретить или разрешить только нужные коды.Это везде есть. А еще эту маску можно поменять в рантайме через sysctl.
Только, увы и ах, на /proc/sysrq-trigger оно никак не влияет (если верить документации) - только на Magic SysRq Keys.
>>В Debian есть MAGIC_SYSRQ_DEFAULT_MASK, задав определённую маску можно запретить или разрешить только нужные коды.
> Это везде есть.В Debian и клонах.
> Если уж все равно собирается кастомное ядро - в данном случае можно
> отключить MAGIC_SYSRQ в конфиге ядра. Afaik, при этом файл sysrq-trigger создаваться
> не должен.Ядро из репозитория.
> Но вообще идея добавить управление доступом к этому механизму, в свете вышесказанного,
> звучит вполне здраво.Да, было бы здорово.
> Для вывода и сохранения лога при ошибках можно использовать netconsole.root@kordis:/home/xaionaro# locate netconsole.ko
/lib/modules/2.6.32-5-amd64/kernel/drivers/net/netconsole.ko
/lib/modules/2.6.32-5-xen-amd64/kernel/drivers/net/netconsole.ko
/lib/modules/3.0.0-1-amd64/kernel/drivers/net/netconsole.ko
root@kordis:/home/xaionaro# modprobe netconsole
FATAL: Module netconsole not found.
root@kordis:/home/xaionaro# uname -a
Linux kordis 3.0.0-1-rt-amd64 #1 SMP PREEMPT RT Sat Aug 27 17:34:31 UTC 2011 x86_64 GNU/Linux
Спасибо за совет, это действительно пригодится для других серверов. Но, конкретно на данной конфигурации, почему-то модуль отсутствует. Завтра разберусь :)
> Леннарт ПоттерингС этим челом надо поосторожнее, он придумал PulseAudio.
>С этим челом надо поосторожнее, он придумал PulseAudio.Вы так говорите, как будто это что-то плохое.
А вы таки видели код и даже что-то контрибьютили туда?
> А вы таки видели код и даже что-то контрибьютили туда?Нет, просто пользовался. Хорошая штука, добавляет много удобных фич для управления звуком. Никаких ужасов, расписанных местными троллями, не наблюдал. Поэтому не понимаю всей этой истерии вокруг пульса и Поттеринга.
> Нет, просто пользовался. Хорошая штука, добавляет много удобных фич для управления звуком.Особенно хорошей фичой для хаксоров оказалось наличие суидного бита на исполняемом файле + его любовь грузить пачку либ на ходу, зачастую откуда попало, что несколько раз позволяло хацкерам вылезать из грязи в князи.
> Реализация modalias для ветки sysfs /sys/devices/system/cpu/cpuXДа, сильно недостаёт.