Здравствуйте!
Скажите, а как выяснить, какие модули будут компилироваться при пересборке ядра, чтобы отказаться от лишних?
>Здравствуйте!
>Скажите, а как выяснить, какие модули будут компилироваться при пересборке ядра, чтобы
>отказаться от лишних?при пересборке ядра собираются все модули
http://www.freebsd.org/doc/en/books/handbook/kernelconfig-bu... - вот тут есть информация, что надо делать, если не хочется собирать все модулину или man make.conf
>[оверквотинг удален]
>>Скажите, а как выяснить, какие модули будут компилироваться при пересборке ядра, чтобы
>>отказаться от лишних?
>
>при пересборке ядра собираются все модули
>
>
>http://www.freebsd.org/doc/en/books/handbook/kernelconfig-bu... - вот тут есть информация, что надо делать, если не хочется
>собирать все модули
>
>ну или man make.conf:-)
Там написано КАК запретить, но не написано ЧТО запретить.
Конкретно в примере указаны модули linux, acpi, sound, ntfs.
Мне как раз и нужен список (с описанием) всех модулей, чтобы выбрать только нужные.
>[оверквотинг удален]
>>http://www.freebsd.org/doc/en/books/handbook/kernelconfig-bu... - вот тут есть информация, что надо делать, если не хочется
>>собирать все модули
>>
>>ну или man make.conf
>
>:-)
>Там написано КАК запретить, но не написано ЧТО запретить.
>Конкретно в примере указаны модули linux, acpi, sound, ntfs.
>Мне как раз и нужен список (с описанием) всех модулей, чтобы выбрать
>только нужные.ls /boot/kernel|grep -v kernel - список всех модулей
ну а потом man <имя модуля> и читаем-читаем-читаем до просветления :)
>ls /boot/kernel|grep -v kernel - список всех модулей
>ну а потом man <имя модуля> и читаем-читаем-читаем до просветления :):-)
Но это же издевательство - их там сотни!
>>ls /boot/kernel|grep -v kernel - список всех модулей
>>ну а потом man <имя модуля> и читаем-читаем-читаем до просветления :)
>
>:-)
>Но это же издевательство - их там сотни!после загрузки выполняем kldstat и смотрим какие модули подгрузились, их оставляем, а оставшиеся удаляем
>>>ls /boot/kernel|grep -v kernel - список всех модулей
>>>ну а потом man <имя модуля> и читаем-читаем-читаем до просветления :)
>>
>>:-)
>>Но это же издевательство - их там сотни!
>
>после загрузки выполняем kldstat и смотрим какие модули подгрузились, их оставляем, а
>оставшиеся удаляемкстати, да! только в make.conf нет переменной для модулей, которые надо собирать. есть модули, которые собирать не надо. так что список всех модулей все равно потребуется.
хотя есть переменная MODULES_OVERRIDE, которая устанавливает имена модулей для принудительной пересборки, но что будет, если удалены ненужные - не в курсе
>>ls /boot/kernel|grep -v kernel - список всех модулей
>>ну а потом man <имя модуля> и читаем-читаем-читаем до просветления :)
>
>:-)
>Но это же издевательство - их там сотни!ну так просил то что? :) список всех модулей :)
>>ls /boot/kernel|grep -v kernel - список всех модулей
>>ну а потом man <имя модуля> и читаем-читаем-читаем до просветления :)
>
>:-)
>Но это же издевательство - их там сотни!это не издевательство - это то, что ты просил
>после загрузки выполняем kldstat...Спасибо! Похоже, то, что надо. Жаль, конечно, что нет возможности выяснить, от чего отказываемся. Типа, как, например, тут: http://www.freebsd.org/doc/en/books/handbook/kernelconfig-co...
>Только в make.conf нет переменной для модулей, которые надо собирать.MODULES_OVERRIDE
This variable sets up a list of modules to build instead of all of them.А это не оно, разве?
Длеать нефиг или 2 Мб, которые занимают модули критичны? :)
Здгавствуйте!
С вашего позволения, переформулирую вопрос.
Я хочу подсократить время пересборки ядра за счёт отказа от компиляции лишних модулей.
Подскажите, пожалуйста, как можно это осуществить более-менее _нетрудоёмким_ путем.После чтения соотвт. статьи хэндбука появилось предположение, что модули как-то логично группируются (top level modules) и можно избежать "просветления" от изучения сотен "man <имя_модуля>".
Выше предложили вариант вообще удалить всё, что не загружается при старте, но это ведь может быть чревато, да?
>Здгавствуйте!
>С вашего позволения, переформулирую вопрос.
>Я хочу подсократить время пересборки ядра за счёт отказа от компиляции лишних
>модулей.
>Подскажите, пожалуйста, как можно это осуществить более-менее _нетрудоёмким_ путем.
>
>После чтения соотвт. статьи хэндбука появилось предположение, что модули как-то логично группируются (top level modules) и можно избежать "просветления" от изучения сотен "man <имя_модуля>".
>
>Выше предложили вариант вообще удалить всё, что не загружается при старте, но
>это ведь может быть чревато, да?На одном из форумов, был вопрос, а надо ли вообще использовать свое ядро или компилячить ядро под соответствующий процессор, или и то и другое вместе, в результате обсуждения большинство участников пришли к мнению, что при модульности ядра поддерживаемых сейчас версий фри и современных вычислительных возможностей компьютера это необходимо только для высоконагруженных систем или же откровенно слабых машин (память/проц), все остальное дает выигрыш 1-2% и в реальности не видно, посему используйте стандартное ядро GENERIC, а недостающие модули подгружайте через /boot/loader.conf. Все остальное от лукавого, только головная боль...
>посему используйте стандартное ядро GENERICСпасибо Вам, Сергей за ценнейшие сведения и щедрую рекомендацию!
>в реальности не видно, посему используйте стандартное ядро GENERIC, а недостающие
>модули подгружайте через /boot/loader.conf. Все остальное от лукавого, только головная боль...Пожалуйста, отконфигурьте мне на генерик-кернеле arp-прозрачный бридж. Или ipfw с форвардингом. Или с дивертом на нат или еще куда.
Мнение "большинства участников одного форума" не стоит ничего. Как и всякое мнение большинства.
>генерик-кернеле arp-прозрачный бридж. Или ipfw с форвардингом. Или с дивертом на нат или >еще куда.Бридж и диверт же загружаются модулями.
>Мнение "большинства участников одного форума" не стоит ничего. Как и всякое мнение
>большинства.Помню, кто-то довольно остроумно писал по этому поводу, что стоит только спросить, про, например, сапоги, как тут же большая часть сообщества разражается пространными рассуждениями про калоши и валенки. Это, похоже, какой-то врождённый дефект.
>>генерик-кернеле arp-прозрачный бридж. Или ipfw с форвардингом. Или с дивертом на нат или >еще куда.
>
>Бридж и диверт же загружаются модулями.Модуль бриджа генерик-кернела скомпилирован без опции IPFIREWALL_DEFAULT_TO_ACCEPT - а это означает, что, как минимум, такой бридж не может стоять между дхцп-сервером и дхцп-клиентом. Верней, может стоять, но тогда за ним не будет никакого дхцп. И вообще, все, что идет на 1 уровне тцп/ип через такой "бридж" не пролезет. Только через собственной компиляции.
По поводу диверта - еще проще:
> There is no need to compile IPFW into the FreeBSD kernel unless NAT functionality is desiredТ.е. если нужен нат - компилируй ядро, и не иначе. Никакой модуль диверта обойти эту затыку не поможет. Более того, даже если на другом конце диверта будет висеть любой другой демон, скажем, нечто самописное, на лету обрабатывающее пакеты, то и оно работать не будет, пока не будет собрано кастомное ядро с опцией IPDIVERT
Ну, с форвардингом вы уже поняли, да.
>Т.е. если нужен нат - компилируй ядро, и не иначе. Никакой модуль
>диверта обойти эту затыку не поможет.Прошу прощения за назойливость, но раз уж разговор зашёл, всё же хочу уточнить: есть же специальные модули ipfw_nat и ipdivert. Они что, не работают, так как нужно?
>>Т.е. если нужен нат - компилируй ядро, и не иначе. Никакой модуль
>>диверта обойти эту затыку не поможет.
>
>Прошу прощения за назойливость, но раз уж разговор зашёл, всё же хочу
>уточнить: есть же специальные модули ipfw_nat и ipdivert. Они что, не
>работают, так как нужно?"мнение большинства" вообще выглядит обсурдно в свете исконно юниксовских традиций затачивания системы под задачу
для десктопа хватит и женерика
>"мнение большинства" вообще выглядит обсурдно в свете исконно юниксовских традиций >затачивания системы
>под задачу
>для десктопа хватит и женерикаЭто в том смысле, что десктоп и исконно юниксовские традиции - по разные стороны баррикад?
>>"мнение большинства" вообще выглядит обсурдно в свете исконно юниксовских традиций >затачивания системы
>>под задачу
>>для десктопа хватит и женерика
>
>Это в том смысле, что десктоп и исконно юниксовские традиции - по
>разные стороны баррикад?вы мине спрашиваете за десктопы и продакшен сервера?
это две большие разницы!по поводу барикад - не по разные стороны, по разные ветви!
>Т.е. если нужен нат - компилируй ядро, и не иначе. Никакой модуль
>диверта обойти эту затыку не поможет. Более того, даже если на
>другом конце диверта будет висеть любой другой демон, скажем, нечто самописное,
>на лету обрабатывающее пакеты, то и оно работать не будет, пока
>не будет собрано кастомное ядро с опцией IPDIVERT
>
>Ну, с форвардингом вы уже поняли, да.для 8ки - не корректно. подгружаю два модуля ipfw и libalias - и имею ядерный nat без опции ядра divert
>для 8ки - не корректно. подгружаю два модуля ipfw и libalias -
> и имею ядерный nat без опции ядра divertи у меня в 7ке вроде так же, но я что-то постеснялся хвастаться. думаю, запишут в "большинство", разговаривать перестанут.
>для 8ки - не корректно. подгружаю два модуля ipfw и libalias -
> и имею ядерный nat без опции ядра divertПотому что во фре есть более одной реализации ната. Самый старый вариант - юзерленд-нат, работающий отдельным демоном, требует диверта и не иначе. Еще есть нетграф-нода ng-nat. И с не очень давних пор появился кернел-нат в либалиасе.ко. Вот его-то вы и запускаете.
Так что учите матчасть.
>>для 8ки - не корректно. подгружаю два модуля ipfw и libalias -
>> и имею ядерный nat без опции ядра divert
>
>Потому что во фре есть более одной реализации ната. Самый старый вариант
>- юзерленд-нат, работающий отдельным демоном, требует диверта и не иначе. Еще
>есть нетграф-нода ng-nat. И с не очень давних пор появился кернел-нат
>в либалиасе.ко. Вот его-то вы и запускаете.
>
>Так что учите матчасть.спасибо. а то я не знал :)
то есть когда ты забываешь про ядерный нат, это нормально, а когда тебе об этом напоминают, так "учите матчасть"? ну-ну