LINUX.ORG.RU

Продемонстрирован запуск openSUSE с ядром Linux, собранным при помощи Clang

 , , ,


0

2

Разработчики openSUSE представили видеоролик, на котором продемонстрирован процесс загрузки и работы дистрибутива в графическом окружении, при использовании ядра Linux, собранного с использованием компилятора Clang вместо GCC. Сборка осуществлена с задействованием наработок проекта LLVMLinux, развиваемом при участии организации Linux Foundation с целью решения проблем со сборкой ядра в Clang и продвижения созданных патчей в upstream-проекты (ядро Linux и LLVM/Clang).

Использование компилятора Clang, распространяемого под лицензией BSD, позволяет задействовать дополнительные техники оптимизации и диагностики проблем, например, автоматизировать выявление фактов разыменования указателей и других ошибок, связанных с некорректной работой с памятью. Изначально проект LLVMLinux развивался в рамках инициативы Linaro и был ориентирован на сборку ядра для платформы ARM, но месяц назад была обеспечена поддержка архитектур x86_64 и i586.

Для упрощения формирования сборочного окружения и кросс-компиляции ядра с использованием Clang и LLVM подготовлен специальный сборочный инструментарий.

Сборка ядра для архитектур i586 и x86_64 полностью работоспособна и позволяет получать рабочие системы, что демонстрирует пример openSUSE, но официально подобные ядра пока не готовы для применения в конечных продуктах.

Дополнительно налажен ежедневный процесс сравнительного тестирования при помощи пакета Linux Test Project (LTP) свежих сборок ядра, собранных с использованием GCC и Clang.

>>> Подробности

★★★★

Проверено: post-factum ()
Последнее исправление: post-factum (всего исправлений: 1)

ждем тестов похороникса?

silw ★★★★★
()

Текст желательно разбивать на параграфы.

По теме: всё пучком. Так и надо.

vahtu
()

19 секунд на загрузку ядра (до передачи управления init) на восьмиядерном процессоре. Вот это скорость!

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

На него не одно ядро завязано, так что пока из системы не выкинешь. К тому же шланг пока еще уступает по качеству скомпилированного кода.

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

обс позволяет сделать такое на выходных.

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

тыц проект гну искал свое ядро когда ему подвернулся линус.. так и пошло сотрудничество гну\линукс и фановый быдлокод под пивко.

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

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

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

x0r

возникает вопрос: почему кернел завязан на compiler specific kludges?

Ты видел, в чем именно костыли? Если бы видел, вопросом не задавался бы.

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

возникает вопрос: почему кернел завязан на compiler specific kludges?

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

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

Просто яблочники продвигают его всюду куда можно, они сами только его и испоьзуют сейчас ну и конечно кормят всех парней их llvm

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

GCC, причем прилично. Как в специфичных фичах, так и в целом.

X10Dead ★★★★★
()

Я очень не люблю clang и llvm. Во-первых, потому что не GPL. Во-вторых, потому что очень ограниченная поддержка архитектур. В-третьих, потому что все эти бредни вокруг этого отвлекают от Бриллианта — а именно, GCC.

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

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

Чтобы оно работало. git grep 'asm'

sf ★★★
()

Проприетарщики и их псевдосвободные товарищи ликуют.

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

Зачем совать ябблшланг в мой уютненький Gnu/Linux?

В твоем уютненьком GNU/Linux уже есть ябблкупс.
Или ты ничего на принтере не печатаешь?

Raving_Zealot ★★
()

Использование компилятора Clang позволяет задействовать дополнительные техники оптимизации и диагностики проблем, например, автоматизировать выявление фактов разыменования указателей и других ошибок, связанных с некорректной работой с памятью.

И сколько при обсуждаемой сборке выявили этих фактов??

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

19 секунд на загрузку ядра (до передачи управления init) на восьмиядерном процессоре. Вот это скорость!

Я надеюсь, это сарказм?

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

Вобще-то, back-end для архитектуры пишется человеком по имени Hal Finkel

anonymous
()

Интересно много ли в GCC костылей, чтоб ядро собиралось, и сильно ли он станет лучше, если их оттуда выкинуть?

В GCC вон уже C++11 и D добавляют, так что он давно перерос ядро и пора их обособить друг от друга. А под ядро и его костыли путь Шланг затачивают, всё равно о большем Шлангу мечтать не приходится.

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

Так это, обстоятельства обязывают не любить это всё... Как и всё, что x86-only by design.

@anonymous

back-end для архитектуры [powerpc] пишется человеком по имени Hal Finkel

Спасибо. Нaшёл его.

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

Бинарники быстрее в той волшебной стране эльфов, где форкнутая феями версия gcc 4.7 работает даже с -O3 -flto -fuse-profile без багов и с потреблением памяти в 640 КБ.

В реальных дистрибутивах, даже в генте, почти все бинарники компилятся с -O2 и больше ничем. В Debian есть ряд т.н. hardened пакетов с повышенными требованиями безопасности, так там вовсе -O0. Потому что чем агрессивнее оптимизации - тем меньше проверок и кода, оставляющего программу секьюрной даже несмотря на ошибки программиста. Shit happens. GCC на это пофигу, он сидит и оптимизирует. Clang стремится устранить это самое shit и дать возможность использовать свои оптимизации по максимуму.

В итоге имеем gcc -o2 против clang -o3, а тут уже можно сравнивать (в пользу gcc всё же); кроме того, большая часть программ в системе - событийно-ориентированные, и им важно время отзыва, а не навыки числодробления. Так что очень даже скоро линуксы будут собираться двумя компиляторами - ядро, gzip и вообще нагружаемые программы с gcc, прикладные и с требованиями к безопасности - с clang. В моей системе что-то подобное уже случилось; сейчас работаю в opensuse, скомпиленном gcc, и почему-то этот же gcc имеет свойство падать с make -j8 при компиляции QtCreator, который мне приходится пересобирать частенько. Теперь моя версия QtCreator скомпилена clang и лежит в ~/bin, и никаких проблем со скоростью нет - да и откуда им взяться в событийной программе на библиотеках собранных gcc?

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

Я, надеюсь, ты понимаешь, что написал?

много ли в GCC костылей, чтоб ядро собиралось

Ядро (Linux the Kernel) вообще-то независимо от компиляторов и прочего (особенно всяких библиотек C).

В GCC вон уже C++11 и D добавляют, так что он давно перерос ядро и пора их обособить друг от друга

Хотя... Если кто-то видит GNU/Linux как GCC/Linux, хмм... мне даже это нравится.

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

19 сек на загрузку ядра - это эпик вин, ясчитаю :3

зюзю чтоли не видел? силанг здесь и не причём по-большому счёту.

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

Ядро (Linux the Kernel) вообще-то независимо от компиляторов и прочего

Неужто оно на 100% по стандарту языка написано, и его сможет любой канпелятор, который этот стандарт полностью реализует, собрать без проблем?

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