LINUX.ORG.RU

Вышел cgroups v2

 , , ,


2

2

Инженер Facebook Tejun Heo объявил о выходе cgroups v2. Полностью переделанная версия механизма cgroups уже доступна в mainline и будет включена в релиз Linux 4.5.

cgroups v2 сфокусирован на предоставлении единого, универсального и продуманного интерфейса (в то время как v1 очень беспорядочен и непоследователен). В частности, в v2 есть только одна унифицированная иерархия, per-process. Все контроллеры теперь жестко иерархические и ведут себя стандартизированным образом. Работающие, четко определенные soft limits для котроллера памяти, теперь не надо полагаться на тюнинг OOM killer'а. Работающий resource control для writeback IO.

Механизм ядра cgroups широко используется такими важными и популярными инструментами, как Docker, Hadoop, Kubernetes, LXC, Mesos и CoreOS. cgroups v2 уже обкатан в продакшене в Фейсбуке, хотя в ближайшем будущем ожидается несколько больших интересных нововведений, которые стали возможны благодаря редизайну.

>>> Пост в FB

★★★★★

Проверено: Pinkbyte ()

Ответ на: комментарий от Csandriel

Вот это:

эта его функция — поглощение контроля над системой — ПЕРВИЧНА, а та функциональность, которой он прельщает разработчиков и пользователей — лишь наживка, а не цель его существования.

Вот это:

В частности обратить внимание на полное отсутствие чего либо общего между декларировавшимися целями и результатом внедрения systemd

intelfx ★★★★★ ()
Ответ на: комментарий от Csandriel

Но кто если не я?

Прекращаем демагогию. Я не собираюсь вступать в ещё один срач с заведомо невменяемым оппонентом, уж извини. Просто мимо проходил.

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

вивсе врети!

Два пункта. Поскольку первый я аргументировал вторым, то попрошу твоих аргументов в его опровержение. Ты хочешь сказать что systemd предлагался НЕ как всего лишь система инициализации?

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

Csandriel ()
Ответ на: комментарий от intelfx

Но ты выхватил суть. Пока что первый из адептов systemd. Самый перспективный, на предмет покаяния ^_^

Csandriel ()
Ответ на: комментарий от intelfx

с заведомо невменяемым оппонентом

Я не обижаюсь. Христа тоже невменяемым и бесноватым называли. Признать невменяемым проще всего, когда нечем больше крыть. И вот это люди, которые «требуют объективности», — размахивают диагнозами. Что две тысячи лет назад, что сейчас.

Csandriel ()
Ответ на: комментарий от intelfx

Просто мимо проходил.

Для человека в принципе статистическая норма - не задумываться к чему идет. Но может ты задумаешься?

Я понимаю что тобой движет — гордыня причастности, к великому, как тебя научили думать, делу. Такой же гордыней руководствовались красные комисары, творя свои великие дела, «ради блага человечества».

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

Csandriel ()
Ответ на: комментарий от Deleted

А без хотя бы nano или grep - сможете? Не вижу разницы между набором nano, grep или journalctl в терминале. Хотя да, journalctl это длинновато.

Хоспаде, повторяешь вам, повторяешь, а всё как об стенку горох. Текстовый редактор есть, блджад, в любой операционной системе. А текстовые логи читаются даже с поломаной файловой системой хексредактором напрямую с диска из под доса.

Ваш journalctl хоть куда нибудь кроме линуха портировали?

anonymous ()

Но ведь на линуксе нет вирусов!!1

anonymous ()
Ответ на: комментарий от Macil

не видно *измеримых* и *воспроизводимых* результатов. Я уж молчу подробном онтологическом и семиотическом анализе systemd.

После предложения о семиотическом анализе systemd ты не должен обвинять _других_ в упоротости :)

tailgunner ★★★★★ ()
Ответ на: комментарий от qnikst

в какой-то момент они стали по дефолту одну иерархию со всеми контроллерами делать

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

shatsky ★★ ()
Ответ на: комментарий от Csandriel

Я презираю религию и религиозных людей, насмехаюсь над твоей недологикой и на этом сообщении отправляю тебя в игнор.

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Я презираю религию и религиозных людей

Спасибо, мне было жизненно важно знать твое мнение. Я убедился что пилят systemd нехристи и послушники сатаны.

насмехаюсь над твоей недологикой

Понимаю. Часто сталкиваюсь с тем, что когда не в состоянии оспорить, люди начинают тупо ржать. Вычитал, что такая тактика еще со времен Римских форумов известна: что нельзя оспорить то можно высмеять. Такая «аргументация» как правило хорошо действует на плебеев, по своей сути не склонных вдумываться в суть споров и прозвучавших аргументов. Примеры применения такого приема можно широко наблюдать в политической борьбе и пропаганде, кстати.

Csandriel ()
Ответ на: комментарий от anonymous

плюсую брата анонима!

пользователь openrc

anonymous ()
Ответ на: комментарий от Macil

А для systemd-филов — сделать systemd рекурсивным.

Если я правильно понял, смешивать контроллеры и процессы можно только в корне иерархии cgroups.

SysVinit-hater ()
Ответ на: комментарий от Macil

Есть, есть, просто глаза надо разуть.

Вот такого пиздеца в коде PID1 - недостаточно?

Отписок в багзилле на вопрос «как починить битый лог journald? Никак, wontfix, close!!» - недостаточно?

А вот вам заявленная простота unit-файлов, кушайте, не обляпайтесь.

И это при том, что разработчики свой код никак не тестируют. (Эта ссылка, кстати, напрямую относится к обсуждаемой теме)

Вот ещё один раунд намечается.

И вот пока сообщество не вынет голову из песка (и ты в их числе) - оно не увидит что его в данный момент имеют в опу. Поведение человеческого экземпляра типа «удак» формулами не описывается, но всем предельно понятно.

anonymous ()
Ответ на: комментарий от anonymous

Вот такого пиздеца в коде PID1 - недостаточно?

Нет. Если у тебя есть идеи как переписать, то где пулл-реквест на гихабе?

Никак, wontfix, close!!» - недостаточно?

4.2!

По ссылке полнейший оффтопик. Дык, вместо того чтобы погнать ТС ссаными тряпками, Поттеринг подробно ответил.

Краткая суть: обращаться с битыми бинарными лог файлами нужно точно также как с битыми текстовыми файлами. Т.е. никак. В journald есть некоторая эвристика, но не более того. Никакого WONTFIX и близко нет, так как о баге и не сообщалось.

А вот вам заявленная простота unit-файлов

А! Это тоже проходили. Давний вопрос, должен ли демон *знать* об init. Является дисциплиной спецолимпиады.

И это при том, что разработчики свой код никак не тестируют.

Даже не смешно. Может быть его ещё на машине без tmpfs тестировть? Баг, кстати, поправили. Хотя опять же, могли бы занять позицию: шлите патчи мы их отсмотрим и может быть примем.

Вот ещё один раунд намечается.

В защиту kdbus выступал Greg K-H. Я его понимаю. У него опыт стояния под индустриальными говномётами, когда из 2.5-2.6 выпиливали devfs и заменяли на udev.

Смысл в том, что kdbus не вносит изменений ни в одну из подсистем ядра. Это полностью «клиентский» модуль. И как бы не кидались какашками, всё-равно эффективного высокоскоростного IPC в ядре так до сих пор и нет.

Единственное в чём можно упрекнуть разработчиков, так это в том что они неверно оценили сложность реализации.

Насчёт bus1 — ещё ничего не ясно. Даже срача на HN не вышло.

И вот пока сообщество не вынет голову из песка

Опять двадцать пять!

И такой «критикой» завален весь интернет. Критика, это ведь не кидание какашками. Критика строится по принципу: а) что не так; б) почему это не так; в) как должно быть; г) почему это должно быть *так*. Очень желательно, пункт «в» сопровождать реализацией.

В противном случае — болтовня.

Macil ★★★★★ ()
Ответ на: комментарий от Macil

Я не собираюсь помогать говноделам. Ни патчем, ни багрепортом. В моих интересах, чтобы у них бомбануло как можно сильнее из-за их говнокодерства и подхода «хуяк-хуяк и в продакшн».

Поттеринг подробно ответил.

Это не ответ, а наливание воды в предыдущий комментарий «The only way to deal with journal corruptions, currently, is to ignore them». По сути - ответа на вопрос «таки как починить логфайл?» - нет.

Давний вопрос, должен ли демон *знать* об init.

Вопрос здесь в том, что за пределами «typical use-case» юнит превращается в гораздо более сложную и хрупкую конструкцию, чем «тупо sh-скрипт».

Даже не смешно. Может быть его ещё на машине без tmpfs тестировть?

Уход с темы засчитан. Непротестированность кейса это, впрочем, не отменяет. Мне вот интересно, а чего они, собственно, ожидали? Тащите всё в инит - тестируйте возможные комбинации. Ах растут по экспоненте? Ну так кто вам виноват, ССЗБ.

В защиту kdbus выступал Greg K-H

И что с того? Ну давай ещё Дреппера вспомним или Мигельку.

Смысл в том, что kdbus не вносит изменений ни в одну из подсистем ядра

Это не повод тащить в ядро очевидную какаху. Линус так и сказал - нефиг ей делать в ядре, чините свой юзерспейс.

Единственное в чём можно упрекнуть разработчиков, так это в том что они неверно оценили сложность реализации.

*Подавился пряником* Сложность реализации? Разве что в том смысле, что им *сложно* писать простой и надёжный код, сложно проектировать простые протоколы и *сложно* удержаться и не тащить в проект всё подряд.

всё-равно эффективного высокоскоростного IPC в ядре так до сих пор и нет.

Сокеты, shm. Эффективней этого - ещё не придумали.

И такой «критикой» завален весь интернет.

Сиверсу и остальным подробно и на пальцах объяснили в ядерной рассылке «что не так» с их проектами.

Очень желательно, пункт «в» сопровождать реализацией.

«Здравствуйте, меня зовут Кирилл. Я хочу, чтобы вы написали игру, экшон, суть такова...» И всё это, разумеется, «за так», чтобы кому-то что-то «доказать».

как должно быть

Чтобы ответить на этот вопрос стороннему человеку, пилители kdbus должны сами знать на него ответ. А они истерики устраивают, когда их спрашивают за примерный роадмап дальнейшего развития.

Я напоминаю, до сих пор не озвучено ни одного use-case, зачем нужен kdbus.

anonymous ()
Ответ на: комментарий от anonymous

Линус так и сказал - нефиг ей делать в ядре, чините свой юзерспейс.

Во-первых, Линус так не говорил. Во-вторых, в ядре есть тот же binder. В-третьих, похрен на то что Линус *говорил*. Линус много чего *говорит*, но делает по большей части правильно.

Разве что в том смысле, что им *сложно* писать простой и надёжный код, сложно проектировать простые протоколы и *сложно* удержаться и не тащить в проект всё подряд.

Ты хоть смотрел код kdbus? Ты хоть смотрел код binder? И да, писать *простой* код и проектировать *простые* протоколы — сложно. А то сплошь и рядом путают простоту с тривиальностью...

Я напоминаю, до сих пор не озвучено ни одного use-case, зачем нужен kdbus.

Озвучен с самого начала: таскать по IPC данные порядка гигабайт.

Macil ★★★★★ ()
Ответ на: комментарий от Csandriel

Я презираю религию и религиозных людей, насмехаюсь над твоей недологикой

Насчет твоей «гордыни причастности к великому» персонаж попал в точку. Правда, в роли «великого» - школоло-поделка systemd.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Не тому отвечаешь. Нет, мне просто интересен этот проект.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Macil

аноним вполне подкрепил свои утверждения ссылками и в том что он говорит есть свой резон, а вот вы лишь пустословно отстаиваете божественность системд и их разработчиков - видимо ваш опус об отсутсвии объективной информации о системд был не более чем спланированнм набросом на вентилятор, фу так делать!

другой аноним

anonymous ()
Ответ на: комментарий от intelfx

Не тому отвечаешь.

ЛОР глючит. Но содержимое мессаги правильно.

tailgunner ★★★★★ ()
Ответ на: комментарий от Macil

Во-первых, Линус так не говорил.

Вот тебе кошернейший бенчмарк от самого Линуса. Я тебе даже процитирую, чтоб ты не смог «не найти»:

Quite frankly, the whole «kdbus is important for performance» seems to

be *totally* invalidated by even a minimal look at profiles for that thing.

there's not a kernel function in sight in the top-15, and it's all

just overhead.

If somebody wants to speed up dbus, they should likely look at the

user-space code, not the kernel side.

My guess is that pretty much the entirely of the quoted kdbus

«speedup» isn't because it speeds up any kernel side thing, it's because it avoids the user-space crap in the dbus server.

IOW, all the people who say that it's about avoiding context switches

are probably just full of shit. It's not about context switches, it's about bad user-level code.

We don't add crap that then has to be disabled with secuirity rules

just because it was a bad interface. Just make the interface not do it in the first place. It's that simple.

Во-вторых, в ядре есть тот же binder.

Ну давай посмотрим на то, что есть в ядре.

[anonymous@localhost linux-4.4]$ find . -name '*binder*'
./include/uapi/linux/android/binder.h
./drivers/android/binder_trace.h
./drivers/android/binder.c
[anonymous@localhost linux-4.4]$
3703 ./drivers/android/binder.c

А теперь давайте посмотрим на то, что предлагает смержить Грег и прочие.

97 files changed, 34069 insertions(+), 3 deletions(-)

Ну хорошо, там есть «документация» и типа-тесты, поэтому великодушно выкинем половину. Остаётся 17k строк кода известного нам качества, которые потом надо будет поддерживать и тянуть до скончания времён, потому что Линус не ломает юзерспейс.

Кстати, почему эти перцы не берут биндер, вместо своего велосипеда? Потому что гугл не даст ломать его как угодно?

похрен на то что Линус *говорил*. Линус много чего *говорит*, но делает по большей части правильно

...и именно поэтому Сиверс получил пинок под зад с запретом принятия патчей. Остальные на очереди. Последним в серии, надеюсь, будет Грег.

Примеров что «незаменимых людей в ядре нет» - навалом, из последнего - Шарп.

Ты хоть смотрел код kdbus?

Как ты мог убедиться из примеров выше, я регулярно смотрю код этого г-на, чтобы понять, где оно на этот раз сломалось.

писать *простой* код и проектировать *простые* протоколы — сложно

Не умеешь - не берись. Я не знаю, герань разводи на балконе, как раз по скиллам. Какого чёрта вам тогда в ядре надо? Нам с этим жить потом.

Озвучен с самого начала: таскать по IPC данные порядка гигабайт.

И? Те же сокеты этого не позволяют делать?

Ну и на закуску: dbus is not an appropriate design for a kernel messaging layer for a variety of reasons.

anonymous ()
Ответ на: комментарий от Macil

Краткая суть: обращаться с битыми бинарными лог файлами нужно точно также как с битыми текстовыми файлами.

неверно. краткая суть: откуда на append-only бинарных журнальных файлах появляются коррапшены, и нормально ли это? представь себе БД с таким поведением. они там транзакции в школе не проходили? или семантику posix файловых систем? Леннарт вообще адекватно так journald с ext4 сравнил, лол.

Баг, кстати, поправили.

Баг, с моей скромной точки зрения, в полном пренебрежении практиками defensive programming, и это в проекте ни много ни мало «системы всего».

val-amart ★★★★★ ()
Ответ на: комментарий от Macil

Краткая суть: обращаться с битыми бинарными лог файлами нужно точно также как с битыми текстовыми файлами. Т.е. никак.

С убитыми текстовыми файлами как раз таки можно работать, в этом суть.

И как бы не кидались какашками, всё-равно эффективного высокоскоростного IPC в ядре так до сих пор и нет.

Новости в мире Linux, и наверное ты хочешь сказать что dbus-like решение будет скоростным? Это менее реально, чем паранойя по поводу целей редхат и места системд в их достижении.

Про критику почитай страничку s6.

qnikst ★★★★★ ()
Ответ на: комментарий от Macil

У него опыт стояния под индустриальными говномётами, когда из 2.5-2.6 выпиливали devfs и заменяли на udev.

Такая брехня пройдет только с нубами. DevFS выпиливалась под аплодисменты.

tailgunner ★★★★★ ()
Ответ на: комментарий от Macil

Озвучен с самого начала: таскать по IPC данные порядка гигабайт.

Какие приятные глупости

qnikst ★★★★★ ()
Ответ на: комментарий от qnikst

Озвучен с самого начала: таскать по IPC данные порядка гигабайт.

Какие приятные глупости

Если верить Грегу, то по dbus (не kdbus) уже таскаются гигабайты.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

qnikst ★★★★★ ()
Ответ на: комментарий от qnikst

Ну с современным подходом к общению меж десктоп программами и системд, может я и поверю в это.

Мне кажется, это было еще до внедрения systemd. И системы были не десктопные, а car infotainment или что-то такое. Я еще подумал «епт, ну что за индусы это написали».

я не понимаю что мне мешает слать гигабайты другими IPC более эффективно, даже если dbus в ядре будет.

Да ничего, конечно. Но протакскивают kdbus именно под легендой «нам нужен быстрый IPC».

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

DevFS выпиливалась под аплодисменты.

Угу, я эти «апплодисменты» читал, ага.

Macil ★★★★★ ()
Ответ на: комментарий от val-amart

откуда на append-only бинарных журнальных файлах появляются коррапшены, и нормально ли это

Ровно оттуда же откуда они появляются и в текстовых файлах. Скорее всего journald действительно сливает с архитектурной точки зрения специализированным системам.

Но вот вопрос: какую из них можно использовать в systemd? Я знаю одну. Но а) она не продакшен; б) в момент начала разработки systemd она была не так известна.

в полном пренебрежении практиками defensive programming

Ну-ну, не нужно бросаться высокопарными фразами... Тем более в такой нечёткой области. Я вообще не думаю что Поттеринг и Co рассматривают крах PID 1 как катастрофу. В ядре есть механизмы реакции на panic. А в виртуальных средах не нужны даже и они.

Macil ★★★★★ ()
Ответ на: комментарий от qnikst

ты хочешь сказать что dbus-like решение будет скоростным

kdbus имеет крайне опосредованное отношение к D-Bus. Используется формат сериализации D-Bus, но вроде бы и ничего более.

Что значит «скоростным»? Если ты имеешь ввиду возможно ли уложить вызов IPC в один слайс, как в биндере, то — нет. А если ты имеешь ввиду возможно ли передавать данные порядка гигабайта без лишних копирований и переключений контекста, то — да.

Про критику почитай страничку s6.

Да читал я её, читал. И даже интересные вещи (по ссылкам) находил. Только критика systemd там настолько неубедительна, что её даже разбирать неинтересно. Видано ли, в разделе «Technical issue» не написать ни одной этой самое issue?

И сам проект интересен... Только у аффтара POSIX головного мозга. Т.е. cgroups и inotify идут лесом.

Ну и учитывая что в рамках проекта s6 уже порядка пятидесяти утилит, то налицо еще один systemd с блекджеком и шлюхами...

P.S. Посмотрел презенташку Поттеринга с последнего systemd.conf по cgroups1. Его послушать, так там вообще лютый АдЪ и ...ецЪ. Это к вопросам «качества».

Macil ★★★★★ ()
Ответ на: комментарий от anonymous

Вот тебе кошернейший бенчмарк от самого Линуса.

Это бенчмарк D-Bus. И никакой кошерности в нём нет.

Кстати, почему эти перцы не берут биндер, вместо своего велосипеда?

Грек К-Х разбирал этот вопрос в своём блоге.

и именно поэтому Сиверс получил пинок под зад с запретом принятия патчей

Сиверс не получал никакого «запрета». Ситуация с Сиверсом — обычная и регулярная практика, с той только разницей что в данном случае она вылилась в публичную плоскость и сопровождалась некорректным поведением Линуса.

Ну и на закуску: dbus is not an appropriate design for a kernel messaging layer for a variety of reasons.

Судя потому что официальная разработка kdbus затормозилась, то советам в конце поста разработчики таки вняли.

Как ты мог убедиться из примеров выше, я регулярно смотрю код этого г-на, чтобы понять, где оно на этот раз сломалось.

Ты может его и в продакшене используешь? kdbus даже из Fedora Rawhide выкинули, а во все остальные проекты его даже и не включали.

Macil ★★★★★ ()
Ответ на: комментарий от Macil

DevFS выпиливалась под аплодисменты.

Угу, я эти «апплодисменты» читал, ага.

Тогда не рассказывай тут про «опыт стояния под говнометами». Если кто и стоял под говнометами, то это был Гуч.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Да ничего, конечно. Но протакскивают kdbus именно под легендой «нам нужен быстрый IPC».

серьёзно? мне казалось, что им нужен быстрый dbus и меньше проблем с bootstrap-ом системы.

qnikst ★★★★★ ()
Ответ на: комментарий от Macil

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

осталось понять, зачем мне тут (k)dbus и почему я это не могу сделать другими средствами.

kdbus имеет крайне опосредованное отношение к D-Bus. Используется формат сериализации D-Bus, но вроде бы и ничего более.

на мой взгляд dbus это: 1. фиксированный формат сериализации, 2. возможности интроспекции и discovery сервисов и их команд, 3. возможность multicast - сообщений подписавшимся, 4. немного плюшек для отложенного старта сервисов и неявных зависимостей. Чего из этого нету в kdbus? Чего нету в dbus, но есть в kdbus - это минимум документации, тут Грегу надо отдать должное, читая её наконец-то можно понять что к чему.

Да читал я её, читал. И даже интересные вещи (по ссылкам) находил. Только критика systemd там настолько неубедительна, что её даже разбирать неинтересно. Видано ли, в разделе «Technical issue» не написать ни одной этой самое issue?

я правильно понимаю, что ты не только страничку про systemd там прочитал, а большую часть документации? но тем не менее там достаточно пунктов разобрано в виде, что делать не надо, как надо и почему. Я не знаю какую информацию про systemd ты искал в интренете, т.к. ссылки на расслыки, на багрепорты, на блоги различных разработчиков не подходят, примеры того, где предложенные решения делают хуже, чем было. Похоже, что ты ищешь, какую-то страницу с откровениями, от которых станет ясно, что systemd использовать ну никак нельзя - но такого, к счатьстью нет, systemd это не плохой вполне работающий вариант для управления системой, работающий в большинстве случаев (учитывая, их подход в общем-то это скорее ожидаемо, чем неожиданно).

Ну и учитывая что в рамках проекта s6 уже порядка пятидесяти утилит, то налицо еще один systemd с блекджеком и шлюхами...

ты про systemd выводы таким же образом делаешь? тогда наверное дискуссию стоит свернуть.

P.S. Посмотрел презенташку Поттеринга с последнего systemd.conf по cgroups1. Его послушать, так там вообще лютый АдЪ и ...ецЪ. Это к вопросам «качества».

каким вопросам качества?

qnikst ★★★★★ ()
Ответ на: комментарий от qnikst

Чего нету в dbus, но есть в kdbus - это минимум документации, тут Грегу надо отдать должное, читая её наконец-то можно понять что к чему.

kdbus это messaging VFS. Судя по обрывкам реплик, эксперименты в юниксах идут с давних пор.

VFS даёт целую массу плюшек: интроспекцию (ты почему-то говоришь о ней как будто это что-то плохое), возможность многоадресной рассылки т.к. иерархия => легко определить понятие групп рассылки, возможность получения эффективных уведомлений о событиях, эффективные механизмы разграничения доступа.

В то же самое время такая VFS не создаёт ничего нового: задействованы только уже существующие ядерные механизмы/интерефейсы.

Т.е. мы не выдумываем подсистемы. Не меняем семантику уже существующих (в отличие от тех же AF_NETLINK, АF_PPOX, ethtool). Не изобретаем новые сисколлы. Не транжирим ценные «слотовые» ресурсы ядра.

Ещё раз повторюсь. Видимо, разработчики неправильно оценили сложность.

Похоже, что ты ищешь, какую-то страницу с откровениями, от которых станет ясно, что systemd использовать ну никак нельзя

Ну да. Типа того.

systemd это не плохой вполне работающий вариант

*Я* — в курсе.

что ты не только страничку про systemd там прочитал, а большую часть документации

Нет. Документацию не читал. И сравнений s6-systemd не читал, т.к. в то время s6 находился в зачаточном состоянии.

Надо будет обязательно посмотреть в образовательных целях.

Проблема только одна: отношение автора к линукс-специфичным API.

Macil ★★★★★ ()
Ответ на: комментарий от qnikst

мне казалось, что им нужен быстрый dbus и меньше проблем с bootstrap-ом системы.

dbus уже стал одним из видов IPC.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

dbus вродеж их скопростью не удовлетворяет. Мол kernel-userspace свичей много, надо быстрее, надо положить его в ядро.

qnikst ★★★★★ ()
Ответ на: комментарий от qnikst

Ну вот там давали ссылку на то, что мол переключения контекста и перформанс — это хрень и можно/нужно вместо этого починить дбас. Дбас не устроил их не только скоростью, а ещё тем, что это ещё один демон с кучей зависимостей и он недоступен в early boot/shutdown.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от qnikst

Во, нашёл классную ссылку https://lwn.net/Articles/405346/

Звучали даже предложения сделать AF_DBUS.

Так же стоит отметить проект DragonflyBSD, где ведётся попытка перевода взаимодействия с ядром на message-based интерфейс.

Macil ★★★★★ ()
Ответ на: комментарий от Macil

Это бенчмарк D-Bus.

Ложь. Обсуждение идёт именно kdbus'а, +двумя постами выше есть обсуждение, как выложенное чудо собирать, что оно собиралось.

И никакой кошерности в нём нет.

А с чего я должен верить тебе больше чем Линусу, м, балабол беспруфный?

Грек К-Х разбирал этот вопрос в своём блоге.

Ссылки нет - считаем что не или разбирал или лил воду на тему как всё будет о**енно.

Сиверс не получал никакого «запрета».

Key, I'm f*cking tired of the fact that you don't fix problems in the code *you* write, so that the kernel then has to work around the

problems you cause.

Greg - just for your information, I will *not* be merging any code from Kay into the kernel until this constant pattern is fixed.

Пруф. Ты снова намеренно лжёшь.

Судя потому что официальная разработка kdbus затормозилась, то советам в конце поста разработчики таки вняли.

Нет, они не сами «вняли», их послали переделывать. Отпиливать собственно желаемый ipc от тонны dbus'о специфичного г-на.

Как я понял насчёт биндера ты слился и use-casов так и не привёл, ок.

anonymous ()
Ответ на: комментарий от Macil

Я вообще не думаю что Поттеринг и Co рассматривают крах PID 1 как катастрофу.

Нормально, чо. Let it fail! Бугага. Вы там с поцерингом уже такую репутацию линупсу создали, что любо дорого. Скоро 95-я выньда от зависти в гробу начнет крутиться.

anonymous ()
Ответ на: комментарий от anonymous

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

Странно. У меня kdbus собирался без проблем. Единственное «но» ему нужен time64_t который появился только в 3.17.

Как я понял насчёт биндера ты слился и use-casов так и не привёл, ок.

Юзкейсы? Биндера? Дык, возьми любой андрод-телефон. Там биндер везде. Если тебе нужны ссылки, ну пожалуйста: http://elinux.org/Android_Binder там как раз внизу ссылка на пост Грега почему нужен kdbus.

В десктопных системах все те же самые юзкейсы: начиная от получения уведомлений, заканчивая компонентными технологиями.

Если ты не понял, то D-Bus давно и крепко пробрался в настольные системы. Если интересно, вот пост на тему (осторожно, Поттеринг по ссылке) http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html

Теперь, зачем необходимо передавать большие объёмы по шине.

Например, ты получаешь PDF-ник из недоверенного источника. Это очень не гут, т.к. все вьюверы (включая штатный) очень и очень сильно кривы и являются неиссякаемым источников эксплоитов.

По счастью, наличие эксплоита в PDF очень легко проверить. Но, тогда возникает вопрос, а что если и наш проверяльщик кривой?

Эта проблема имеет очень и очень простое решение. Поскольку наш проверяльщик не взаимодействует с пользователем, то его можно запустить в изолированном окружении. Тут выбор богат: DAC (под другим uid), LSM (SELinux, AppArmor и прочие), неймспейсы (их ещё называют LXC), на уровне гипервизора (см. напр. QubesOS), гипотетический контроллер безопасности для cgroups, или любые другие механизмы.

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

Сеть? Но лучше её убрать вообще (и лучше все семейства сокетов) и zero-copy нет. Файловая система? Но это сложно: нужно договариваться о точках рандеву, разрабатывать протокол взаимодействия. Вот и остаётся самый тупой вариант: послать PDF по IPC.

Естественно, юзкейсы не ограничиваются только проверкой. Есть целая проблема с построением миниатюр. Для самых параноидальных пользователей по IPC можно сделать и рендеринг: как в «лёгкой форме» декодирование и проверка, так и в «тяжёлой» передача графики по IPC (хотя, конечно для этого есть и другие механизмы).

Предваряя возгласы «такой подход туп», замечу что биндер умудряется делать IPC вызовы в пределах одного тайм-слайса.

А при должном проектировании, можно сделать так что передача гигабайт по IPC не будет вносить вообще никакого оверхеда.

Macil ★★★★★ ()
Ответ на: комментарий от anonymous

Let it fail! Бугага.

Философия Эрланга, и всех highload-систем. Вон извращенцы из netflix юзают «chaos monkey», которая периодически вырубает случайную ноду.

Зато, когда к Амазону (а у нетфликса нет своей инфраструктуры) подобрался полярный лис, нетфликс был одним из немногих кто не полёг.

Так что не надо.

Macil ★★★★★ ()
Ответ на: комментарий от Macil

Философия Эрланга, и всех highload-систем. Вон извращенцы из netflix юзают «chaos monkey», которая периодически вырубает случайную ноду.

facepalm.mkv.gz (4.7G)

tailgunner ★★★★★ ()
Ответ на: комментарий от Macil

послать PDF по IPC

Есть целая проблема с построением миниатюр

Ты упоролся.

SysVinit-hater ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.