[d-kernel] kernel-headers-modules

[d-kernel] kernel-headers-modules

[vsu]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

Hello!

А почему у нас сейчас заголовки из kernel-headers-modules ставятся в
/usr/src/linux-%version-%flavour, а не в
/usr/include/linux-%version-%flavour?  В результате нет возможности
указать /usr/include/linux-%version-%flavour в качестве каталога с
ядром, если собираемому модулю нужны заголовки SCSI.

У меня ещё возникают мысли втащить в kernel-headers-modules файлы
Makefile, Rules.make и arch/i386/Makefile (слегка их попатчив, чтобы
ничего в дереве ядра не пересобиралось).  Некоторые модули хотят
собираться именно таким образом - не хочется это ломать (при сборке
таким методом получаются наиболее правильные опции gcc).

-- 
Sergey Vlasov

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] kernel-headers-modules

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

On Sun, Oct 05, 2003 at 05:17:06PM +0400, vsu@altlinux.ru wrote:
> А почему у нас сейчас заголовки из kernel-headers-modules ставятся в
> /usr/src/linux-%version-%flavour, а не в
> /usr/include/linux-%version-%flavour?

Скорее всего по ошибке.

> В результате нет возможности
> указать /usr/include/linux-%version-%flavour в качестве каталога с
> ядром, если собираемому модулю нужны заголовки SCSI.

Это не очень сложно исправить?

> У меня ещё возникают мысли втащить в kernel-headers-modules файлы
> Makefile, Rules.make и arch/i386/Makefile (слегка их попатчив, чтобы
> ничего в дереве ядра не пересобиралось).  Некоторые модули хотят
> собираться именно таким образом - не хочется это ломать (при сборке
> таким методом получаются наиболее правильные опции gcc).

Странно, у меня тоже раньше возникали такие мысли...


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] kernel-headers-modules

[vsu]

[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]

On Sun, Oct 05, 2003 at 09:01:20PM +0400, Dmitry V. Levin wrote:
> On Sun, Oct 05, 2003 at 05:17:06PM +0400, vsu@altlinux.ru wrote:
> > А почему у нас сейчас заголовки из kernel-headers-modules ставятся в
> > /usr/src/linux-%version-%flavour, а не в
> > /usr/include/linux-%version-%flavour?
> 
> Скорее всего по ошибке.
> 
> > В результате нет возможности
> > указать /usr/include/linux-%version-%flavour в качестве каталога с
> > ядром, если собираемому модулю нужны заголовки SCSI.
> 
> Это не очень сложно исправить?

Да вроде нет - явный список каталогов в kernel-headers уже есть, так
что остаётся только переместить файлы для kernel-headers-modules, и
поправить все пакеты, которые их используют (пока их немного).

> > У меня ещё возникают мысли втащить в kernel-headers-modules файлы
> > Makefile, Rules.make и arch/i386/Makefile (слегка их попатчив, чтобы
> > ничего в дереве ядра не пересобиралось).  Некоторые модули хотят
> > собираться именно таким образом - не хочется это ломать (при сборке
> > таким методом получаются наиболее правильные опции gcc).
> 
> Странно, у меня тоже раньше возникали такие мысли...

Сейчас попробую...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] kernel-headers-modules

[Ed V. Bartosh]

Hello,

> А почему у нас сейчас заголовки из kernel-headers-modules ставятся в
> /usr/src/linux-%version-%flavour, а не в
> /usr/include/linux-%version-%flavour? 
Нужно поднять тред на эту тему, но, скорее всего, это было сделано для
того, чтобы отделить это от  /usr/include/linux..., которые
используются юзерспейсом. Не по ошибке точно.

> В результате нет возможности
> указать /usr/include/linux-%version-%flavour в качестве каталога с
> ядром, если собираемому модулю нужны заголовки SCSI.
Да, но никто не мешает указать оба места.

> У меня ещё возникают мысли втащить в kernel-headers-modules файлы
> Makefile, Rules.make и arch/i386/Makefile (слегка их попатчив, чтобы
> ничего в дереве ядра не пересобиралось).  Некоторые модули хотят
> собираться именно таким образом - не хочется это ломать (при сборке
> таким методом получаются наиболее правильные опции gcc).
Ну и какие же это include будут ? Вот поэтому и вынесено в том числе.
Я за то, чтобы добавить. Просто пока не нужно было, а в целом я - за.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel-headers-modules

[Ed V. Bartosh]

Hello,

 DVL> On Mon, Oct 06, 2003 at 03:40:19PM +0400, Ed V. Bartosh wrote:
 >> > А почему у нас сейчас заголовки из kernel-headers-modules ставятся в
 >> > /usr/src/linux-%version-%flavour, а не в
 >> > /usr/include/linux-%version-%flavour? 
 >> Нужно поднять тред на эту тему, но, скорее всего, это было сделано для
 >> того, чтобы отделить это от  /usr/include/linux..., которые
 >> используются юзерспейсом. Не по ошибке точно.

 DVL> Странно, ибо заголовки из kernel-headers-modules всё равно не будут
 DVL> найдены в /ust/include/linux/ при любом значении переключателя.
 DVL> Другими словами, на чистый userspace не влияет.
Я тоже так считал, но не помню кто порекомендовал вообще вынести все
это из /usr/include подальше от греха.

 >> > В результате нет возможности
 >> > указать /usr/include/linux-%version-%flavour в качестве каталога с
 >> > ядром, если собираемому модулю нужны заголовки SCSI.
 >> Да, но никто не мешает указать оба места.

 DVL> Это сложнее, ибо местонахождение "текущих" module-specific headers не так
 DVL> просто найти, ибо, в отличие от, скажем, /ust/include/linux, их никто не
 DVL> поддерживает в актуальном состоянии.
А кому они нужны текущие ? Вот ядерные хедеры нужны юзерспейсу, а эти же
сугубо для сборки модулей под конкретное ядро и только.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel-headers-modules

[Ed V. Bartosh]

Hello,

 >> > /usr/include/linux-%version-%flavour? 
 >> Нужно поднять тред на эту тему, но, скорее всего, это было сделано для
 >> того, чтобы отделить это от  /usr/include/linux..., которые
 >> используются юзерспейсом. Не по ошибке точно.

 SV> Они будут отделены, так как юзерспейс полезет исключительно в
 SV> подкаталог include.

 SV> Если убирать - тогда и .config оттуда надо убирать.
А его вообще кто-нибудь там ищет ? Ему самое место в /boot, где он,
собственно говоря, и лежит.

 >> > В результате нет возможности
 >> > указать /usr/include/linux-%version-%flavour в качестве каталога с
 >> > ядром, если собираемому модулю нужны заголовки SCSI.
 >> Да, но никто не мешает указать оба места.

 SV> Речь о том, что некоторые вещи хотят именно каталог ядра, а include/
 SV> и drivers/scsi/ добавляют сами - понятно, что это решается либо
 SV> подстановкой значений для других переменных, либо патчем для
 SV> Makefile, но зачастую это только лишняя работа.
Согласен. Но с другой стороны указывать каталог, лежащий в
/usr/include в качестве SRCDIR - это тоже, кхм, попахивает чем-то
нехорошим :)

 SV> Можно пойти другим путём - сделать в
 SV> /usr/src/linux-%version-%flavour симлинк include ->
 SV> ../../include/linux-%version-%flavour/include; тогда заменителем
 SV> каталога с ядром будет выступать /usr/src/linux-%version-%flavour.
Может так оно и лучше будет. Нужно подумать.

 SV> Здесь проблема ещё в одном месте: при тестовых сборках скриптами в
 SV> CVS переопределяется %_usrsrc, из-за чего либо не находятся
 SV> исходники, либо эти файлы пишутся не туда, куда надо.  Можно это
 SV> обойти, но тогда в спеках придётся писать что-то вроде
 SV> %_includedir/../src/linux-%kversion-%kflavour/drivers/scsi.  А
 SV> ломать этот механизм сборки я не хочу, поскольку hasher пока что не
 SV> умеет работать с ccache.
А это не проблемы hasher-а или твоих скриптов ?

 >> > У меня ещё возникают мысли втащить в kernel-headers-modules файлы
 >> > Makefile, Rules.make и arch/i386/Makefile (слегка их попатчив, чтобы
 >> > ничего в дереве ядра не пересобиралось).  Некоторые модули хотят
 >> > собираться именно таким образом - не хочется это ломать (при сборке
 >> > таким методом получаются наиболее правильные опции gcc).
 >> Ну и какие же это include будут ? Вот поэтому и вынесено в том числе.

 SV> include для make (по крайней мере, Rules.make именно так и
 SV> используется).

 >> Я за то, чтобы добавить. Просто пока не нужно было, а в целом я - за.
 SV> Например, нужно для сборки bttv отдельно от ядра (тогда даже
 SV> Makefile патчить не приходится).
Да, у меня тоже уже примеров поднакопилось :)

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel-headers-modules

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

On Mon, Oct 06, 2003 at 03:40:19PM +0400, Ed V. Bartosh wrote:
> > А почему у нас сейчас заголовки из kernel-headers-modules ставятся в
> > /usr/src/linux-%version-%flavour, а не в
> > /usr/include/linux-%version-%flavour? 
> Нужно поднять тред на эту тему, но, скорее всего, это было сделано для
> того, чтобы отделить это от  /usr/include/linux..., которые
> используются юзерспейсом. Не по ошибке точно.

Странно, ибо заголовки из kernel-headers-modules всё равно не будут
найдены в /ust/include/linux/ при любом значении переключателя.
Другими словами, на чистый userspace не влияет.

> > В результате нет возможности
> > указать /usr/include/linux-%version-%flavour в качестве каталога с
> > ядром, если собираемому модулю нужны заголовки SCSI.
> Да, но никто не мешает указать оба места.

Это сложнее, ибо местонахождение "текущих" module-specific headers не так
просто найти, ибо, в отличие от, скажем, /ust/include/linux, их никто не
поддерживает в актуальном состоянии.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] kernel-headers-modules

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2291 bytes --]

On Mon, Oct 06, 2003 at 03:40:19PM +0400, Ed V. Bartosh wrote:
> Hello,
> 
> > А почему у нас сейчас заголовки из kernel-headers-modules ставятся в
> > /usr/src/linux-%version-%flavour, а не в
> > /usr/include/linux-%version-%flavour? 
> Нужно поднять тред на эту тему, но, скорее всего, это было сделано для
> того, чтобы отделить это от  /usr/include/linux..., которые
> используются юзерспейсом. Не по ошибке точно.

Они будут отделены, так как юзерспейс полезет исключительно в
подкаталог include.

Если убирать - тогда и .config оттуда надо убирать.

> > В результате нет возможности
> > указать /usr/include/linux-%version-%flavour в качестве каталога с
> > ядром, если собираемому модулю нужны заголовки SCSI.
> Да, но никто не мешает указать оба места.

Речь о том, что некоторые вещи хотят именно каталог ядра, а include/
и drivers/scsi/ добавляют сами - понятно, что это решается либо
подстановкой значений для других переменных, либо патчем для
Makefile, но зачастую это только лишняя работа.

Можно пойти другим путём - сделать в
/usr/src/linux-%version-%flavour симлинк include ->
../../include/linux-%version-%flavour/include; тогда заменителем
каталога с ядром будет выступать /usr/src/linux-%version-%flavour.

Здесь проблема ещё в одном месте: при тестовых сборках скриптами в
CVS переопределяется %_usrsrc, из-за чего либо не находятся
исходники, либо эти файлы пишутся не туда, куда надо.  Можно это
обойти, но тогда в спеках придётся писать что-то вроде
%_includedir/../src/linux-%kversion-%kflavour/drivers/scsi.  А
ломать этот механизм сборки я не хочу, поскольку hasher пока что не
умеет работать с ccache.

> > У меня ещё возникают мысли втащить в kernel-headers-modules файлы
> > Makefile, Rules.make и arch/i386/Makefile (слегка их попатчив, чтобы
> > ничего в дереве ядра не пересобиралось).  Некоторые модули хотят
> > собираться именно таким образом - не хочется это ломать (при сборке
> > таким методом получаются наиболее правильные опции gcc).
> Ну и какие же это include будут ? Вот поэтому и вынесено в том числе.

include для make (по крайней мере, Rules.make именно так и
используется).

> Я за то, чтобы добавить. Просто пока не нужно было, а в целом я - за.

Например, нужно для сборки bttv отдельно от ядра (тогда даже
Makefile патчить не приходится).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] kernel-headers-modules

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]

On Mon, Oct 06, 2003 at 04:41:07PM +0400, Ed V. Bartosh wrote:
> Hello,
> 
>  >> > /usr/include/linux-%version-%flavour? 
>  >> Нужно поднять тред на эту тему, но, скорее всего, это было сделано для
>  >> того, чтобы отделить это от  /usr/include/linux..., которые
>  >> используются юзерспейсом. Не по ошибке точно.
> 
>  SV> Они будут отделены, так как юзерспейс полезет исключительно в
>  SV> подкаталог include.
> 
>  SV> Если убирать - тогда и .config оттуда надо убирать.
> А его вообще кто-нибудь там ищет ? Ему самое место в /boot, где он,
> собственно говоря, и лежит.

Практически все модули при сборке.

>  >> > В результате нет возможности
>  >> > указать /usr/include/linux-%version-%flavour в качестве каталога с
>  >> > ядром, если собираемому модулю нужны заголовки SCSI.
>  >> Да, но никто не мешает указать оба места.
> 
>  SV> Речь о том, что некоторые вещи хотят именно каталог ядра, а include/
>  SV> и drivers/scsi/ добавляют сами - понятно, что это решается либо
>  SV> подстановкой значений для других переменных, либо патчем для
>  SV> Makefile, но зачастую это только лишняя работа.
> Согласен. Но с другой стороны указывать каталог, лежащий в
> /usr/include в качестве SRCDIR - это тоже, кхм, попахивает чем-то
> нехорошим :)
> 
>  SV> Можно пойти другим путём - сделать в
>  SV> /usr/src/linux-%version-%flavour симлинк include ->
>  SV> ../../include/linux-%version-%flavour/include; тогда заменителем
>  SV> каталога с ядром будет выступать /usr/src/linux-%version-%flavour.
> Может так оно и лучше будет. Нужно подумать.
> 
>  SV> Здесь проблема ещё в одном месте: при тестовых сборках скриптами в
>  SV> CVS переопределяется %_usrsrc, из-за чего либо не находятся
>  SV> исходники, либо эти файлы пишутся не туда, куда надо.  Можно это
>  SV> обойти, но тогда в спеках придётся писать что-то вроде
>  SV> %_includedir/../src/linux-%kversion-%kflavour/drivers/scsi.  А
>  SV> ломать этот механизм сборки я не хочу, поскольку hasher пока что не
>  SV> умеет работать с ccache.
> А это не проблемы hasher-а или твоих скриптов ?

Да скрипты-то я перепишу (просто придётся в некоторых местах писать
прямо /usr/src вместо макроса %_usrsrc).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] kernel-headers-modules

[Ed V. Bartosh]

Hello,

 >>  SV> Если убирать - тогда и .config оттуда надо убирать.
 >> А его вообще кто-нибудь там ищет ? Ему самое место в /boot, где он,
 >> собственно говоря, и лежит.

 SV> Практически все модули при сборке.
О как ! А зачем им ?
И насчет всех модулей я не согласен в корне.
Им всем нужен linux/config.h, а не .config.
Ты ничего не путаешь ?

 >>  SV> Здесь проблема ещё в одном месте: при тестовых сборках скриптами в
 >>  SV> CVS переопределяется %_usrsrc, из-за чего либо не находятся
 >>  SV> исходники, либо эти файлы пишутся не туда, куда надо.  Можно это
 >>  SV> обойти, но тогда в спеках придётся писать что-то вроде
 >>  SV> %_includedir/../src/linux-%kversion-%kflavour/drivers/scsi.  А
 >>  SV> ломать этот механизм сборки я не хочу, поскольку hasher пока что не
 >>  SV> умеет работать с ccache.
 >> А это не проблемы hasher-а или твоих скриптов ?

 SV> Да скрипты-то я перепишу (просто придётся в некоторых местах писать
 SV> прямо /usr/src вместо макроса %_usrsrc).
Так может лучше тогда в спеках юзать этот %_usrsrc. Или я не понял
чего ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel-headers-modules

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

On Mon, Oct 06, 2003 at 06:51:21PM +0400, Ed V. Bartosh wrote:
> Hello,
> 
>  >>  SV> Если убирать - тогда и .config оттуда надо убирать.
>  >> А его вообще кто-нибудь там ищет ? Ему самое место в /boot, где он,
>  >> собственно говоря, и лежит.
> 
>  SV> Практически все модули при сборке.
> О как ! А зачем им ?
> И насчет всех модулей я не согласен в корне.
> Им всем нужен linux/config.h, а не .config.
> Ты ничего не путаешь ?

Ну ладно, нужен не всем, но встречается.  Некоторым - для grep,
некоторые его в Makefile тащат через include.

>  >>  SV> Здесь проблема ещё в одном месте: при тестовых сборках скриптами в
>  >>  SV> CVS переопределяется %_usrsrc, из-за чего либо не находятся
>  >>  SV> исходники, либо эти файлы пишутся не туда, куда надо.  Можно это
>  >>  SV> обойти, но тогда в спеках придётся писать что-то вроде
>  >>  SV> %_includedir/../src/linux-%kversion-%kflavour/drivers/scsi.  А
>  >>  SV> ломать этот механизм сборки я не хочу, поскольку hasher пока что не
>  >>  SV> умеет работать с ccache.
>  >> А это не проблемы hasher-а или твоих скриптов ?
> 
>  SV> Да скрипты-то я перепишу (просто придётся в некоторых местах писать
>  SV> прямо /usr/src вместо макроса %_usrsrc).
> Так может лучше тогда в спеках юзать этот %_usrsrc. Или я не понял
> чего ?

Посмотри в CVS на buildkernel и buildmodules.  Там пакеты
kernel-{fix,feat,source} ставятся во временный каталог, и сборка
идёт не в chroot, а путём переопределения %_usrsrc и ещё нескольких
макросов.  В результате %_usrsrc надо использовать там, где нужно
работать с файлами из "установленных" пакетов; а вот в %files и
%install нужно будет писать явно /usr/src.

На окончательную сборку в hasher всё это не влияет - только на
промежуточные тестовые сборки.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]