Оптимальная настройка ядра

menuconfig ничего не ставит! оно только показывает конфиг, который:
1. либо лежит в директории с исходниками ядра (.config)
2. либо конфиг текущего запущеного ядра из /proc/config.gz (вроде так)
3. либо дефолтный конфиг для конкретной архитектуры. обеспечивается параметрами при запуске make

проверить работоспособность ядра без перезагрузки нельзя (пока) (и смотря что считать перезагрузкой... почитайте про kexec)
а вот без переустановки загрузчика можно установить новое ядро можно, для этого достаточно воспользоваться практически любым загрузчиком, кроме lilo :)

что касается того, как оптимально настроить систему, то это выбор каждого(благо в menuconfig, gconfig и xconfig есть справка о каждой опции)... это все равно, что спросить какой дистрибутив лучше :)

Маленькая оговорка на счет оптимальности для ядра: либо работает - либо не работает, т.е. свою будущую работу ВЫ сами планируете и создаете свое ядро (включая или исключая модули\как модули) для своих нужд и потребностей, явно продуманных и не очень!
pS а пересобрать ядро не так уж и долго; сложнее настроить...

Если мне кто-нибудь сможет доказать, что его ядро настроено оптимальнее того, что создаётся гентушным genkernel-ом, сниму шляпу. Разумеется, лишние мегабайты на диске, отсутствие inirramfs-предзагрузки и отсутствие нескольких явно несуществующих в вашей системе модулей -- не в счёт, так как это тривиально делается уже после genkrnel'а. И опять же, тонкий тюнинг некоторых моментов доступен через genkernel --menuconfig, так что вопрос "оптимальной настройки ядра" для меня совсем не праздный. :)

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

Именно для этого и есть genkernel. Если его не использовать, вероятность получить не запускающуюся систему сильно увеличивается ;)

> И что за параметры ставит по дефолту утилита menuconfig

Во, сказанули-то! Это не утилита, во-первых, а параметр для утилиты make. А genkernel -- это скрипт с некими дефолтными пресетами. В любом случае за основу обычно берётся апстримовский набор дефолтных опций (для i386 их два -- 32 и 64 бит). genkernel просто ещё учитывает патчи в поддерживаемых гентушными мейнтейнерами ядрах, которые соответсвенно изменяют набор опций в .config, например, tuxonice-sources. Кроме того, genkernel содержит такие пресеты для всех доступных в дереве portage ядер. Параметры обычно такие. Всё включено, но если можно включить модулем, включается модулем. Исключение -- самые свежие экспериментальные фитчи. Некоторые модули, необходимые для загрузки, genkernel переносит в создаваемый образ initramfs. Собственно его задача как раз -- создать такой образ.

> genkernel вроде проверяет оборудование
Нет, это делает само ядро, а также загрузочные скрипты (через modprobe), в т.ч. размещаемые в iniramfs.

> genkernel вроде создает конфигурационный файл, но какой?
/usr/src/linux/.config и ещё где-то в районе /etc/genkernel/, точно не помню :)

> по моему опять много лишнего там
Да, но оно легко проверяется и убирается! ;)

> В Gentoo для ядра есть какая нибудь песочница?
Ага, qemu называется. Ну, или virtualbox. :)

> можно как-то проверить работоспособность его без переустановки загрузчика?
Можно. Например, qemu -kernel ... [ -initrd ... ] ///тоно не помню, ставьте qemu и см. man, только чтобы поставить qemu или virtualbox, ядро уже должно стоять и работать, сюрьпрайз! :)

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

$ make menuconfig
$ make
$ make install modules_install

Перезапускаешь компьютер, понимаешь что включил не тот модуль, повторяешь процедуру..
Через минут 10-15 друзья задают вполне разумный вопрос: Что ты делаешь?
Ты умно отвечаешь что ты оптимизировал ядро, и от этого у тебя быстро загружается Linux.
А у друзей складывается впечатление что Linux это ОС для задротов :D

Если ты не задрот и хочешь избежать такой ситуации лучше пользоваться genkernel, если хочется чучуть оптимизировать выбери соответствующий тип процессора и отключи не нужные модули для контроллеров hdd

Если ты программируешь для embedded и думаешь как бы сэкономить пару кбайт то тогда лучше почитать справку о каждой опции и думать стоит ли её включать или нет.

возвращаясь в русло топика
вот что предложил genkernel на чистой машинке

[*] Prompt for development and/or incomplete code/drivers
()  Local version - append to kernel release
[ ] Automatically append version information to the version string
    Kernel compression mode (Gzip)  --->
[*] Support for paging of anonymous memory (swap)
[*] System V IPC
[*] POSIX Message Queues
[*] BSD Process Accounting
[*]   BSD Process Accounting version 3 file format
[*] Export task/process statistics through netlink (EXPERIMENTAL)
[*]   Enable per-task delay accounting (EXPERIMENTAL)
[*]   Enable extended accounting over taskstats (EXPERIMENTAL)
[*]     Enable per-task storage I/O accounting (EXPERIMENTAL)
[*] Auditing support
[*]   Enable system-call auditing support
      RCU Subsystem  --->
<> Kernel .config support
   (15) Kernel log buffer size (16 => 64KB, 17 => 128KB)
[ ] Group CPU scheduler
[*] Control Group support  --->
[ ] enable deprecated sysfs features which may confuse old userspace tools
-*- Kernel->user space relay support (formerly relayfs)
-*- Namespaces support
[*]   UTS namespace
[*]   IPC namespace
[*]   User namespace (EXPERIMENTAL)
[*]   PID Namespaces (EXPERIMENTAL)
[ ]   Network namespace
[*] Initial RAM filesystem and RAM disk (initramfs/initrd) support
()    Initramfs source file(s)
[*] Optimize for size
[ ] Configure standard kernel features (for small systems)  --->
    Kernel Performance Events And Counters  --->
*] Disable heap randomization
   Choose SLAB allocator (SLAB)  --->
[*] Profiling support (EXPERIMENTAL)
<M> OProfile system profiling (EXPERIMENTAL)
[ ]OProfile AMD IBS support (EXPERIMENTAL)
[ ]   OProfile multiplexing support (EXPERIMENTAL)
[*] Kprobes
    GCOV-based kernel profiling  --->
[ ] Slow work debugging through debugfs

вот что осталось после /dev/krivo/hand

    Kernel compression mode (Gzip)  --->
[*] Support for paging of anonymous memory (swap)
[*] System V IPC
[*] POSIX Message Queues
[*] BSD Process Accounting
<*> Kernel .config support
[*]   Enable access to .config through /proc/config.gz
    (18) Kernel log buffer size (16 => 64KB, 17 => 128KB)
[*] Control Group support  --->
-*- Kernel->user space relay support (formerly relayfs)
-*- Namespaces support
()    Initramfs source file(s)
[ ] Optimize for size
[*] Disable heap randomization
   Choose SLAB allocator (SLAB)  --->

и то, и то ядра работают
глюков не замечено

где грабли?

Ps
1)Хотелось бы увидеть конструктивные ответы типа "отключение этой xxxxx опции влечет за собой след. негативные последствия"
2)не нужно посылать в гугл или встроенные help - и там, и там были. Читали. Как поняли - так и сделали.
3)Конфигурация ориентирована на end-user-chainik и стабилизированный вариант компа (железки не суются туды\сюды)
4)не нужно отвлекаться на отвлеченные темы

PPs
Еще кандидат на удаление [*] Control Group support - но никак руки не доходят проверить

PPPs
Если опцию в ядро вставляют - значит это кому-то нужно ;)
Зачем использовать, если и без этого работает как часы?
(Закон какого-то там "мерфи" - чем больше комплектующих, тем выше вероятность отказа всей системы)

google://ядерная физика для домохозяйки

Всё до банального просто:
1. make allnoconfig
2. make menuconfig включение того минимала, без которого система не будет работоспособной.
То, что необходимо во время загрузки (например sata контроллер, корневая система) внедряю,
всё остальное, что использую (другие дрова системы, файловые системы, fuse, drm, ip-filter и т.п.) собираю в качестве модулей.
Из «подстроек» только тип процессора, да Sys Rq. Шулдер стандартный устраивает от и до.

То, что творит genkernel мне не нравится ни по объему ненужной мне функциональности, ни, что важно, из-за initrd.

У генкернела есть один большой недостаток. Скрытая логика принятия решения.
К тому же, этот пакет тоже "совершенствуется" -- то есть логика меняется. Любой серьёзный скрипт зависит от кучи параметров. Меняются и параметры, и их местонахождение, и опции. Когда речь идет об установке первоначальной -- в принципе, почти всё равно чем собирать, потому как на iso-образах обычно согласованные между собой пакеты находятся. Когда речь идет о плавно обновляющейся живой системе, чем, по сути Дженту и является, тут уже личный выбор. Только хорошее правило любого админа говорит о том, что нужно точно знать, что именно происходит. В этом случае скрытая логика любых "автоматизирующих" скриптов обязательно сыграет злую шутку. Самое обидное, что привыкнув к "вспомогательным конфигурялкам", человек может долго разбираться с самим конфигом. Потому что нет навыков. (например, не раз приходилось лечить роутеры с помощью ssh+iptables, несмотря на то, что в веб-гуйне всё было пушисто. А правила в цепочках не обнулялись) :) Короче, таких примеров может быть много. Чтобы не ловить щелчки от грабель и пинки от руководства, конфиги надо всё-таки уметь править руками. Может просто не быть времени/возможности доустановить конфигурялку. По разным причинам. А вот когда конфиг диктуя по телефону можешь поправить -- тогда можешь пользоваться чем угодно. Это правило админское. Домашний пользователь может и не грузиться, вплоть до того, что просто позвать друга ))) Но для тех, кому интересно и поковыряться -- админские навыки могут оказаться полезными. Кроме того, они гораздо быстрее расширяют кругозор, так как сталкиваешься с технологиями прямо в ядре, что сразу побуждает разузнать побольше.
Таковы, вкратце, мои резоны. Я не ставлю пакет, если он мне не нужен. В Дженту я с 2004.0, перебрался на неё с Мандрейка, на Мандрейк с шапки, на шапку -- со слаквари. Ядро с версии 2.0.0 на первой своей слаквари. Ядра пересобирались везде, начиная с i386 с 16Мб озу :) Поэтому лично мне лишняя софтина-скриптина никогда не была нужна.
Кроме того, по давней традиции ранних хэндбуков, ядра, помещаемые в бут-раздел винчестера, имеют названия kernel-`uname -r` и конфиг grub'а я, по вполне понятным причинам, всегда правлю руками. Например, если вдруг забыл сделать mount /boot, то vim обругается на недоступность конфига. А "автоматика" отработает по алгоритму, который заложил в неё чужой добрый дядя. Зачем мне такая неопределенность? Будьте проще, и ядра к вам сами потянутся )))