What's missing from upstream kernel containers?

Editor's Notes

• #4: Зачем нам отдавать свои патчи в мейнстрим меньше усилий по поддержке своих патчей во время переезда на новую версию ядра хотим, чтобы нашими контейнерами можно было пользоваться без установки специального ядра FIXME: количество патчей для разных компонентов ядра 2.6.18 vs 2.6.32, 2.6.32 vs 3.11 FIXME: добавить картинку с нашими патчами в upstream (http://openvz.org/File:Kernel_patches_stats.png) мы добавили: namespaces (pid, ipc, network) CRIU cgroups controllers нужен график коммитов в ядро http://openvz.org/File:Kernel_patches_stats.png У нас есть OpenVZ -- большой набор патчей, реализующих разную функциональность для контейнеров. Эта функциональность делится на некие "кирпичики", составляющие. Ну, например, network namespaces -- возможность иметь в ядре Линукса не одну сущность под названием "сетевая подсистема", а много. Эта сущность включает в себя экземпляр TCP/IP стека, таблицы маршрутизации, таблицы фаерволлинга, всякие разные кеши и хеши, ну и собственно сами сетевые устройства. Возможность создавать свои отдельные экземпляры сетевой подсистемы, отдавать его контейнеру, прокидывать туда устройства и т.п. -- это и есть один из "кирпичиков", из которых построена OpenVZ. Так вот, время от времени мы берём такой кирпичик и пытаемся воссоздать его в мейнстрим-ядре. Не просто послать на linux-kernel@ часть наших патчей, а именно воссоздать, то есть по сути с нуля, заново реализовать, представить на суд общественности, получить комментарии, поправить, представить на суд общественности -- и так далее, пока или оно не будет принято, или кончится терпение и мы плюнем на это неподъёмное дело. Вот таким примерно образом мы "засовываем" OpenVZ в мейнстрим ядро. После того, как "кирпичик" появляется в мейнстриме, мы выкидываем аналогичную часть из нашего патча и адаптируемся к мейнстримному (иногда написанному нами же, иногда нет). http://k001.livejournal.com/774225.html Отчего же тогда мы не отдаём весь ядерный код OpenVZ в ваниллу? Мы отдаём! Уже несколько лет как этим занимаемся, с переменным успехом (сейчас, я посмотрел, в ядре примерно 1700 патчей от нас, что не так уж и хреново, хотя, конечно, хочется много больше). Как это примерно происходит, описано выше на примере PID namespace. Бывает, что сложнее, бывает, что проще, бывает, что вообще не удаётся сделать то, что примут. Не потому, что криво, глючно и никому не надо, как думают аналитики на ЛОРе, а потому, что процесс принятия патчей -- сложный, по ряду причин. Например, мало кто понимает, что такое контейнеры и нафига они вообще нужны. Или понимают, но имеют своё, отличающееся от нашего видение, как решать ту или иную проблему. Поэтому тут больше надо разговаривать, убеждать, отстаивать свои подходы, чем просто писать и засылать хороший код. Для тех, кто думает, что на самом деле всё просто, а просто наши инженеры тупые -- покажите мне, сколько ваших нетривиальных патчей приняли, и мы поговорим. Что насчёт светлого будущего? Какое оно? Когда оно наступит? В нашем понимании, идеальное светлое будущее -- это когда OpenVZ патч к ядру будет нулевого размера, то есть мы хотим, чтобы вся функциональность, которая есть в OpenVZ, появилась в ванильном ядре. Когда это наступит? Я боюсь, что никогда, ибо мир неидеален. Но если, скажем, в ванилле будет 60 или 80% нашей функциональности -- я буду счастлив (сейчас там примерно 20-30%, точнее сложно сказать). http://ru-openvz.livejournal.com/1970.html
• #6: This slide show amount of patchset for three