LINUX.ORG.RU

Компилятор Clang теперь пригоден для сборки Linux-ядра

 , ,


0

3

В блоге разработчиков Clang появилась информация о том, что с помощью Clang удалось собрать работоспособное ядро Linux версии 2.6.36 с поддержкой многопроцессорных систем (SMP). Несмотря на то, что некоторые компоненты ядра пока не поддаются компиляции, это событие приближает тот момент, когда Clang превратится в полноценный аналог GCC.

Немного технической информации:

  • В качестве основного стенда использовался Macbook 5.1 на базе Intel Core 2 Duo (не стоит забывать, что разработку Clang поддерживает в первую очередь компания Apple). На этой конфигурации удалось запустить ядро с работоспособным X-сервером, а также ядро в среде Qemu
  • В качестве второго стенда использовалась microATX-платформа на базе Intel Atom. В этом случае ядро также функционировало, однако разработчики не пытались запускать X-сервер
  • В системе на базе собранного ядра компилятор успешно собирает сам себя, а также новое ядро. Разработчики докладывают об успешной работе кода, полученного в ходе четвертого цикла самосборки.

Работоспособны следующие компоненты ядра:

  • Базовый код ядра, файловые системы, поддержка шин, в том числе и PCI, ACPI
  • SMP, SMT, SysV, pThreads и POSIX IPC
  • NUMA, управление памятью и SWAP
  • Сетевой стек IPv4, за исключением IPSec
  • Некоторые драйверы и прошивки

Пока не удалось добиться работы следующих подсистем:

  • CryptoAPI, а следовательно, и SELinux, Posix ACLs, IPSec, eCrypt
  • Стека IPv6 и код Netfilter/Router из-за зависимости от CryptoAPI
  • Виртуализации (поддержки гипервизора Xen)
  • Поддержки загружаемых модулей

Разработчики намерены и дальше улучшать совместимость между Clang и GCC и добиваться сборки с помощью Clang полностью работоспособного ядра.

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



Проверено: anonymous_incognito ()
Последнее исправление: Dmitry_Sokolowsky (всего исправлений: 3)

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

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

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

а потом закрыть

А толку? Если твои изменения тривиальны, то хоть зазакрывайся.

PS. Мы видим, как clang (и не только его) закрывают: Apple вон всё больше под BSDL «закрывает».

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

>Gcc фактически закрытый и проприетарный по самое небалуйся.

Всё-таки открытый. Но GPLv3 и странная политика принятия патчей сделают своё дело.

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

> Так скомпилированная программа не является же производной работой от компилятора

В FSF считают иначе. Право использовать скомпилированные gcc программы дают якобы только исключения лицензии.

baka-kun ★★★★★
()
Ответ на: комментарий от pylin

>а как программеру ну да денежек содрать побольше можно)

поясни?

на рантайм у жцц претензий к закрытому коду нет.

или ты компиляторы пишешь?

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

> Всё-таки открытый.

Он сейчас напрочь огорожен от принятия улучшений и развития кем-либо за пределами части сообщества GNU.

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

>Закрыть код чего? Своих улучшений? То есть распорядиться результатами собственного труда по своему усмотрению? Это плохо, когда сделанное твоими руками и мозгами принадлежит тебе?

Тебе дали код, люди работали старались, а ты попользовался и, будь добр, поблагодари людей - верни код, который дописал.

PS. Мы видим, как clang (и не только его) закрывают: Apple вон всё больше под BSDL «закрывает».

Сейча сдк для ифона оффициально кроме мака негде не пашет, политика такая: хочешь прогать для ифона - покупай мак. Но т.к. код открыт, то у эпла вытребовали патчи для гцц и есть сборки, работающие не тока на маке. Ну с ллвм, ты понял, так не прокатит. Это лишь один пример.

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

4.2. Те искючения, которые ты имеешь в виду, на runtime-библиотеки (glibc, libgcc…), а не на сам компилятор.

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

> Тебе дали код, люди работали старались, а ты попользовался и, будь добр, поблагодари людей - верни код, который дописал.

правильно.

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

Проприетарщики бдят.

Через пару-тройку лет он загнётся.

Через пару-тройку лет загнётся всё кроме MSVS, задавят «патентами». И только GCC и другие GPL'ные программы будут этому сопротивляться.

Camel ★★★★★
()
Ответ на: комментарий от baka-kun

>Закрыть код чего? Своих улучшений? То есть распорядиться результатами собственного труда по своему усмотрению? Это плохо, когда сделанное твоими руками и мозгами принадлежит тебе?

Если производная работа от gcc принадлежит целиком и полностью создателю производной работы, то почему всякие zvercd нелегальны, ведь их «авторы» не имеют ничего против их распространения?

Ttt ☆☆☆☆☆
()
Ответ на: Конкуренция добро, GCC рулит. от Camel

> Как тут уже сказали, отправлять свой код в проект с BSD'шной лицензией есть неуважение к собственному труду

А отправлять в GPL — к чужому? %)

Не считаю для себя возможным диктовать другим, что им делать с их собственным кодом. А если ж захотел открыть свой — на, бери, пользуйся. От меня не убудет, я его уже передал всем желающим, будь то linux, FreeBSD или Cisco. Мне от этого где хуже?

Не понимаю этой жабы (вернее, наверное, «собаки»): «А-а-а, они закроют мой код и заработают на нём деньги там, где я, лох, не смог. Так хрен им».

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

>Не понимаю этой жабы (вернее, наверное, «собаки»): «А-а-а, они закроют мой код и заработают на нём деньги там, где я, лох, не смог. Так хрен им».

Дело не в деньгах. Можно код выкинуть - нате берите, делайте что хотите. А можно скзазать «давайте будем разрабатывать вместе».

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

Ну а если попробовать декомпилировать, а потом заново скомпилировать, то тогда он легальным будет?

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

> Тебе дали код, люди работали старались, а ты попользовался и, будь добр, поблагодари людей - верни код, который дописал.

А что, простого человеческого «спасибо» и патчей на те участки кода, которые не являются на 100% моими уже мало? Мне хватает упоминания даже не имени, псевдонима, в исходниках как открытых, так и закрытых продуктов.

Сейча сдк для ифона оффициально кроме мака негде не пашет

Не вижу проблемы.

то у эпла вытребовали патчи для гцц

Только не «вытребовали», а он их сам предоставляет в полном соответствии с лицензией, репозитарий открыт.

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

>А-а-а, они закроют мой код и заработают на нём деньги там, где я, лох, не смог. Так хрен им

Ну вообще GPL тоже позволяет это сделать без всяких проблем. Пожалуйста,бери, модифицируй и используй внутри своей конторы как хочешь. Только если захочется продать, то пожалуйста, выдавай сорцы тем кто купил и только по просьбе. А это вообще может быть один клиент,который в паблик выкладывать не собирается, да и сорцы ему нафиг не нужны. Кроме того, в GPL не прописаны сроки, в течение которых лицензиат должен получить исходники. При желании этот срок можно растянуть хоть на 10 лет.

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

> Можно код выкинуть - нате берите, делайте что хотите. А можно скзазать «давайте будем разрабатывать вместе».

Ну вот clang и разрабатывают вместе, а gcc — «all you base».

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

> Расскажи это интел, например.

Штеуду интересен компилятор не очень конкурирующий с их собственным. И да, они та самая часть GNU сообщества (местами).

baka-kun ★★★★★
()
Ответ на: комментарий от samy_volosaty

> я так понимаю исключения добавили для устранения недоговорённости.

То есть я уже могу взять результат работы первой стадии компилятора, модифицировать по своему усмотрению, скормить кодегенератору, и получить НЕ GPL продукт? FSF так не считает.

baka-kun ★★★★★
()
Ответ на: комментарий от Ttt

> Те искючения, которые ты имеешь в виду, на runtime-библиотеки

А если повнимательней приглядеться?

baka-kun ★★★★★
()
Ответ на: комментарий от Gorthauer

> Так ведь хочется заюзать анализатор кода от компилятора в IDE

Анализатор кода от компилятора для IDE никак не подходит - хоть от clang, хоть от gcc, потому что он должен быть:

a) Инкрементальный

b) Уметь парсить неправильный код (т.е. успешно парсить в принципе произвольный текст).

Ничего этого парсеры компиляторов делать не умеют.

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

> Если производная работа от gcc принадлежит целиком и полностью создателю производной работы…

Где ты вычитал «полностью»? Только в части новой авторской работы.

baka-kun ★★★★★
()
Ответ на: комментарий от post-factum

Ну так zvercd будет ведь уже принадлежать его сборщику, если следовать логике анти-GPL-овцев. Почему тогда он является незаконным? Пусть автор нарушил закон, когда декомпилировал, но сам зверьсд уже, если следовать их логике, чистый.

Ttt ☆☆☆☆☆
()
Ответ на: комментарий от baka-kun

вроде уже холиварили с этими анальными рабами GPL. Они отдают все, ради того, чтоб РМС их не назвал рабоми Джобса (или кого угодно).

А Джобс тем временем подбирается все ближе и ближе к свободе, четко деля: тут свободно, а тут мое.

namezys ★★★★
()

> Apple хочет засунуть под капот Мака ядро Linux?

Не смешите меня. Ядро мака куда отзывчевее на моей системе. И оно поддерживает soft-rt из коробки для CoreAudio хотя бы.

А как с этим у linux'а?

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

> в GPL не прописаны сроки

Минимум три года, или пока существует поддержка. Знать надо.

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

> Мы видим, как clang (и не только его) закрывают: Apple вон всё больше под BSDL «закрывает».

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

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

> - компилирет быстрее

- более внятные сообщения об ошибках

- bsd-лицензия



Недостатки:
- не весь код переваривает
- обычно генерит код на пару процентов быстрее gcc, но иногда может и сотворить что-то ужасно тормозящее
- bsd-лицензия. Хорошо это или плохо пусть решаю тролли, мы же упомянем и в преимуществах и в недостатках.

naryl ★★★★★
()
Ответ на: комментарий от baka-kun

Согласно копирастическому законодательству, на которое так фапают копирасты, которые в основном и заинтересованы, чтобы для свободного софта не применялись копилефт-лицензии, правообладатель производной работы осуществляет свои авторские права при условии соблюдения прав произведений, взятых за основу. А сторонникам свободного ПО, которые не собираются закопиращивать свои доработки, не должно особо волновать, имеют ли они право закопирастить их.

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

> Ну вообще GPL тоже позволяет это сделать без всяких проблем.

Фанатики GNU не видят, как прагматики делают на них деньги. У них, борцунов за свободу кода от человека, шоры на всю морду лица.

baka-kun ★★★★★
()
Ответ на: комментарий от namezys

> Пока утащат куда нить - они уже намного лучше сделают

Естественно. Модель «закрыть и почивать на чужих лаврах» не работает.

baka-kun ★★★★★
()
Ответ на: комментарий от naryl

> не весь код переваривает

поправят, хотя и не обязаны. Отхождения от стандарта - это проблемы программистов. Это редкий случай, когда apple идет на встречу.

обычно генерит код на пару процентов быстрее gcc, но иногда может

Как и gcc. Вопрос тюнинга.

Технически gcc хуже. Просто старее

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

>Не смешите меня. Ядро мака куда отзывчевее на моей системе. И оно поддерживает soft-rt из коробки для CoreAudio хотя бы.

Не смеши меня, мак дико лагает, например. А реалтайм просто не нужен хотя бы.

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

В некоторых странах и некоторых случаях декомпиляция разрешена. Допустим, я совершил декомпиляцию Windows законно, полученный код на языке высокого уровня немного модифицировал и собрал. С точки зрения анти-GPL-ьщиков, это уже моя интеллектуальная собственность.

Ttt ☆☆☆☆☆
()
Ответ на: комментарий от naryl

> - не весь код переваривает

Это не надолго. Предрекаю: достаточно скоро в gcc будут пилить совместимость с clang.

- обычно генерит код на пару процентов быстрее gcc, но иногда может и сотворить что-то ужасно тормозящее

Он очень быстро развивается.

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

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

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

>Технически gcc хуже. Просто старее

Ох лол. Ты хоть пару строк гцц видел? Аналитик, епт. За время развития гцц обрел вполне себе нормальную архитектуру, которая позволяет его спокойно расширять. То, что ллвм что-то там быстрее генерит - бред, не видел ниодного реального теста.

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

ИМХО, законность сего действия устанавливается лицензией. В любом случае, хотелось бы узнать название страны, где такое возможно.

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

> А реалтайм просто не нужен хотя бы.

Обеспечте io с audio firewire устройства в районе 8-10 млсек: АЦП + шина + роутинг в ядре + софт обработки + роутинг в ядре + ЦАП

Как это сделать без soft-rt?

ЗЫ: где у вас мак лагал? Вот сегодня он у меня лагал, когда я случайно выдернул кабель от основного SATA диска. Ему стала плохо, пока обратно не подключил

namezys ★★★★
()

По теме — недолюбливаю LLVM за толстоту.

А вообще, я с нетерпением жду того времени, когда сишный компилятор будет нужен только для сборки ядра, а все прикладные программы уйдут с этого макроассемблера (или макроассемблера++) на более высокоуровневые бескостыльные языки.

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

> Согласно копирастическому законодательству, на которое так фапают копирасты

На копирастическое законодательство «фапают», как ты выражаешься, в FSF: это единственная их защита. Остальной опенсорс максимально освобождает ПО, оставляя за автором только неотчуждаемые права, и не поучаю других, как им быть.

А сторонникам свободного ПО, которые не собираются закопиращивать свои доработки

Они их уже закопирастили, а некоторые так держатся за свой копирайт, что убивают gcc.

baka-kun ★★★★★
()
Ответ на: комментарий от buddhist

> По теме — недолюбливаю LLVM за толстоту.

Можно и в нативный код, а не для легкой и компактной виртуальной машины.

уйдут с этого макроассемблера (или макроассемблера++) на более высокоуровневые бескостыльные языки.

Э-э-э… Уйдут на «толстоту» жирнее LLVM?

baka-kun ★★★★★
()
Ответ на: комментарий от post-factum

Если закон разрешает, то лицензия уже не может запретить. В России, например, разрешена декомпиляция для достижения способности к взаимодействию с другими программами.

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