новая подсистема конфигурации ядра

Я действительно не понимаю, зачем это нужно. Людей, реально нуждающихся в конфигурировании ядра - не очень много. Сегодняшние дистрибутивы покрывают 90% нужд пользователей (или 99%?). Остальные должны обладать некоей квалификацией для выполнения этой работы. И нынешняя система конфигурирования не столь сложна, чтобы испугать человека, отличающего IDE от SCSI, LPT от USB:) Или идея о кухарке, управляющей гос-вом, все никак не может умереть? Службам поддержки очень нравится, наверное, отвечать на вопросы типа "я скомпилил ядро, и у меня система не загружается"...

MUD, которую сделал ESR, была одним из front-end к системе конфигурации CML2, front-end сделанный исключительно для демонстрации ее мощности. 
обычные make config/make menuconfig/make xconfig там тоже были как front-end.
В CML2 включен полный theorem prover (не знаю как лучше перевести - "доказатель" теорем? :) чтобы генерить непротиворечивые конфиги. 

Versus
 

2svu Ты неправ. Текущая система конфигурирования ядра действительно может привести к нерабочему ядру (ну очнь просто). А то что на CML это не даст тебе поломать ядро. Причем как я помню целью было сделать ядро+система конфигурирования+утилитка которая сама обнюхает машину и сконфигурит ядро. IMHO очень хорошая идея.

А что, все "бывалые" играют в MUD ? Странное, на мой взгляд, предположение. "Ощупыватель" железа + генератор config'а - вещи
полезные. А вот qt-конфигуратор - это перебор по-моему. Давайте
тогда сразу сделаем kde-kernel-config, gnome-kernel-config,
foobar-kernel-config etc., и подсистема кофигурации станет толще
всего остального кода :-).

Not found

The node you are looking for does no longer exist or is not accessible without the proper access rights.

где ещё можно почитать?

промахнулся :)

To svu, а это не для конечных юзеров делается, а для девелоперов. Тратить лишнее время им тоже не за чем.

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

Это для девелоперов, говорите? А что - девероперы меняют конфигурацию ядра (целиком!) каждые 5 минут? Мне кажется (поправьте, если вру), они меняют только кусок конфигурации, относящийся к разрабатываемуму в данный момент драйверу. Или я не прав? А вот вводить в ядро зависимость от графических тулкитов - это умно. Типа rpm kernel depends on rpm qt. Вот приятно-то будет! До сего дня make xconfig обходился базовыми иксами...

2 svu:

Тебе уже объяснили, что текущая система конфигурации несовершенна и может приводить к противоречивым результатам.

> вводить в ядро зависимость от графических тулкитов

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

> До сего дня make xconfig обходился базовыми иксами

Бред. Ему нужен tcl/tk.

Вы что, люди! Тут расказывается о CML2, что к нему можно прикрутить любой фронт-энд (не знаю насчет веб-интерфейса :)). Что у него синтаксис очень легкий, структиризированный, логический, и т.д. и т.п. идите лучше пиво пить - а когда ядро выйдет все сами увидите!

>Это для девелоперов, говорите? А что - девероперы меняют конфигурацию ядра (целиком!) каждые 5 минут? Мне кажется (поправьте, если вру), они меняют
>только кусок конфигурации, относящийся к разрабатываемуму в данный момент драйверу. Или я не прав?

Не совсем - есть весьма обширные патчи ... ну например тот же MOSIX
который во-первых лезет в самые интимные места ядра да к тому же
имеет тучу настроек которые при некотором сочетании дают (точнее давали) либо несобирающееся
ядро либо что гораздо опаснее - некий код, который собирается но дает
неустойчивое ядро ... конечно это скорее проблеммы конфигураторов и/или
рук девелоперов :) но таки удобный и надежный инструмент на эту тему
никому не помешает ... а что про GUI/console так это вопрос привычки/ресурсов/религиозных
убеждений - я например большую часть кода пишу в GUI (но не для GUI)
а вот конфигуратор ядра предпочитаю текстово-консольный, что не более чем привычка :)

>anonymous (*) (2002-09-09 10:25:28.104) AFAIR в kde (kcontrol &) есть настройка ядра.

To svu, я предпочитал всегда make menuconfig, запущенный после make oldconfig, но в первый-то раз надо кнофигурить все. Как минимум производителям дистров меньше геморроя. Да и вообще, не забывай, что в мире gnu проги пишутся для себя. Раз кто-то писал это - ему эта прога жизнь упрощала, значит может и еще кому-нибудь помочь. Зачем отказываться?

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

согласен, мне тоже по молодости этого не хватает

Не собирается, говорите? Это-то ясно. Я боюсь только, что однажды соберутся. А то, что текущая система противоречива - может, это отражение противоречий в ядре?

"Вообще" я, наверное, все-таки понимаю. Я просто не понимаю идеи графических фронтендов как таковой. make config и ручная правка конфигов forever!:)

Да, про tcl тут меня поймали:)

не понимаю в чем восторг от конфигурилки на qt, в KDE сто лет как встроена графическая конфигурялка ядра, работает, каши не просит...

я и сам не понимаю, зачем это надо; для проверки непротиворечивости конфигурации ядра есть make dep. IMHO.

A kde-kernel-config uzhe est. Smotri kcontrol (KDE control center)

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

это каким же интеллектом должна обладать сия утилитка чтобы обрабатывать все подряд левые патчи ?

oxonian, make dep только выявляет необходимые связи между файликами. и никак не защищает от некорректного конфигурирования.

2 lb А у утилитки интеллекта и нет. Он есть у человека который для МОЗИКСА сделает на СМЛ2 фалик с описанием. А вот СМЛ2 соберет все файлики с описанием (от МОЗИКСА от ИДЕ от СКАЗИ от СЕТИ и прочее) спросит тебя о предпочтениях (точнее прочтет файлик основанный на опросе) и сделает так что если у тебя есть CD-RW то обязательно запихнет эмуляцию скази (ругнувшись) даже если ты по невежеству заявишь что сказя тебе не нужна.

Вот так.

2 svu CML2 это не ГРАФИЧЕСКАЯ КОНФИГУРЯЛКА !!! это система конфигурации.

Ты видел графических клиентов для CVS ??? Так что теперь CVS - графическая система управления версиями ???? Почитай, это вообще штука не только для ядра линуха, ее можно использовать и для непротиворечивой конфигурации например сквида и для управления своими исходниками.....

Надо только голову приложить.

> make dep только выявляет необходимые связи между файликами

никто не запрещает make dep научить делать еще что-то. я про семантику процесса а не про то, что сейчас в Makefile написано.

Впрочем, кто такой я и кто такой и кто такой Реймонд. ;)

> CML2 это не ГРАФИЧЕСКАЯ КОНФИГУРЯЛКА !!! это система конфигурации.

никто и не говорит о CML2. все говорят именно о нужности этой конкретной Qtшной морды для конфигурирования ядра. Мою шутку про MUD тоже никто не оценил. ;)

Успокойся, знаем мы про CML2. И про то, вместо того, что бы взять полноценный генератор, Реймонд зачем-то изобрел свой.

2oxonian (*) (2002-09-10 10:36:07.487): Таки оно уже вставлено в 2.5?

2oxonian Да я не нервничаю. Если ты знаешь полноценную конфигурялку, кинь ссылочку, будет очень интерестно поглядеть. PS: Про Муд это ничего, вспомни ps в виде DOOM - вот это песня. Теперь админ может хоть в NFS на работе гонять - процессами рулю скажет. :-)

2lb
>это каким же интеллектом должна обладать сия утилитка чтобы обрабатывать все подряд левые патчи ?
Дело не в интелекте а в стандартном инструменти которым можно было б
писать конфиги для левых патчей потому как сейчас это делается по
большей части руками ....