Почему ядро Linux не пишут на С++? :)

http://kerneltrap.org/node/2067
И соответственно сотни такх же флеймов в инете.

Пишут. На ЛОРе пробегала ссылка на ядро Linux, написанное на C++. Я его даже скачивал ;).

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

Вон симбиан написали. И????

Лучше б не брались...

> На ЛОРе пробегала ссылка на ядро Linux, написанное на C++. Я его даже скачивал ;).

Тогда это уже ядро не Linux :)

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

А разве С++ компилируется в байт-код?? Это ведь не Java!

> Вон симбиан написали. И????

И что, плохая операционка?

BeOS тоже был на C++. Отличная штучка ;)

ожидаем глобальный переход на язык пасцал (pascal)!

>> И что, плохая операционка?

типа того...

BeOS был все-таки на C, а переписывают его уже на С++. А чем же с сишным ядром плохо живется?

На Си? Не знал. Раньше слухи ходили, что это было Pure C++, и что это давало серьёзные преимущества.

А с Сишным всё нормально ) Мне просто на самом деле интересно просто, почему же не используют Си++.

> На Си? Не знал. Раньше слухи ходили, что это было Pure C++, и что это давало серьёзные преимущества.

Преимущества полагается предавать огласке. Минимум - тут, в идеале - мылом Линусу и на lkml.

> А с Сишным всё нормально ) Мне просто на самом деле интересно просто, почему же не используют Си++.

Вопрос ставится неправильно. А должен быть разбит на 3:

1. зачем пихать нечто во все щели? 2. зачем вообще использовать с++ для написания кода ядра, если есть с? 3. зачем вообще использовать что-то сложное, если есть нечто более простое, полностью покрывающее потребности?

Ну и вспоминаем собственно времена когда ядро писалось, наличие стандартов, до сих пор не устаканенный ABI, и т.п. Потом понимаем, почему таки с++ не используется. Собстна, каким хреном потом делать из glibc системные вызовы? Сначала ядро на с++, потом в него сувать врапперы для обеспечения совместимости, потом - ... что получим? ;)

Патамушта C++ язык программирования более высокого уровня. А выхлоп от этого высого уровня есть только в прикладном софте. В системном софте инкапсуляция, наследование - как козе баян, да и еще сильная потеря производительности, так как системный софт - критическое место. Еще неочевидный плюс, С - устоявшийся язык, с конца 70 не менялся, а C++ - постоянно новые вариации, не меньше 2х за последнии 10 лет.

Каким боком системные вызовы glibc связаны с языком, на котором написано ядро? Там-же не прямой вызов. =)

ABI компилятора меняется не так часто, как сейчас ABI ядра.

1. Хороший, блин, вопрос. Почти даже риторический, правда C++ ни кто ни куда не пихает.

2/3. Зачем использовать C, если есть asm? Imho C++ не от нефигделать придумывали.

>В системном софте инкапсуляция, наследование - как козе баян, да и еще сильная потеря производительности

В каком именно месте потеря производительности? И почему именно в системном софте не важна инкапсуляция? Imho она везде важна, и это больше относится к проектированию.

>Еще неочевидный плюс, С - устоявшийся язык, с конца 70 не менялся, а C++ - постоянно новые вариации, не меньше 2х за последнии 10 лет.

C98? И что хорошего в том, что якобы "с конца 70 не менялся"?

Imho они оба устоялись, и уже достаточно давно.

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

Нет слов, одни эмоции. В том, что С++ заимствовал у Си, С++ б-и-н-а-р-н-о совместим с Си. Какой нахер байт-код, что вы курите?

> Патамушта C++ язык программирования более высокого уровня. А выхлоп от этого высого уровня есть только в прикладном софте.

Почто так. Однако Си точно так же является языком высокого уровня. Дело в том, что ядро Linux тесно взаимодействует с железом и в нем используются только встроеные типы данных и близкие к встроенным. Там уровни абстракции и принципы сокрытия данным не используются. Linux очень плотно работает с железом, в отличии от того же Solaris например и возможности С++ ядру не нужны.

> Нет слов, одни эмоции. В том, что С++ заимствовал у Си, С++ б-и-н-а-р-н-о совместим с Си. Какой нахер байт-код, что вы курите?

Ниасилил вашу логику, вообще-т я говорил про моск ;) Так что еще вопрос кто из нас и что курит... прямо с утра ;))

> Почто так. Однако Си точно так же является языком высокого уровня.

Бобер, выдыхай, с - это на самом деле прикинувшийся шлангом питон.

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

> Дело в том, что ядро Linux тесно взаимодействует с железом и в нем используются только встроеные типы данных и близкие к встроенным. Там уровни абстракции и принципы сокрытия данным не используются. Linux очень плотно работает с железом, в отличии от того же Solaris например и возможности С++ ядру не нужны.

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

> Ниасилил вашу логику, вообще-т я говорил про моск ;) Так что еще вопрос кто из нас и что курит... прямо с утра ;))

В таком случае, не нужно нести ахинею и тем самым вводить заблуждение остальных. С логикой у меня всё в поряде, вот с телепатическими способностями туго. Это у вас утро, у нас уже рабочий день к концу близится :)

> Каким боком системные вызовы glibc связаны с языком, на котором написано ядро? Там-же не прямой вызов. =)

Угу, там вызов через кроссплатформенный графический интерфейс на Tk.

Аффтар, может на .NET сразу перепишем, чтобы вообще от языка не зависеть? :)

> ABI компилятора меняется не так часто, как сейчас ABI ядра.

Еще одно угу... а если абстрагироваться и подумать, что есть не только gcc на свете? ABI ядра = ABI любого сишного компилятора, по сему поводу вообще думать не нужно, что есть великий плюс С.

> 1. Хороший, блин, вопрос. Почти даже риторический, правда C++ ни кто ни куда не пихает.

XML - тоже не пихают, а некоторые далбайопы даже логи в него пишут метров по 30-40, и потом xslt-парсером в рантайме разгребают... аналогия ясна? ;)

> 2/3. Зачем использовать C, если есть asm? Imho C++ не от нефигделать придумывали.

Дык не отмазка, на асме писаны критические участки кода, все в порядке с этим. С++ придумали ИМХО на свою голову именно от нечего делать, т.к. единственный его опосредованный плюс - возможность в IDE просматривать классы деревьями, но сие перебивается косяками и недостатками.

> В каком именно месте потеря производительности? И почему именно в системном софте не важна инкапсуляция? Imho она везде важна, и это больше относится к проектированию.

Угу, а ты тоже выдыхай :) Вот ты сказал "везде важна" - согласно правилам, и будь добр это доказать, т.к. что-то утверждаешь. Непонятно в каком месте? Ну давай тогда писать софт вообще без оптимизаций, хуле, железо прогрессирует, ядра становятся все толще. Глядишь там через годик напишем ядро, которое под себя будет требовать ресурсы достаточные для параллельного запуска трех Свист от мелкософта.

> C98? И что хорошего в том, что якобы "с конца 70 не менялся"?

ABI, прогрессировали оптимизаторы, etc. Стабильность всегда хороша.

> Imho они оба устоялись, и уже достаточно давно.

4.2.

> В таком случае, не нужно нести ахинею и тем самым вводить заблуждение остальных. С логикой у меня всё в поряде, вот с телепатическими способностями туго. Это у вас утро, у нас уже рабочий день к концу близится :)

Офттопик... на КГ/АМ вы все же не тянете ;) И разумеется чего-то конструктивного от вас как... дождаться можно? ;)

> А если серьезно - то с сейчас является практически макроассемблером, 
> а с++ - таки средне-высокий уровень. Ну то есть эволюция, 
> классификации меняются, мозги скрипят.

Оно и заметно, что скипят.  :)))

- Карэн, а срэднэ-вэсокий уровэн язэка программирования, это как?
- Срэднэ-вэсокий, Гоги, это на уровнэ груд.

> Нет слов, одни эмоции. В том, что С++ заимствовал у Си, С++ б-и-н-а-р-н-о совместим с Си. Какой нахер байт-код, что вы курите?

Вперед, как только предоставите либку, написанную на чистом С++, без костылей типа `extern "C"`, и могущую подгружаться любым чисто С-шным бинарником, написанным в пару - тогда респект, а пока что низачот ;) Или для последовательности пущей - модуть ядра на С++, то будет здорово. ведь он БИНАРНО совместим с С.

> В таком случае, не нужно нести ахинею и тем самым вводить заблуждение остальных. С логикой у меня всё в поряде, вот с телепатическими способностями туго. Это у вас утро, у нас уже рабочий день к концу близится :)

Гм... может стоит к родине поближе, чувство юмора прокачать, эээ? :)

> Оно и заметно, что скипят. :))) > > - Карэн, а срэднэ-вэсокий уровэн язэка программирования, это как? > - Срэднэ-вэсокий, Гоги, это на уровнэ груд.

Хороший вечер, дарагой, эээ? ;) Вот такие вот грудастые и предлагают писать ядро на с++ %))

Лана, если с - высокий уровень, то асм выходит - средний. И что тогда является низким? Мсье тру-хардкорный кодер в машинных кодах? :)

> Вперед, как только предоставите либку, написанную на чистом С++, без
> костылей типа `extern "C"`, и могущую подгружаться любым чисто 
> С-шным бинарником, написанным в пару - тогда респект, а пока что 
> низачот ;) 

В чем костыльность extern инструкций? Они нужные для однозначного 
определения принципа линковки смешеного кода, в принципе без них можно 
тоже обойтись в ущерб переносимости.

$ cat misc.cc
#include <stdio.h>  
#include <stdlib.h> 
                    
int main() {        
  int i = 4;        
  printf("%i\n", i);
  return 0;         
}                   
$ g++ misc.cc -o misc
$./misc
4
$

> Или для последовательности пущей - модуть ядра на С++, то будет 
здорово. ведь он БИНАРНО совместим с С.

Для меня это проблематично, т.к. я для ядра модулей не писал. Почему бы вам самому не попробовать.

> Вперед, как только предоставите либку, написанную на чистом С++, без
> костылей типа `extern "C"`, и могущую подгружаться любым чисто 
> С-шным бинарником, написанным в пару - тогда респект, а пока что 
> низачот ;)

Пардон. Да, в случае с C++ либами, Си-шный бинарник компилируется средствами C++. Это проблема?

> В чем костыльность extern инструкций? Они нужные для однозначного определения принципа линковки смешеного кода, в принципе без них можно тоже обойтись в ущерб переносимости.

А зачем нам такие извраты как смешанный код? Т.е. фактически С++ не имеют обратной совместимости с С-коммпиляторами. Костыльность их в том, что даже такой "великолепный" и "удобный" язык, как С++ не смог обойтись без обратной совместимости поначалу, а чуть позднее - от нее избавиться, следствия очевидны - тащим еще и С-шные правила за собой, проявляя страшную непоследовательность.

> $ g++ misc.cc -o misc > $./misc > 4

А теперь `ldd ./misc` и сильно удивляемся лишней строчке.

> Для меня это проблематично, т.к. я для ядра модулей не писал. Почему бы вам самому не попробовать.

Я заранее знаю результат и в силу сего - неинтересно ;)

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

> Пардон. Да, в случае с C++ либами, Си-шный бинарник компилируется средствами C++. Это проблема?

Это проблема. См. calling consentions и т.д. и т.п. Ну и о mangling ни в коем разе не забываем, dlsym() по одной и той же строке корректно отработает в С с лохматого года, чего нельзя вообще сказать о С++.

Вообще - даже в коротеньком треде уже проблем с плюсами нашли с десяток, все еще просматривается необходимость переписывать ядро на с++?

> Каким боком системные вызовы glibc связаны с языком, на котором написано ядро? Там-же не прямой вызов. =)

>Угу, там вызов через кроссплатформенный графический интерфейс на Tk.

>Аффтар, может на .NET сразу перепишем, чтобы вообще от языка не зависеть? :)

Поправьте, если не прав, но вызов там проходит через прерывание.

http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html

Поэтому mangling врядли особо помешает. Я говорил об этом.

>Еще одно угу... а если абстрагироваться и подумать, что есть не только gcc на свете? ABI ядра = ABI любого сишного компилятора, по сему поводу вообще думать не нужно, что есть великий плюс С.

imho 99% модулей ядра компилятся gcc(асмовые куски на gas ни чем другим не скомпилишь), хотя согласен, возможны проблеммы с закрытыми дровами.

>XML - тоже не пихают, а некоторые далбайопы даже логи в него пишут метров по 30-40, и потом xslt-парсером в рантайме разгребают... аналогия ясна? ;)

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

>Дык не отмазка, на асме писаны критические участки кода, все в порядке с этим. С++ придумали ИМХО на свою голову именно от нечего делать, т.к. единственный его опосредованный плюс - возможность в IDE просматривать классы деревьями, но сие перебивается косяками и недостатками.

Пример на инкапсуляцию: Не встречали в описании функций ядра "Чтобы вызвать эту функцию зажмите спинлоки A и B, если забудите отпустить то будет жопа", может не стоит такую функцию делать public, а стоит сделать к ней wraper, зажимающий и отпускающий спинлоки?

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

Полиморфизма там и сейчас хватает, правда через жопу сделанного, но хватает.

Насчет асма: Ни кто не мешает делать вставки на асме, и особых тормозов от одного слова class тоже не прибавится. Почему из фразы "на C++" следует, фраза "без оптимизации"?

Успокойтесь, никто ядро на С++ переписывать не собирается. А проблем я как-то не узрел :)

P.S: Что есть consentions?

conv*

> В чем костыльность extern инструкций? Они нужные для однозначного определения принципа линковки смешеного кода, в принципе без них можно тоже обойтись в ущерб переносимости.

>А зачем нам такие извраты как смешанный код? Т.е. фактически С++ не имеют обратной совместимости с С-коммпиляторами. Костыльность их в том, что даже такой "великолепный" и "удобный" язык, как С++ не смог обойтись без обратной совместимости поначалу, а чуть позднее - от нее избавиться, следствия очевидны - тащим еще и С-шные правила за собой, проявляя страшную непоследовательность.

Imho "великость" и "удобность" языка C++ как-раз в том и состоит, что он не пытался отказываться от совместимости с C по языку. И совместимость есть, но только там, где это возможно. В mangled именах записана инфа о классах, namespace-ах и т.д., чего просто нету в C => компилер не может потдержать совместимость без extern C. При этом практически все, что есть в C до C99 есть в C++ => без особых проблем в эту сторону совместимость сохраняется.

>Одна из причин проста - ядро собирается с `-nostdinc`, а посему как минимум в ядро придется засунуть все С++-ные интерфейсы, и еще и либку статически загнать не забыть. А такое счастье как увеличение потребления памяти в пару раз на ровном месте разве нам нужно?

В ядре врядли потребуется stl(как и вообще шаблоны), потоки, exception-ы и большая часть стандартной библиотеки плюсов, а вот сам язык(синтаксис и т.д.) imho весьма мог-бы. От этого память не вздуется.

>Успокойтесь, никто ядро на С++ переписывать не собирается.

Согласен.

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

> Imho "великость" и "удобность" языка C++ как-раз в том и состоит, что он не пытался отказываться от совместимости с C по языку. И совместимость есть, но только там, где это возможно. В mangled именах записана инфа о классах, namespace-ах и т.д., чего просто нету в C => компилер не может потдержать совместимость без extern C. При этом практически все, что есть в C до C99 есть в C++ => без особых проблем в эту сторону совместимость сохраняется.

Правильно. но если все что нужно по определению есть в С, зачем С++? Типа рекурсивно заменить "gcc" в мэйкфайлах на g++? :)

> В ядре врядли потребуется stl(как и вообще шаблоны), потоки, exception-ы и большая часть стандартной библиотеки плюсов, а вот сам язык(синтаксис и т.д.) imho весьма мог-бы. От этого память не вздуется.

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

imho может помочь его лучше структурировать. Может помочь избегать мелких багов, т.к. компилятор более придирчивый(мелочь).

Потоки не всмысле thread, а в смысле iostream.

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

Лет через 10... когда подрастет поколение-пепси, не слышавшее вообще о таком языке как "С", запостите тему еще раз ;)

Криминал - в "взяли работающее, сломали и начали строить новое".

Интересно же!

=)

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