LINUX.ORG.RU
 

[мерялка]размер ядра


0

1

Прошу накидать статистических данных по размеру ядра. Формат примерно такой:

я, Вася Пупки, ядро дистрибутивное сам, все драйвера в модулях, initramfs вкомпилена в ядро, размер ядра 5.02 Мб, суммарный размер модулей 6.3 Мб

я, Глеб Мизгирь, ядро конпелял сам, монолитное, initrd внешний, ядро веси 15 Мб, initrd ещё 4.

И так далее.

UPD: Очень хотелось бы увидеть тут тех, у кого запущенные кеды и тормозилла всего сто метров памяти отожрали.

UPD2: если у вас суммарный размер этого добра (ведро+модули) меньше 4 Мб , можете похвастаться, как оптимизировали


 ← 1 2 →
[#] Ответ на: комментарий от gentoo_root 03.02.2012 19:53:25  
>>-----Цитата---->>

что, собственно, и делает моя initramfs или же может делать preinit-скрипт на корневой ФС

<<-----Цитата----<<

Если основной затык в devю. то есть devtmpfs, классная штука

** ()
[#]  
du /boot/3.0.4 
1371	/boot/3.0.4
 du -sh /lib/modules/3.0.4-ck/kernel/
3.2M	/lib/modules/3.0.4-ck/kernel/

Сжатия ядра xz, самосбор, Gentoo/

** ()
[#] Ответ на: комментарий от partyzan 03.02.2012 20:06:17  

Забыл написать, что initrd нет

** ()
[#] Ответ на: комментарий от partyzan 03.02.2012 20:06:17  
>>-----Цитата---->>

1371 /boot/3.0.4

<<-----Цитата----<<

Даже на version_string сэкономил байты?

** ()
[#] Ответ на: комментарий от gentoo_root 03.02.2012 18:42:48  
alfix

Мало ли что в модулях есть.

9,2M	/lib/modules/2.6.30.10/kernel/drivers/video/nvidia.ko

Покажи мне такую дискету.

()
[#] Ответ на: комментарий от kombrig 03.02.2012 17:00:04  
Lee_Noox

в холодной воде, добавь :D

** ()
[#] Ответ на: комментарий от alfix 03.02.2012 20:12:29  

На моей дискете всякого шлака не было: просто система, которая может загрузиться, смонтировать флешку и использовать busybox (busybox на дискете, на флешке ничего системного нет). Я не ставил себе цель постоянно работать с этой дискеты или чтобы она была совместима с множеством железа.

** ()
[#] Ответ на: комментарий от name_no 03.02.2012 20:02:40  
>>-----Цитата---->>

Если основной затык в devю. то есть devtmpfs, классная штука

<<-----Цитата----<<

Я его и использую. Но в общем случае, когда дистрибутив не делается под конкретную машину, неизвестно, нужен ли udev для монтирования /usr. По крайней мере, все распространённые дистрибутивы, не использующие systemd, запускают udev до монтирования /usr, значит, смысл в этом есть.

** ()
[#] Ответ на: комментарий от name_no 03.02.2012 20:08:56  

Так легче в грабе править. попробуй запомнить название ядра vmlinuz-my-ck-sources-3.0.4 и попробовать угадать как называется 3.2.1.

** ()
[#] Ответ на: комментарий от daemonpnz 03.02.2012 20:00:25  
>>-----Цитата---->>

Ещё раз тебя спрашиваю, почему система с systemd и отдельным /usr не загружается

<<-----Цитата----<<

4.2. Система с systemd и отдельным /usr загружается.

>>-----Цитата---->>

А без systemd, но с glibc/udev всё прекрасно грузится и очень даже шустро?!

<<-----Цитата----<<

Уж точно не шустрее, чем с systemd. И это всё зависит от конкретного железа. Если у тебя нету проблемной железки, то у тебя будет работать. У меня же не запускался bluetoothd при загрузке с включённым bluetooth, например, потому что udev запускался раньше монтирования /usr, а bluetoothd находится в /usr/sbin, и bluetoothd запускается правилом udev. Это называется «всё прекрасно грузится»?!

** ()
[#]  
post-factum

Я, post-factum, ядро компилю, понятное дело, сам, кое-что вкомпилено, кое-что в модулях, initramfs отдельно, размер ядра 3,4 Мб, размер модулей 7,8 Мб.

***** ()
[#] Ответ на: комментарий от Novell-ch 03.02.2012 17:12:36  
ms-dos32

А разве можно PE-загрузчик использовать на этапе загрузки ядра?

()
[#] Ответ на: комментарий от Lee_Noox 03.02.2012 20:15:27  
kombrig

Помнишь анекдот "у вас бы и не так скукожился"? Так это про меня.

* ()
[#]  

монолит 3 мб

* ()
[#] Ответ на: комментарий от Cancellor 03.02.2012 18:03:39  
doomgl
>>-----Цитата---->>

Васисуалий

<<-----Цитата----<<

Взбодрили

()
[#] Ответ на: комментарий от daemonpnz 03.02.2012 20:56:08  
>>-----Цитата---->>

Костыли ради костылей

<<-----Цитата----<<

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

Конечно, можно и SysVinit собрать с префиксом /usr, тогда ничего не загрузится совсем. Можно и init-скрипты положить в /usr/share/init.d, тогда тоже не загрузится. А чтобы грузилось, кладут SysVinit и init-скрипты в корневую ФС, чтобы они были доступны.

Точно также и systemd надо собирать с префиксом /, и его зависимости тоже делать доступными из корневой ФС (это я про dbus). То, что мейнтейнеры Генты не положили dbus в корневую ФС (хотя бы при установке определённого USE-флага) и даже не положили такой ебилд в оверлей systemd, — проблемы Генты, а не systemd.

Более того, сейчас в Генте вообще стали собирать и systemd с префиксом /usr, потому что бегут впереди паровоза. До этого они замаскировали ебилды новых версий systemd, пока не придумают решения для проблемы с /usr, но почему-то потом пропустили в ~arch ебилд, устанавливающий systemd в /usr.

systemd работает даже при /usr на отдельном разделе. При этом он способен сам его смонтировать, и работать всё будет не хуже, чем с SysVinit (systemd не решает проблемы udev и /usr, но новых проблем не добавляет). Но ебилды для systemd и для dbus составлены неправильно: они устанавливают эти пакеты в /usr, делая их недоступными на раннем этапе загрузки. Если составить правильные ебилды, то будет 2 варианта: либо без initrd, но проблема udev остаётся та же, что и с SysVinit; либо с initrd или preinit-скриптом в корневой ФС, монтирующими /usr и решающими проблему udev. С неправильными ебилдами остаётся только второй способ, т.е. таким радикальным способом мейнтейнеры Генты решают проблему udev, но при этом бегут впереди паровоза, т. к. они ещё не написали ни initrd, ни preinit-скрипт.

** ()
[#] Ответ на: комментарий от gentoo_root 03.02.2012 21:22:26  
daemonpnz

Делаем вывод из всей это простыни: systemd одна большая проблема.

**** ()
[#] Ответ на: комментарий от daemonpnz 03.02.2012 21:30:31  
>>-----Цитата---->>

Делаем вывод из всей это простыни: systemd одна большая проблема.

<<-----Цитата----<<

Вывод сделан неправильно: видимо, невнимательно читал. Правильный вывод такой: разрабы Генты криво пишут ебилды, нифига не могут поддерживать systemd, который может вполне нормально работать, если его правильно собрать. Правильно собранный systemd не решает проблемы udev, но не добавляет новых, при этом работает. Для решения проблемы udev, не имеющей ничего общего ни с SysVinit, ни с systemd, предназначен либо initrd, либо preinit-скрипт.

** ()
[#] Ответ на: комментарий от gentoo_root 03.02.2012 21:35:11  
daemonpnz
>>-----Цитата---->>

Для решения проблемы udev, не имеющей ничего общего ни с SysVinit, ни с systemd, предназначен либо initrd, либо preinit-скрипт.

<<-----Цитата----<<

Каких проблем?! Почему у меня оно просто работает?!

>>-----Цитата---->>

разрабы Генты криво пишут ебилды, нифига не могут поддерживать systemd, который

<<-----Цитата----<<

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

>>-----Цитата---->>

если его правильно собрать

<<-----Цитата----<<

то dbus всё равно будет в /usr и это проблема systemd, а не генты и её разрабов.

**** ()
[#]  
jcd

я, Глеб Мизгирь, ядро конпелял сам, монолитное, initrd внутренний, ядро весит 5 мб

*** ()
[#] Ответ на: комментарий от daemonpnz 03.02.2012 21:39:12  
>>-----Цитата---->>

Каких проблем?!

<<-----Цитата----<<

Я уже сказал. У меня не запускался bluetoothd при загрузке с включённым bluetooth и отдельным /usr, потому что он в /usr/sbin.

>>-----Цитата---->>

Почему у меня оно просто работает?!

<<-----Цитата----<<

Потому что у тебя нет железа, которое обрабатывается проблемными скриптами. Список проблемных скриптов: «grep -Er 'usb-db|pci-db|FROM_DATABASE|/usr' /{etc,lib}/udev/rules.d».

>>-----Цитата---->>

то dbus всё равно будет в /usr и это проблема systemd, а не генты и её разрабов.

<<-----Цитата----<<

Это не проблема systemd ни в каком случае, потому что dbus — зависимость systemd, значит, мейнтейнеры должны обеспечить его доступность во время запуска и работы systemd. Например, делается USE-флаг systemd, при установке которого dbus-daemon и libdbus устанавливаются в /bin и /lib. Если вдруг в какой-нибудь новой BolgenOS glibc будет установлено в /usr/lib, и система не загрузится, то это что, проблема SysVinit, что ли?!

** ()
[#]  
const86

Версия 3.2.2, без модулей, initramfs (для загрузки с LVM) внутри - 3916320.

***** ()
[#] Ответ на: комментарий от gentoo_root 03.02.2012 22:02:18  
daemonpnz
>>-----Цитата---->>

Это не проблема systemd ни в каком случае, потому что dbus — зависимость systemd, значит, мейнтейнеры должны обеспечить его доступность во время запуска и работы systemd.

<<-----Цитата----<<

Это проблемы systemd и лично Поттеринга, если его поделка требует перепиливания расположения системных файлов, то такая поделка на фиг не нужна. Для dbus можно было сделать отдельного демона, который бы запускался при доступности самого dbus.

**** ()
[#] Ответ на: комментарий от ttnl 03.02.2012 18:28:22  
buddhist

Ну, мне хотя бы справку от врача :D

*** ()
[#] Ответ на: комментарий от daemonpnz 03.02.2012 22:22:08  
>>-----Цитата---->>

Для dbus можно было сделать отдельного демона, который бы запускался при доступности самого dbus.

<<-----Цитата----<<

o_O Зачем нужно 2 демона, выполняющих одну и ту же функциональность? Ничего плохого нет в перемещении dbus в корень и установке симлинков на старых местах для обратной совместимости с кривыми программами, в которые захардкодены пути.

** ()
[#] Ответ на: комментарий от gentoo_root 03.02.2012 22:27:12  

Я чёт не понял щас. systemd зависит от d-bus, а библиотеки d-bus устанавливается в /usr/lib?

В таком случае пара вопросов.

1. Автор systemd е***ся что ли?

2. Статически слинковать не проще?

** ()
[#] Ответ на: комментарий от gentoo_root 03.02.2012 22:27:12  
daemonpnz

Кто говорил об одинаковой функциональности?! О_о

**** ()
[#] Ответ на: комментарий от name_no 03.02.2012 22:30:21  
daemonpnz
>>-----Цитата---->>

1. Автор systemd е***ся что ли?

<<-----Цитата----<<

А ты об этом только узнал?!

**** ()
[#] Ответ на: комментарий от daemonpnz 03.02.2012 22:30:33  
>>-----Цитата---->>

Кто говорил об одинаковой функциональности?! О_о

<<-----Цитата----<<

Тогда я вообще не понял, что это за набор костылей получится.

И да, как верно заметил name_no, можно и статически слинковать systemd с libdbus.

** ()
[#]  
stormblastt 
$ du -h /boot/vmlinuz-3.2.1-gentoo-r1
3.0M	/boot/vmlinuz-3.2.1-gentoo-r1

$ du -h /lib/modules/3.2.1-gentoo-r1/
252K	/lib/modules/3.2.1-gentoo-r1/misc
8.0K	/lib/modules/3.2.1-gentoo-r1/kernel/drivers/scsi
12K	/lib/modules/3.2.1-gentoo-r1/kernel/drivers
16K	/lib/modules/3.2.1-gentoo-r1/kernel
380K	/lib/modules/3.2.1-gentoo-r1/
** ()
[#] Ответ на: комментарий от gentoo_root 03.02.2012 22:37:22  
daemonpnz

А ещё он другое заметил, но ты это проигнорировал.

**** ()
[#] Ответ на: комментарий от daemonpnz 03.02.2012 23:33:29  
>>-----Цитата---->>

А ещё он другое заметил, но ты это проигнорировал.

<<-----Цитата----<<

Я не проигнорировал, на том предложении мой парсер вышел с кодом 1 и сообщением на stderr: «Вложенные *».

** ()
[#] Ответ на: комментарий от gentoo_root 03.02.2012 23:36:08  
>>-----Цитата---->>

Я не проигнорировал, на том предложении мой парсер вышел с кодом 1 и сообщением на stderr: «Вложенные *».

<<-----Цитата----<<

Я там предположил, что автор systemd — идиот, потому что написал init, который зависит от dbus — это надо быть на всю башку больным, что такое написать, а уж использовать это добровольно...

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

Ну так вот, в /usr по определению лежат те либы, которые а) не входят в базовый набор и б) могут запросто отсутствовать вообще. Init в системе нужен обязательно, а dbus — нет. Зависимость init от d-bus выдаёт в его авторе...

Собственно, когда я понял, что автор systemd так же является автором pulseaudio, всё встало на свои места.

** ()
[#] Ответ на: комментарий от name_no 03.02.2012 23:43:24  
>>-----Цитата---->>

Я там предположил, что автор systemd — идиот, потому что написал init, который зависит от dbus — это надо быть на всю башку больным, что такое написать, а уж использовать это добровольно...

<<-----Цитата----<<

D-Bus там нужен как интерфейс для управления systemd. SysVinit'ом, по сути, вообще нельзя управлять — только менять ранлевелы через /dev/initctl, чего явно недостаточно для нормального управления. systemd также поддерживает интерфейс /dev/initctl. А для нормального управления сервисами он выставляет интерфейс на D-Bus. Предложишь другой, лучший способ?

>>-----Цитата---->>

Ну так вот, в /usr по определению лежат те либы, которые а) не входят в базовый набор и б) могут запросто отсутствовать вообще. Init в системе нужен обязательно, а dbus — нет. Зависимость init от d-bus выдаёт в его авторе...

<<-----Цитата----<<

Здесь нарушена логика, потому что init нужен обязательно, но это не обязательно systemd. Если нет D-Bus, используй SysVinit. Если есть D-Bus, тогда можно использовать или SysVinit, или systemd. Поэтому init в общем не зависит от D-Bus и D-Bus таки необязателен.

>>-----Цитата---->>

те либы, которые а) не входят в базовый набор

<<-----Цитата----<<

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

** ()
[#] Ответ на: комментарий от gentoo_root 03.02.2012 23:54:34  
>>-----Цитата---->>

И почему он разный для разных дистрибутивов?

<<-----Цитата----<<

Для дистрибутивов, соответствубщих lsb, базовый набор — одинаковый.

Но на момент старта init базовым являются linux-utils, coreutils и libc и рассчитывать, что будут доступны другие — преступление против пользователя.

Хотя не могу не отметить, что во многих линуксах есть куча проблем, связанных с вольной трактовкой "базового набора". Например, если каталог etc смонтирован read-only, то ето жёппа, господа. Хотя никто не обещал, что этот каталог будет доступен на запись, на запись обещаны только /var и /tmp (ну и home, конечно). Или ещё вариант, если /var при старте системы пустой — половина хлама из init.d не запустится. Мало кто из них способен сам создать себе каталог /var/cache, если его нет.

Конечно, надо разработчиков лопатой бить, но почему-то их все защищают и поддерживают (дескать, нефиг делать read-only /etc и чистить /var и делать /usr на внешнем разделе). Меня это удручает.

** ()
[#]  
MrHouse
>>-----Цитата---->>

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

<<-----Цитата----<<

Это зависит от тормозилы или от железа?

* ()
[#] Ответ на: комментарий от stevejobs 03.02.2012 16:57:14  
MrHouse
>>-----Цитата---->>

монолитное, не получилось

<<-----Цитата----<<

ЛОХ!

* ()
[#] Ответ на: комментарий от MrHouse 04.02.2012 0:23:50  
>>-----Цитата---->>

Это зависит от тормозилы или от железа?

<<-----Цитата----<<

А как прожорливость тормозиллы зависит от железа?

** ()
[#] Ответ на: комментарий от name_no 04.02.2012 0:25:00  
MrHouse
>>-----Цитата---->>

А как прожорливость тормозиллы зависит от железа?

<<-----Цитата----<<

А как конфиг ядра зависит от тормозилы?

* ()
[#] Ответ на: комментарий от MrHouse 04.02.2012 0:27:22  
>>-----Цитата---->>

А как конфиг ядра зависит от тормозилы?

<<-----Цитата----<<

А как тормозилла зависит от конфига KDE?

** ()
[#] Ответ на: комментарий от name_no 04.02.2012 0:38:04  
MrHouse
>>-----Цитата---->>

А как тормозилла зависит от конфига KDE?

<<-----Цитата----<<

А как конфиг КДЕ зависит от конфига ядра?

* ()
 ← 1 2 →
Talks