[d-kernel] kernel-headers-%flavour, kernel-headers-modules-%flavour

[d-kernel] kernel-headers-%flavour, kernel-headers-modules-%flavour

[Sergey Vlasov]

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

Hello!

Постоянно повторяющиеся в самых разных местах вопли по поводу
несобирающихся модулей VMware мне уже надоели.  Похоже, единственный
способ решить этот вопрос окончательно - это в конце концов поместить
в /usr/src/linux-%kversion-%flavour/include полную копию заголовков
ядра вместо симлинка, что я и собираюсь сделать в очередной сборке
ядер std26.

После этого смысл существования пакетов kernel-headers-%flavour
теряется окончательно: для kernel-headers-modules-%flavour они больше
не нужны, а для использования в userspace - непригодны (и разработчики
ядра не собираются что-либо делать по этому поводу).  Впрочем, можно
сохранить хотя бы видимость существования этих заголовков для
userspace, поставив симлинк и зависимость в обратную сторону.  Правда,
при этом по сравнению с текущей ситуацией у kernel-headers-%flavour
появляется (через kernel-headers-modules-%flavour) лишняя зависимость
на версию gcc, использовавшуюся при компиляции ядра.

У кого-то есть другие предложения?

-- 
Sergey Vlasov

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

Re: [d-kernel] kernel-headers-%flavour, kernel-headers-modules-%flavour

[Dmitry V. Levin]

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

Hi,

On Sun, May 08, 2005 at 11:13:16PM +0400, Sergey Vlasov wrote:
> Постоянно повторяющиеся в самых разных местах вопли по поводу
> несобирающихся модулей VMware мне уже надоели.  Похоже, единственный
> способ решить этот вопрос окончательно - это в конце концов поместить
> в /usr/src/linux-%kversion-%flavour/include полную копию заголовков
> ядра вместо симлинка, что я и собираюсь сделать в очередной сборке
> ядер std26.
> 
> После этого смысл существования пакетов kernel-headers-%flavour
> теряется окончательно: для kernel-headers-modules-%flavour они больше
> не нужны, а для использования в userspace - непригодны (и разработчики
> ядра не собираются что-либо делать по этому поводу).  Впрочем, можно
> сохранить хотя бы видимость существования этих заголовков для
> userspace, поставив симлинк и зависимость в обратную сторону.  Правда,
> при этом по сравнению с текущей ситуацией у kernel-headers-%flavour
> появляется (через kernel-headers-modules-%flavour) лишняя зависимость
> на версию gcc, использовавшуюся при компиляции ядра.
> 
> У кого-то есть другие предложения?

Я вижу в этом решении больше минусов, чем плюсов.

Плюс, я так понимаю, только один - пользователям VMware, которые собирают
модули для неё, можно будет меньше думать во время сборки.

Минус - неоправданное разрастание kernel-image, с которым цивилизованными
методами (без rm -rf) не сможет справиться даже квалифицированный
разработчик.

Что касается kernel-headers-%flavour, которые якобы непригодны для
использования в userspace, то сейчас при всей своей некудышности они
используются для сборки многих пакетов, более тесно связанных с ядром, чем
обычные приложения.  Эту проблему необходимо решать, без этого
окончательный переход на 2.6 невозможен.


-- 
ldv

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

Re: [d-kernel] kernel-headers-%flavour, kernel-headers-modules-%flavour

[Sergey Vlasov]

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

On Mon, May 09, 2005 at 07:08:59PM +0400, Dmitry V. Levin wrote:
> On Sun, May 08, 2005 at 11:13:16PM +0400, Sergey Vlasov wrote:
> > Постоянно повторяющиеся в самых разных местах вопли по поводу
> > несобирающихся модулей VMware мне уже надоели.  Похоже, единственный
> > способ решить этот вопрос окончательно - это в конце концов поместить
> > в /usr/src/linux-%kversion-%flavour/include полную копию заголовков
> > ядра вместо симлинка, что я и собираюсь сделать в очередной сборке
> > ядер std26.
> > 
> > После этого смысл существования пакетов kernel-headers-%flavour
> > теряется окончательно: для kernel-headers-modules-%flavour они больше
> > не нужны, а для использования в userspace - непригодны (и разработчики
> > ядра не собираются что-либо делать по этому поводу).  Впрочем, можно
> > сохранить хотя бы видимость существования этих заголовков для
> > userspace, поставив симлинк и зависимость в обратную сторону.  Правда,
> > при этом по сравнению с текущей ситуацией у kernel-headers-%flavour
> > появляется (через kernel-headers-modules-%flavour) лишняя зависимость
> > на версию gcc, использовавшуюся при компиляции ядра.
> > 
> > У кого-то есть другие предложения?
> 
> Я вижу в этом решении больше минусов, чем плюсов.
> 
> Плюс, я так понимаю, только один - пользователям VMware, которые собирают
> модули для неё, можно будет меньше думать во время сборки.

Там ещё была проблема в том, что скрипты от VMware норовили по
малейшему поводу пытаться пересобрать эти модули снова.

> Минус - неоправданное разрастание kernel-image, с которым цивилизованными
> методами (без rm -rf) не сможет справиться даже квалифицированный
> разработчик.

kernel-image не будет разрастаться от этого в любом случае.

Можно сделать, чтобы ничего не разрасталось - просто переложить эти
файлы в /usr/src, оставив в /usr/include симлинк.  В этом случае
останется только вытягивание пакетами kernel-headers-%flavour
следующего мусора:

8.0K    arch
92K     drivers
245K    scripts
60K     .config
44K     Makefile
196K    Module.symvers
4.0K    gcc_version.inc
649K    total

а также, возможно, лишней версии gcc.

И даже этого можно избежать, если оставить основную массу заголовков
ядра в kernel-headers-%flavour, но держать их не в
/usr/include/linux-%kversion-%flavour, а в
/usr/src/linux-%kversion-%flavour, оставив в /usr/include только
симлинк.

> Что касается kernel-headers-%flavour, которые якобы непригодны для
> использования в userspace, то сейчас при всей своей некудышности они
> используются для сборки многих пакетов, более тесно связанных с ядром, чем
> обычные приложения.  Эту проблему необходимо решать, без этого
> окончательный переход на 2.6 невозможен.

А для этого придётся собирать что-то типа linux-libc-headers.

Хотя мне всё-таки непонятно поведение разработчиков ядра по этому
вопросу - если они утверждают, что не надо лазить в заголовки ядра из
userspace, то почему они не имеют ничего против klibc, где делается
именно это?

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

Re: [d-kernel] kernel-headers-%flavour, kernel-headers-modules-%flavour

[Dmitry V. Levin]

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

On Mon, May 09, 2005 at 09:02:42PM +0400, Sergey Vlasov wrote:
> On Mon, May 09, 2005 at 07:08:59PM +0400, Dmitry V. Levin wrote:
> > On Sun, May 08, 2005 at 11:13:16PM +0400, Sergey Vlasov wrote:
> > > Постоянно повторяющиеся в самых разных местах вопли по поводу
> > > несобирающихся модулей VMware мне уже надоели.  Похоже, единственный
> > > способ решить этот вопрос окончательно - это в конце концов поместить
> > > в /usr/src/linux-%kversion-%flavour/include полную копию заголовков
> > > ядра вместо симлинка, что я и собираюсь сделать в очередной сборке
> > > ядер std26.
> > > 
> > > После этого смысл существования пакетов kernel-headers-%flavour
> > > теряется окончательно: для kernel-headers-modules-%flavour они больше
> > > не нужны, а для использования в userspace - непригодны (и разработчики
> > > ядра не собираются что-либо делать по этому поводу).  Впрочем, можно
> > > сохранить хотя бы видимость существования этих заголовков для
> > > userspace, поставив симлинк и зависимость в обратную сторону.  Правда,
> > > при этом по сравнению с текущей ситуацией у kernel-headers-%flavour
> > > появляется (через kernel-headers-modules-%flavour) лишняя зависимость
> > > на версию gcc, использовавшуюся при компиляции ядра.
> > > 
> > > У кого-то есть другие предложения?
> > 
> > Я вижу в этом решении больше минусов, чем плюсов.
> > 
> > Плюс, я так понимаю, только один - пользователям VMware, которые собирают
> > модули для неё, можно будет меньше думать во время сборки.
> 
> Там ещё была проблема в том, что скрипты от VMware норовили по
> малейшему поводу пытаться пересобрать эти модули снова.

Наверное, я не совсем в курсе, что именно там происходит с VMware?


-- 
ldv

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