TCCBOOT - динамическая компиляция ядра при загрузке

ядро написано на шарпе и компилица джаст-ин-тайм компайлером от мелкософта

хм, интересно однако. нужно будет попробовать. а под 2.6 не работает?

объясните убогому, а кому это надо?

только я что-то догнать не могу, нафига эта сборка при каждой загрузке??? что она дает-то? не проще ли один раз скомпилировать и потом юзать долгое время? кто нить объяснит?

ну видимо чисто по советски - "а шоб було" =)

Pi, вот и я про тоже...наверное чтобы повыпендриваться=) мол, вы все ломаки, юзаете одни и теже бинарники ядра, а я крутой кул-хацкер компилирую находу...

naverno chtob pokazat' chto gcc eq suxx

WARNING: don't try to play with TCCBOOT unless you are a kernel hacker!

Selecter, спасибо (я про цитату...), теперь все понятно. я был прав, сказав "кул-хацкер" (см. 5-е сообщение)=)

LiveCD в перспективе могут стать вконец офигевшими по части плотности прилегания к hardware, да и вообще - оптимизация весчь сугубо полезная.

ой, сорри, не 5-е сообщение, а 6-е...

скажите, кто нить из вас уже тестил эту фичу? как она вам?

вообщем поделитесь впечатлениями, как только поюзаете...

а кто-нибудь можешь объяснить как 34M tar.bz2 засунут на 5.9M .iso?

или там ещё и мегаархиватор прилагается?

господа ракажите про этот интересный TCC (Tiny C compiler)

Однакооооо....

нет предела человеческому извращению =)

Компилиться быстро и сгенеренный код тормозит немеряно.
Вот это я панимаю 2 в 1!

Эту хренотень не пробовал, но то что он написал QEMU - respect!!!

Офигеть...

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

Это не получится. Tcc - только для с. Поэтому весь дистрибутив будет сложно собрать.

ребята идут дальше gentoo - one-time-kernel ;) следующим шагом, само-собой, будет сборка всей системы в момент загрузки. загрузчик будет спрашивать, какие программы сегодня нужны и собирать их, причем, за те же 15 секунд ;)

о! или даже так. программы будут собираться как только юзверь пытается их запускать.

пить надо меньше. меньше надо пить (с) "с легким паром"

> программы будут собираться как только юзверь пытается их запускать.

Тоже мне, рокит саиенс. Сто лет в обед. JIT зовется.

>о! или даже так. программы будут собираться как только юзверь пытается >их запускать.

все равно быстрее knoppix'а будет работать ;)

Интересно, а какой в этом смысл? Какова цель?

> о! или даже так. программы будут собираться как только юзверь пытается их запускать.

... что окончательно погубит технологию RPM ;)

> Интересно, а какой в этом смысл? Какова цель?

Для разработчиков ядра возможно такое может быть удобно.

Да, звучит логично...

> объясните убогому, а кому это надо?

В принципе - никому (это на /. уже разжевали и выяснили, что принципиально сие ничего нового не дает). Но просто весело =) Это из того же разряда, что и веб-сервер на PHP. Хотя, кто знает, может сему чуду и найдут практическое применение...

На самом же деле, есть сильное подозрение, что это такой своеобразный промоушен для TCC: все-таки собрать ядро за 15 секунд - это сила.

А еще, как отметил кто-то на слэшдоте, кернелхакеров теперь низвели практически до статуса скриптописателей =)

> Интересно, а какой в этом смысл? Какова цель?

Вот, придумал!

Надо сваять LiveCD, на котором ядро будет при загрузке собираться с оптимизацией под проц. Можно даже дать юзеру флаги компиляции выбрать: "масса, вам с -O2, чтоб все медленно ползало, или с -O3, чтоб все быстро падало?" =)

Достаточно при загрузке ядро _линковать_, а не компилировать. А все "полуфабрикаты" (*.o) с разными оптимизациями держать наготове.

Хотя это ничем и не отличается от загрузки ядерных модулей, только линковка статическая вместо динамической -- можно поэкономить на вызовах функций. ;)

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

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

этот TCC сам по себе много места занимает? у меня вот GCC на хард не влезает -- cвободных 50Мб только, потому ядро пересобрать не могу. TCC поможет или нет?

>этот TCC сам по себе много места занимает? В архиве 147 Kb...

>а под 2.6 не работает ?

С ходу не получилось собрать, патч ,видать, надо... (((

вообще , я сомневаюсь что можно что либо существенное с помощью него

собрать, во всяком случае без подготовки...

147 Kb ... мдя... при таких размерах компилятор С

должен быть гениальным чтобы что нибудь собирать ... )))

там в архиве исходники которые предлагается собирать GCC :L((((

Ну а потом автор начнет ваять свой тцц до уровня гцц и получим все теже 15 минут компиляции ядра. Может действительно надо гцц более модульным сделать? Не таким огромным, авось и сможет хотя бы за 30 секунд, но собрать ядро и все прочие проги.

Just for fun, гы, гы :)

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

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

а слаку под слакой он компилирует?

> Для разработчиков ядра возможно такое может быть удобно.

Золотые слова! Именно для разработчиков ядра, или для тех кто пытается работать в этом направлении. Конечно собирать ядро каждый раз при старте - ИМХО маразм, но вот боротся с его "странностями" экспериментальным путем гораздо легче.

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

так ему ж все равно glibc и /usr/lib/include надо для компиляции

на дискету никак не влезет. на ZIP 100-мегабайтный, это да.

может когда-нибудь Патрик его в zipslack включит

может оно и так, да не так. ядро собранное GCC и ядро собранное TinyCC -- не одно и то же ядро.

ММММ! Вобщем - то да... не подумал... Но вечерком обязательно попробую. А то все торкает дикое желание "побороть" во фрэймбуфере "снег" при переключении видеорежимов, а при том, что кернел-хацкер из меня никакой (пока), приходится действовать методом "подправили-собрали-посмотрели-обломились" ;).

Уважаемые, может я настолько туп, но что-то это пахнет лажей...

Я все не пойму - компилятор-то как работает? Ему ведь тоже ресурсы немалые нужны - обращение к файлам, выделение памяти, там еще что-то. Кто этим всем рулит? Или у него еще и ядро свое есть, под которым он другое ядро компилит, а потом еще его и подгружает???????

А ты бы по ссылке сходил, да скриншоты посмотрел...

TCCBOOT reads C or assembly sources from a gzipped ROMFS filesystem stored in an Initial Ram Disk (initrd). It first reads the file 'boot/tccargs' which contains the TinyCC command line (same syntax as the tcc executable). The TinyCC invocation should output one binary image 'kernel'. This image is loaded at address 0x00100000. TCCBOOT then does a jump to the address 0x00100000 in 32 bit flat mode. This is compatible with the ABI of the 'vmlinux' kernel image.

Да и вообще

http://fabrice.bellard.free.fr/tcc/tccboot_readme.html

>о! или даже так. программы будут собираться как только юзверь пытается их запускать.

Да. именно для этого он и задумывался:

#!/usr/local/bin/tcc

void main() { printf("Hello World"); }

При таком запуске он компилирует в память и тут же запускает.

>Надо сваять LiveCD, на котором ядро будет при загрузке собираться с оптимизацией под проц. Можно даже дать юзеру флаги компиляции выбрать: "масса, вам с -O2, чтоб все медленно ползало, или с -O3, чтоб все быстро падало?" =)

После того, как допишешь в tcc оптимизацию. (С сохранением скорости компиляции)

>этот TCC сам по себе много места занимает? В архиве 147 Kb...

У этого типа есть еще otcc, так тот вообще около 4Кб занимает.

>при таких размерах компилятор С должен быть гениальным чтобы что нибудь собирать ... )))

Он таки и есть гениальный.

>там в архиве исходники которые предлагается собирать GCC :L((((

Если я правильно помню, его потом можно пересобрать им-же самим.

> не проще ли один раз скомпилировать и потом юзать долгое время?

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

>#!/usr/local/bin/tcc

>void main() { printf("Hello World"); }

GCC с такими штуками выдаёт invalid preprocessing directive #!

>Я лично не вижу других причин перезагрузки линкусовых машин кроме как смена ядра.

Ноутбук? Экономия электроэнергии? Звук кулеров мешает кому-то спать?

перезагружать ноутбук с линуксом? а apm на что?

(сабж классный)