[linux] вопрос о ядре
1) так как же правильно ставить ядро? после установки нового будут новые хедеры, а библиотека скомпилина со старыми... что за это будет?Читай readme который идет с ядром. С чего ты взял что библиотека скомпилина со старыми?
Прочти Makefile там се линки есть что откуа подключается.
2) нужно ли хранить потом сорсовое дерево или удалить можно (проблема с линком из /lib/modules - он же нужен зачем-то)после установки ядра сорцы уже не нужны, но советую оставить, если собираешься что-нить разрабытывать - они могут понадобиться.
В наше время должно быть пофиг, так как вменяемый дистрибутив не использует инклуды из /usr/src/linux,
а вместо этого держит их копию в /usr/include/{linux,asm}
Если это не так, то /usr/src/linux лучше не трогать.
> так как же правильно ставить ядро? после установки нового будут новые хедеры, а библиотека скомпилина со старыми... что за это будет?
Будет всё нормально, так как хедеры идут вместе с библиотекой.
Есть небольшое число программ, которые сильно зависят от версии ядра, и их нужно собирать, используя
хедеры от нового ядра - таким программам нужно показать, где лежат правильные хедеры.
> нужно ли хранить потом сорсовое дерево или удалить можно (проблема с линком из /lib/modules - он же нужен зачем-то)
Удалить можно, если не планируется потом собирать программы из вышеупомянутого класса.
К этому классу относятся и отдельно распространяемые модули ядра.
Ссылка в /lib/modules - специально для таких программ.
а вместо этого держит их копию в /usr/include/{linux,asm}
Если это не так, то /usr/src/linux лучше не трогать.
> так как же правильно ставить ядро? после установки нового будут новые хедеры, а библиотека скомпилина со старыми... что за это будет?
Будет всё нормально, так как хедеры идут вместе с библиотекой.
Есть небольшое число программ, которые сильно зависят от версии ядра, и их нужно собирать, используя
хедеры от нового ядра - таким программам нужно показать, где лежат правильные хедеры.
> нужно ли хранить потом сорсовое дерево или удалить можно (проблема с линком из /lib/modules - он же нужен зачем-то)
Удалить можно, если не планируется потом собирать программы из вышеупомянутого класса.
К этому классу относятся и отдельно распространяемые модули ядра.
Ссылка в /lib/modules - специально для таких программ.
если места достаточно, то зачем удалять?
потом можно будет не париться, если понадобится скомпилить какой-нибудь забытый модуль
потом можно будет не париться, если понадобится скомпилить какой-нибудь забытый модуль
Делай в usr/src/linux и не парься, всё будет норм.
спасибо за полный ответ!
как я понимаю, чаще всего этим занимаются братья automake & autoconf, но как это они делают не задумывался
остальным:
спасибо
библиотека скомпилина с другими хедерами, т.к. сам ее компилил, знаю
удалить дерево хочется, чтобы не загромождать систему (150-200 мб все-таки но, возможно, для ядра нужно делать исключение, что и пытаюсь понять
вменяемый дистрибутив не использует инклуды из /usr/src/linux,а как понять, откуда берут хедеры программы при компиляции?!
а вместо этого держит их копию в /usr/include/{linux,asm}
как я понимаю, чаще всего этим занимаются братья automake & autoconf, но как это они делают не задумывался
Будет всё нормально, так как хедеры идут вместе с библиотекой.как их определить? знать? для каждой программы вчитываться в INSTALL?
Есть небольшое число программ, которые сильно зависят от версии ядра.
Удалить можно, если не планируется потом собирать программы из вышеупомянутого класса.интересно... получается, можно докомпилить модули? какие на это ограничения есть (чтобы не вызвать конфликт с ядром)?
К этому классу относятся и отдельно распространяемые модули ядра.
остальным:
спасибо
библиотека скомпилина с другими хедерами, т.к. сам ее компилил, знаю
удалить дерево хочется, чтобы не загромождать систему (150-200 мб все-таки но, возможно, для ядра нужно делать исключение, что и пытаюсь понять
а как понять, откуда берут хедеры программы при компиляции?!Из стандартных путей и с помощью директивы -I
для каждой программы вчитываться в INSTALL?А это
Еще бы.получается, можно докомпилить модули?Можно
какие на это ограничения есть (чтобы не вызвать конфликт с ядром)?Никаких. Разве что объем винта может это дело ограничить.
> а как понять, откуда берут хедеры программы при компиляции?!
По умолчанию из /usr/include , а все дополнительные пути указываются в Makefile и передаются gcc параметрами командной строки.
> как их определить? знать? для каждой программы вчитываться в INSTALL?
Грубо говоря, да, надо читать INSTALL или что там ещё есть.
Обычно это глубоко системные программы, дающие доступ к каким-то особенным фичам ядра.
Ну iptables например - понятно, что с инклудами от ядра версии 2.2 оно не скомпилируется.
> получается, можно докомпилить модули? какие на это ограничения есть (чтобы не вызвать конфликт с ядром)?
Можно. Некоторые драйвера не включены в ядро, и идут отдельно.
Если им чего-то не хватит, получишь ошибку компиляции.
Можно также и докомпилить модули, которые сразу забыл собрать, да.
Ограничения - ну если например забыл включить в ядро поддержку ethernet, то никакой драйвер ethernet-адаптера не соберёшь и т.д.
По умолчанию из /usr/include , а все дополнительные пути указываются в Makefile и передаются gcc параметрами командной строки.
> как их определить? знать? для каждой программы вчитываться в INSTALL?
Грубо говоря, да, надо читать INSTALL или что там ещё есть.
Обычно это глубоко системные программы, дающие доступ к каким-то особенным фичам ядра.
Ну iptables например - понятно, что с инклудами от ядра версии 2.2 оно не скомпилируется.
> получается, можно докомпилить модули? какие на это ограничения есть (чтобы не вызвать конфликт с ядром)?
Можно. Некоторые драйвера не включены в ядро, и идут отдельно.
Если им чего-то не хватит, получишь ошибку компиляции.
Можно также и докомпилить модули, которые сразу забыл собрать, да.
Ограничения - ну если например забыл включить в ядро поддержку ethernet, то никакой драйвер ethernet-адаптера не соберёшь и т.д.
только что нашел раздел в кернел-хавту:
получается, что дерево сорсов вообще не нужно (только для удобства, но экономия!
)
есть ли какие-то причины еше, чтобы оставить дерево сорсов?
3.3. Howto Install Just A Single Module ?извратно, но можно!
получается, что дерево сорсов вообще не нужно (только для удобства, но экономия!
)есть ли какие-то причины еше, чтобы оставить дерево сорсов?
1) Его можно читать на ночь вместо сказки.
По умолчанию из /usr/include
странно, что так вшито... почему бы не сделать было аналог $PATH ?2 ПЖ:
Из стандартных путейэт че такое?
Это и есть /usr/include.
> странно, что так вшито...
ничего странного, вполне в духе традиций
ничего странного, вполне в духе традиций
ну, стандарты же кто-то устанавливает... организации вроде w3c
а про инклюды какой-нибудь FHS диктует?
а про инклюды какой-нибудь FHS диктует?
у меня еще два вопроса появилось по ходу разбирательства:
1) как при многоядровости обеспечить правильное использование System.map (учитывая, что два ядра могут быть даже одного релиза) - в хавту про это есть, но я не понял
2) насколько оправдана стабильность при компиляции с помощью gcc 2.95.3?
дело в том, что у меня видеокарта nvidia с закрытыми дровами
а они их компилят gcc 3, что конфликтует с ядром, скомпилиным gcc 2
1) как при многоядровости обеспечить правильное использование System.map (учитывая, что два ядра могут быть даже одного релиза) - в хавту про это есть, но я не понял
2) насколько оправдана стабильность при компиляции с помощью gcc 2.95.3?
дело в том, что у меня видеокарта nvidia с закрытыми дровами
а они их компилят gcc 3, что конфликтует с ядром, скомпилиным gcc 2
> 1) как при многоядровости обеспечить правильное использование System.map (учитывая, что два ядра могут быть даже одного релиза) - в хавту
> про это есть, но я не понял
При каждой компиляции ядра увеличивается на единицу дополнительный номер сборки, который кладётся в файл .version,
а также показывается командой uname -a
Его нужно дописать к имени System.map: например /boot/System.map-2.6.11-3
> 2) насколько оправдана стабильность при компиляции с помощью gcc 2.95.3?
> дело в том, что у меня видеокарта nvidia с закрытыми дровами
> а они их компилят gcc 3, что конфликтует с ядром, скомпилиным gcc 2
Гораздо больше шансов нарваться на баг в драйвере от nvidia, чем на проблему
из-за неправильной компиляции.
> про это есть, но я не понял
При каждой компиляции ядра увеличивается на единицу дополнительный номер сборки, который кладётся в файл .version,
а также показывается командой uname -a
Его нужно дописать к имени System.map: например /boot/System.map-2.6.11-3
> 2) насколько оправдана стабильность при компиляции с помощью gcc 2.95.3?
> дело в том, что у меня видеокарта nvidia с закрытыми дровами
> а они их компилят gcc 3, что конфликтует с ядром, скомпилиным gcc 2
Гораздо больше шансов нарваться на баг в драйвере от nvidia, чем на проблему
из-за неправильной компиляции.
При каждой компиляции ядра увеличивается на единицу дополнительный номер сборки, который кладётся в файл .versionТы уверен?
А не в Makefile прописываешь перед компиляцией?
да, я тоже читал, что в мейкфайле
подозреваю, что EXTRAVERSION в мейфайле - это для папки модулей, а .version - для System.map
2 : правильное предположение?
подозреваю, что EXTRAVERSION в мейфайле - это для папки модулей, а .version - для System.map
2 : правильное предположение?
version просто добавляется к той версии, которая прописана в мейкфайле
При каждой компиляции ядра увеличивается на единицу дополнительный номер сборки, который кладётся в файл .versionа я сам могу написать туда строку? ну и систем.мап соответственно обозвать?
Для того, чтобы добавлять произвольные строки, есть EXTRAVERSION
я все пытался найти подтверждение твоим словам...
упоминаний о .version не нашел, везде пишут про EXTRAVERSION!
.version используется в корневом Makefile - вставляется в заголовочные файлы
а еще там написано
упоминаний о .version не нашел, везде пишут про EXTRAVERSION!
.version используется в корневом Makefile - вставляется в заголовочные файлы
а еще там написано
KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)так все-таки, нужно называть System.map так:
System.map-$(KERNELRELEASE)-$(POINTVERSION).mapтак
System.map-$(KERNELRELEASE)$(POINTVERSION).mapили так
System.map-$(KERNELRELEASE).map(где $(POINTVERSION) - версия из .version)?
Походу я наврал - не используется .version при поиске System.map
Ну тогда можно, если приспичит, при загрузке определять, что за ядро, и создавать ссылку на правильный System.map
Я обычно просто перезаписываю поверх старого System.map, так что не очень-то он и нужен.
О том, как должен называться System.map, написано например в man ps
Ну тогда можно, если приспичит, при загрузке определять, что за ядро, и создавать ссылку на правильный System.map
Я обычно просто перезаписываю поверх старого System.map, так что не очень-то он и нужен.
О том, как должен называться System.map, написано например в man ps
Есть небольшое число программ, которые сильно зависят от версии ядра, и их нужно собирать, используяОни могут не оказаться в /usr/include/linux ?
хедеры от нового ядра - таким программам нужно показать, где лежат правильные хедеры.
Удалить можно, если не планируется потом собирать программы из вышеупомянутого класса.Правильно ли я понял, что существуют userland программы, которым для сборки нужны исходники ядра? Именно /usr/src/linux, а не /usr/include/linux. Если это так, то это мягко говоря, странновато.
В /usr/include/linux положено лежать тем хедерам, с которыми собиралась glibc, иначе возможны проблемы (хотя обычно их не бывает).
> Правильно ли я понял, что существуют userland программы, которым для сборки нужны исходники ядра? Именно /usr/src/linux, а не /usr/include/linux.
> Если это так, то это мягко говоря, странновато.
Ну это в основном не настоящие программы, а модули ядра, или обёртки вокруг сисколлов.
Но и им должно хватать /usr/src/linux/include/{linux,asm}
> Правильно ли я понял, что существуют userland программы, которым для сборки нужны исходники ядра? Именно /usr/src/linux, а не /usr/include/linux.
> Если это так, то это мягко говоря, странновато.
Ну это в основном не настоящие программы, а модули ядра, или обёртки вокруг сисколлов.
Но и им должно хватать /usr/src/linux/include/{linux,asm}
вот что я нашел в BLFS по iptables:
странновато
и что мне делать, если я поменяю ядро? перекомпиливать iptables?
про man ps:
клево, там действительно то, что надо, написано!
If you are going to patch the kernel, you need to do it before you compile iptables, because during the compilation, the kernel source tree is checked (if it is available at /usr/src/linux-[version] to see which features are available.
странноватои что мне делать, если я поменяю ядро? перекомпиливать iptables?
про man ps:
клево, там действительно то, что надо, написано!
> и что мне делать, если я поменяю ядро? перекомпиливать iptables?
нет, за исключением случаев, если хочешь какой-то новой фичи в netfilter, которая не поддерживается имеющейся версией iptables
нет, за исключением случаев, если хочешь какой-то новой фичи в netfilter, которая не поддерживается имеющейся версией iptables
хорошо
вроде мне понятны стали многие вещи
теперь буду "правильнее" компилить ядра
тебе отдельное спасибо!
спасибо также принимавшим участие!
вроде мне понятны стали многие вещи
теперь буду "правильнее" компилить ядра
тебе отдельное спасибо!
спасибо также принимавшим участие!
Оставить комментарий
a10063
в kernel-howto говорится, что при установке ядра нужно его сорсы распаковать в /usr/src/linux (вернее сделать такой софтлинк на папку с сорсами)а в ридми сорсов нашел вот что:
1) так как же правильно ставить ядро? после установки нового будут новые хедеры, а библиотека скомпилина со старыми... что за это будет?
2) нужно ли хранить потом сорсовое дерево или удалить можно (проблема с линком из /lib/modules - он же нужен зачем-то)
отцы! научите, плиз!
только прошу советы не "по опыту", а "как положено"