Ебаные красноглазики, сука-блядь, поубывав бы! Чо-то нахуевертят, напидорасят, блядь, своими руками ижжопы! Десять конфиругационных файлов, один ссылается на другой, якобы, чтобы было "удобно". Хочешь что-то изменить под себя и понимаешь что надо менять сразу в нескольких местах.
Пытаешься разобрацца в этом говне, чтобы как-то его использовать, продираешься сквозь ибаные дебри зависимостей зависимостей зависимостей, а когда тебе кажется, что ты уже видишь свет в конце тоннеля, они хоп - уже всё переделали! Получилось то же самое говно или чуть лучше, но - абсолютно другое. И у тебя есть выбор - послать их нахуй или начать всё заново. Точнее, послать-то ты можешь только заочно. Ну или вот, в тырнете написать.
читать дальше
Но обо всём по порядку. Я откомпилировал всё это говнище, которое перечислено в их книжке-инструкции и даже немножко постиг дзэн ГНУ-Линукса. Казалось бы, всё! Ещё немного, и ты получишь результат, ради которого столько ебался. У меня впереди было два тихих выходных на работе. Один день я потратил, чтобы перенести эту хрень с каталога на виртуальный диск плюс ещё докомпилинг доп.пакетов. Ну, тут они ни при чём, с каталога на диск это моя инициатива - они в самом начале предупреждали, что нужен хотя бы отдельный раздел. Второй день я целиком посвятил ебле с ядром. Безрезультатной.
Для тех, кто не в курсе - дело в том, что стандартное ядро не знает, на каком оборудовании ему придётся запускаться. И для успешного запуска главное это опознать диск (контроллер диска), на котором лежит собсно операционная система. Для этого есть два пути. Первый - внедрить в код ядра драйвера всех возможных дисков. Получится охуенно большое ядро, ну как охуенно, нормальное в целом, на десяток мегабайт больше, короче, больше обычного. И поскоку система ставится один раз и стоит на одном и том же компе годами, то все эти драйвера будут загружаться и висеть в памяти зря.
Второй путь - оформить драйвера в виде подгружаемых модулей. Тогда в памяти будет висеть только то, что нужно. Но тут проблема - если модули отдельно от ядра, то они лежат на диске. А чтобы получить доступ к диску, внезапно нужны модули, которые лежат на диске.
Для этого придумали такую штуку - initramfs. Это такой архив, в который запакованы все драйвера и библиотеки, которые могут понадобиться, а в ядре ничего нет. Архив лежит рядом с ядром, при загрузке загрузчик помещает в память ядро и архив и передаёт управление ядру. Ядро своими щупальцами дотягивается до архива, находит нужные ему драйвера, монтирует диск, и загрузка продолжается.
Во FreeBSD и вообще в *BSD такой хуйни нет, и ядро там - загружается. Зато в *BSD есть много другой хуйни, которая сводит на нет все преимущества, и о которой мы поговорим позднее. Может быть.
Дык вот, а не похуй ли нам? Ну загружается как-то там и ладно. Мне в общем тоже было похуй до того момента, когда в LFS наступил последний шаг - сборка ядра. Они там предлагают собрать ядро БЕЗ initramfs. Ядро собирается, стартует, но подцепить диск не может. Теоретически, если вкомпилить в ядро нужный модуль, точнее, несколько нужных, оно загрузится. Но только на этой машине, а если на другой машине стоит другой драйвер диска, то там оно снова споткнётся. Но это дело будущего, а сейчас надо хотя бы понять, какой драйвер подоткнуть и как.
И если в память загрузить в initramfs одинокий драйвер без ничего, догадается ли ядро его там найти или ему кто-то должен сообщить? Ядро при загрузке выдаёт какую-то малоинформативную хуйню вроде Dump stack: 0x100ff и дальше куча цифр. Можно ли это как-то использовать или нет, хз.
Вообще, я никогда до этого не конфиругил ядро в Линукс. Не было необходимости. А вот во FreeBSD - конфирурил, и оно загружалось! Как дело было во FreeBSD - ты открываешь текстовый файлик и правишь параметры. Там куча комментариев, в которых написано, что за параметр и в каких случаях его включать. В целом несложно. Выкидываешь то, что ненужно - поддержку всяких накопителей на магнитной ленте, перфокарт, перфолент и прочего, чего у тебя никогда не будет. Добавляешь то, что нужно - какой-нибудь там IPFW2, NAT и прочее, и потом компилишь.
В Линуксе перед тобой открывается шикарный псевдографический интерфейс с менюшкой с подменюшками. По нему можно лазить. А ещё есть графический тырфейс - аж целых два. Ух ты! - подумал я, почему же во FreeBSD до сих пор никто ничего такого не сделал? Потому что нихуя непонятно, что же ты на самом деле правишь. Ну или надо знать. Я скоро перешёл на текстовый файлик - так быстрее. В менюшке написано "Поддержка SCSI", ты включаешь, а что ты там включил - хер его знает. А в тырнете тебе пишут:
CONFIG_SCSI_MOD=y
CONFIG_SD_MOD=y
и именно это ты должен найти в файлике и включить. Нередко в разных местах.
Я нескоко раз пересобрал ядро с разными вариантами:
make menuconfig - запускает меню для конфигурации
make defconfig - стандартное ядро
make localmodconfig - собираем ядро со всеми модулями, которые есть на текущей машине
make localyesconfig - то же, что предыдущее, только модули вкомпилены в ядро
make nconfig - не помню, то такое тоже есть
Методом научного тыка и неистового гугления (вы же не думаете, что я бездумно собирал ядро?) я накопал, что у меня в VirtualBox используется
00:0d.0 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] (rev 02)
Для него нужны чо-то там AHCI. Модули, которые я нашёл в /lib/modules на своей машине
ahci.ko
libahci.ko
libata.ko
ahci_platform.ko
libahci_platform.ko
В общем чо-то типа того. В Гугле рекомендовали включить CONFIG_SATA_AHCI, CONFIG_SCSI_SATA_AHCI и мож ещё парочку. В LFS-машине можно прочитать файлик /lib/modules/4.12-7/modules.builtin - модули, вкомпиленные в ядро. Я получил все, кроме libata.ko
К вечеру я заебался, спиздил ядро и initramfs из Арча и подсунул его на свой LFS-диск. Похуй, что в LFS версия ядра 4.12, а в Арче 4.13, моё ядро вместе с Арч-initramfs загрузилось, а вот ядро Арча без своей initramfs - нет.
В GRUB2 тоже есть модули - файлы с расширением .mod (а у ядра с расширением .ko). Они нигде толком не описаны, хотя нет, пижю, вот апесание
blog.fpmurphy.com/2010/06/grub2-modules.html
Как я понял, это не то же, что модули ядра, это скорее как команды загрузчика. Например boot, linux это отдельные модули. Впрочем, иногда несколько команд упаковывается в отдельный модуль. Эти модули могут помочь загрузчику в загрузке ядра, а вот могут ли они помочь ядру - хер знает.
Я ваще прочёл несколько серьёзных (или пытающихся казацца таковыми) книг по Линуксу и нигде не сказано, как именно ядро определяет из всех драйверов нужный. Вот "как-то там" определяет.
Почти весь следующий день убил на то, чтобы разобраться как же собрать без Initramfs. Нашёл на archwiki, как в Арче генерится файл initramfs и как управлять его конфигурацией. Делаем так:
cd /etc/mkinitcpio.d/
cp linux.preset linux-1.preset
vim linux-1.preset
В нём правим ('default') на ('normal'), initramfs-linux.img на initramfs-normal.img, default_image на normal_image
normal_options="-S udev,keyboard,filesystem,fsck,block,autodetect,modconf" #тут перечисляем, что нужно исключить из будущего initramfs. Через запятую. А взято оно из строчки HOOKS=(... в /etc/mkinitcpio.conf
Сразу скажу - исключить можно всё, кроме base. Hook "base" содержит процесс init, без которого всё загибается.
В /etc/mkinitcpio.conf надо в пункт MODULES=() включить те модули, которые нам нужны. Как узнать, какие? Эт я определил на своей виртуалке под Арчем с помощью modinfo & lsmod.
Запустить LFS надо на той же самой виртуалке = оборудование одинаковое. ??? PROFIT!
lsmod перечиляет загруженные модули, modinfo module_name|grep depend даёт строчку модулей, которые зависят от module_name. А значит, если ты загрузишь один из них, module_name подгрузится автоматически, как необходимый. Загружено было около 70 модулей, из них я отследил следующие связанные:
ahci, libahci, libata, ata_piix, ata_generic, pata_acpi, scsi_mod, sd_mod, sr_mod, cdrom
Вот про scsi_mod & sd_mod хер бы я когда догадался сам. Я-то всё задрачивал на *ahci* & *libata*.
Короче, в стоку в /etc/mkinitcpio.conf включаем следующее MODULES=(ext4 ahci sd_mod). Остальное всё подгрузится автоматически. В HOOKS там же можно включить HOOKS=(base) и тогда скомандовать mkinitcpio -p linux-1, после чего в /boot окажется компактный initramfs-normal.img.
Надеюсь, это всё вам очень пригодилось. Следующим пунктом исследований будет как вкомпилить всю эту хрень в ядро и загрузится ли ядро без initramfs в принципе? init-то у него не будет.
У меня вот нет очучения, что я узнал чо-то там полезное, сокровенное. Так, будто в куче говна какой-то порылся, время убил, ни хрена не понял, но хоть результат есть, и на том спасибо.
Эээ, старался объяснять как можно доступнее
Ты доступно объяснил, но я говорю, вообще, об этой сфере, а не только о Линуксе.
Что на самом деле думали
А на самом деле думали
Люди те, что их придумали (с) - где-то прочитал
Ну, я понимаю, оно конечно, когда кто-то уже всё придумал, легко сказать, мол, а чо такого, всё же очевидно. Не хочу показаться таким, НО
примеров таких железяк - много. Волчья яма, например, силки, капканы, мышеловка. Можно спросить, мол, а где они "думают"? Правильно, думал, человек, который их сделал. Ну хорошо, вот флюгер или ветрорулевой на яхте. Но все эти машины "аналоговые", а эпоха компьютеров началась с цифровых устройств. До этого долгое время были аналоговые ЭВМ, потому что считать как-то надо было.
Да, компьютер логичнее, потому что там - понятно что к чему подсоединяется и для чего. Там нет такой хуйни как в Линухе - помойка из конф.файлов, непонятно что за что отвечает.
Вот этого-то я и не понимаю, как этот кто-то додумался и как это может запоминать.
Запоминает как - да просто - там два реле закольцованы. У тебя два провода. На первый ты подаёшь сигнал о том, что щас надо будет запоминать (строб), на другой - что именно запоминать. Ну там либо высокое, либо низкое напряжение. Всё. На выходе триггера после снятия стробирующего сигнала будет нужное напряжение. И когда таких штук много собирается, тут-то и начинается настоящий пиздец!
И да, после появления триггера, кто-то должен был додуматься о перспективах, которые дают триггеры, а это не менее сложно, чем додумацца до триггера.
Но мы чо-то отвлеклись от обсирания красноглазиков
Есть 2 вида вычислительной техники - аналоговая и цифровая (дискретная, импульсная)
щас как раз цифровая рулит. Раньше была аналоговая. В аналоговой например число 5 могло быть представлено напряжением 5в, а суммирующие устройства суммировали например 2 входных напряжения и получалось 5+5=10в. или там 5+6=11в. Но они никогда не считали абсолютно точно, это ж не идеальные, а реальные резисторы или чо там было - они никогда не были абсолютно одинаковыми, поэтому решали задачу примерно, с погрешностями, было некоторое дрожание напряжения, зато результат на выходе появлялся мгновенно. Как токо изменились данные на входе, мгновенно менялись данные на выходе.
Дискретные устройства работали абсолютно по-другому. В них число 5 это всегда 5, не 5.01, не 4,99. Если на аналоговых 5в грубо говоря можно было подать на одном проводе, то тут провода требовалось уже три, т.к. щитали эти дискретные устройства в двоичной системе - 0 или 1, есть сигнал или нет сигнала.
000 - 0
001 - 1
010 - 2
011 - 3
100 - 4
101 - 5
Таким образом для числа 5 требовалось 3 провода - 3 разряда шины данных. Но их никогда не делали 3, делали минимум 4 (меньше не имело смысла), потом стали делать 8, 16, 32, 64 и т.д. Целые степени двойки. Иногда снабжали одним дополнительным проводом для контроля чётности.
Чтобы складывать эти числа требовалось Арифметическо-логическое устройство. Оно формировало логику сложения
0+0=0
0+1=1
1+0=1
1+1=0 и 1 переноса в следующий разряд. Умножение можно свести к сложению (как в столбик делают)
Всё это делалось потактово - такты задавал тактовый генератор и числа знач передвигались в этом устройстве, разряд переносился, потом складывались старшие разряды, потом ещё более старшие и т.д.
В этом случае сложение-умножение происходило не мгновенно, в отличие от аналогового варианта.
ну и дальше это всё усложнялось, транзисторы уменьшались в размере, их больше влезало на кристалл, они потребляли меньше энергии, тактовые частоты росли, и щас имеем то, что имеем.
Щас вот уже процессоры разгонять больше не могут, стали ядра дополнительные делать - 4х ядерный проц, 10 ядерный и т.д.
т.е. в компах всё относительно просто, сложности возникают с ПО. Как распараллелить задачу на нескоко процессоров или ядер, чтобы повысить производительность? Далеко не все задачи позволяют такое делать.
Как синхронизировать между собой отдельные потоки одной задачи, чтоб они одно и то же не выполняли и т.д?
Ну и раньше конструкторы РЭА выжимали всё из электроники, а прогеры напрягались писали компактные программы, экономили каждый байтик. А щас что? Компы мощные, памяти до хера, прогеры расслабились, лапки свесили и пишут какую-то неповоротливую хуету. Авось комп перемелет, он же мощный. Вследствие чего современные компы умудряются тормозить.
А, вот. Должны были появиться ещё полупроводники - материалы, которые проводят ток только в одном направлении, т.к. при строительстве компов широко используются транзисторы, диоды и прочие полупроводниковые штуки.
Мог бы, но об этом не пишут. Транзисторы, диоды, шины - это всё херня, это я понимаю, не понимаю как они "думают" и как человеческая мысль могла дойти до того, чтобы сначала возникнуть, а после и воплотиться.
А до этого они действовали по заданной программе в основном. Ну вот раньше были всякие шарманки и прочее, которые могли играть мелодию, грампластинки. А тут то же самое, токо оно ещё может ветвиться очень сильно. Если таких ветвлений много, то и кажется, что они думают, а на самом деле хуячат по жёско заданной программе. условие выполняется или нет и попёрли либо по ветке А либо по Б
Вот ты если пейсал проги, наверное замечал, что там нельзя сделать "ну как-то там пусть сделает и всё", там всё нужно явно прописывать (и это бесит) вот, открываешь ты файл. не удаётся расшифровать путь - ашыбка, надо решать чо делать, нет такого файла - тоже, файл не читается - тоже, внутри файла не то, что ожидалось - тоже. Т.е. сам комп ничо решать не будет.