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, где делается
именно это?