[d-kernel] kernel policy (final?)

[d-kernel] kernel policy (final?)

[Peter Novodvorsky]

Please, review it.

Kernel Policy for Sisyphus.
===========================

Version: 0.99.9

0. Документ и его обновление.
-----------------------------

kernel policy обновляется участниками kernel maintainer committee.
Состав kernel committee:
- Ed V. Bartosh
- Dmitry V. Levin
- Peter A. Novodvorsky


1. Именование
-------------

1.1 Патчи.
----------

Есть два вида патчей:

kernel-feat-%{upsteram_name}
kernel-fix-%{upstream_name}

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

В пакетах feat содержатся патчи добавляющие ядру Linux новые
возможности. Это могут быть и драйверы устройств (рекомендуется
называть такие kernel-feat-drivers-<имя_устройства>) и файловых
систем (желательно называть kernel-feat-fs-<имя_файловой
системы>), добавление новых возможностей к сетевой подсистеме
(желательно называть kernel-feat-net-<сокращённое название
улучшения>), а так же добавление новых возможностей к корневой части
(kernel/*, mm/*, arch/*) ядра, (желательно называть
kernel-feat-core-<название улучшения>). При наименовании патчей
рекомендуется следовать иерархии каталогов в исходных текстах ядра.

Все пакеты fixes поддерживаются kernel maintainer commitee. Именуются
по именам подсистем ядра, а так же существует отдельный пакет для
security патчей и build патчей:
kernel-fixes-{net,drivers,fs,vm,core,security,build}.

Глубина иерархии в названии пакета может варьироваться, некоторые
уровни - пропускаться, чтобы сделать название короче,
например kernel-net-netfilter вместо kernel-net-ipv4-netfilter и
kernel-net-ipv6-netfilter.
 
1.2 Внешние модули.
-------------------

Внешними модулями называются модули, исходные файлы которых, как
правило, поставляются не в виде патчей и которые собираются отдельно
от ядра.

Пакеты с такими собранными модулями должны называться
kernel-modules-<сокращённое название набора модулей>-<версия ядра с
которым собраны модули>-<flavour ядра с которым собраны модули>.

Пакеты с хедерами этих модулей должны назваться
kernel-headers-<сокращённое название набора модулей>-<версия ядра с
которым собраны модули>-<flavour ядра с которым собраны модули>. Такие
пакеты могут и не существовать, они требуются лишь в том случае, когда
хедеры требуются утилит или других модулей.

1.3 Пакеты с исходными текстами модулей.
----------------------------------------

Такие пакеты должны называться: kernel-source-<имя проекта>-<версия
модулей>.

1.4 Пакеты с исходными текстами ядра.
-------------------------------------

Такие пакеты должны называться: kernel-source-<версия ядра без
суффикса (rc*|pre*)>.

1.5 Пакеты с ядром.
------------------

Такие пакеты должен называться kernel-image-<flavour ядра>.

Пакеты с хедерами ядра должны называться kernel-headers-<flavour
ядра>.

1.6 Пакет kernel-build-tools
----------------------------
В этом пакете содержатся rpm определения, макросы, скрипты и другие
вспомогательные средства, которые рекомендуется использовать в spec
файлах kernel- пакетов и в apply скриптах.

2. Versioning пакетов.
----------------------

Пакетам с feat патчами желательно присваивать версии, полученные из
upstream. Если upstream не делает versioning, допустимо называть их по
дате последнего изменения upstream в формате yyyy.mm.dd.

Пакетам с fix патчами обязательно присваивать версии по дате
запаковывания в формате yyyy.mm.dd.

Пакетам с внешними модулями и ядром, а так же с их исходными текстами
модулей желательно присваивать версии, полученные из upstream. Если
upstream не делает versioning, допустимо называть их по дате
последнего изменения upstream в формате yyyy.mm.dd. 

Пакетам с исходными текстами ядра присваиваются версии по следующей
схеме: 
  - если это версия preX, то версия пакета будет 0.0.X.
  - если это версия rcX, то версия пакета будет 0.X.0.
  - если это релиз, то версия пакета будет 1.0.0.

3. Содержимое пакетов.
----------------------

3.1 Патчи.
----------

/usr/src/kernel/patches/<имя_патча>/*            патчи
optional:
         kernel/patches/apply/<имя_патча>        программа, которая
						 прикладывает патчи

Файлы с патчами рекомендуется называть по шаблону "NN_name.patch", где
NN -- номер патча, определяющий порядок его приложения. Если есть
патч, который надо прикладывать только в случае существования других
патчей, то его рекомендуется положить в каталог
/usr/src/kernel/patches/<имя_патча>/NN_<имя приложенного патча>.  

Программа прикладывающая патч, будучи вызванная из каталога с исходными
текстами ядра, обязана приложить к ним нужные патчи или возвратить 1 в
случае ошибки Программа может пользоваться переменной окружения KVER
заданной при запуске в среде, которая содержит версию ядра, к которой
нужно приложить патч. 

При прикладывании патчей, программа может руководствоваться файлами в
подкаталоге исходных текстов ядра patches/ формата
APPLIED_$name. Существование таких файлов означает, что приложены
патчи с именами $name. После прикладывания своих патчей программа
обязана создать свой файл формата APPLIED_$name.

В случае отсутствия программы apply, патчи будут приложены в
соответствии с алгоритмом, описанным в секции 4.

3.2 Пакет с исходными текстами.
--------------------------------

/usr/src/kernel/sources/<имя_пакета>-source-<версия>.tar.gz
....

3.3 Пакет с внешними модулями.
-------------------------------

/lib/modules/<версия ядра>-<flavour>/*
/usr/include/linux-<версия ядра>-<flavour>/include/*
....

3.4 Пакет с ядром.
------------------

image:
/boot/config-<версия ядра>-<flavour>-<release>
/boot/vmlinuz-<версия ядра>-<flavour>-<release>
/boot/System.map-<версия ядра>-<flavour>-<release>
/lib/modules/<версия ядра>-<flavour>-<release>/*

headers:
/usr/include/linux-<версия ядра>-<flavour>/*

....

4. Порядок приложения патчей при сборке по умолчанию
----------------------------------------------------

for i in `ls -1 $1` ; do
    if [ ! -s $1/$i ] ; then continue ; fi
    if [ -f $1/dont_apply_to_${3}_$i ] ; then
	echo "Denied for the kernel version $3 ..."
	continue
    fi
    if [ -d $1/$i ] ; then 
	if [ -f patches/APPLIED_`echo $i | sed -e 's/^.._\\(.*\\)/\\1/'` ] ; then 
	    apply_recursive "$1/$i" 
	fi 
	continue 
    fi 
    echo "Applying patch $i ..." 
    %__cat $1/$i | patch -p1 -b 
done 


5. Порядок принятия новых пакетов в Sisyphus.
---------------------------------------------

Дабы упорядочить вхождение новых пакетов в Sisyphus, сначала
разработчик обязан написать письмо в devel-kernel@altlinux.ru с темой
ITP: <имя_пакета> (Intent to package) и с descriptionом пакета в теле,
чтобы пояснить, что новое он хочет добавить. Далее проходит обсуждение
этого пакета и люди договариваются, целесообразно ли присутствие
пакета в Sisyphus. Kernel maintainer maintainer committee имеет право
наложить вето на вхождение пакета в Sisyphus при согласии всех
участников KMC.


Appendix A: spec для обычного ядра
----------------------------------

# Version options
%define kernel_base_version 2.4.21
%define kernel_extra_version rc1
# Numeric extra version scheme developed by Alexander Bokovoy:
# 0.0.X -- preX
# 0.X.0 -- rcX
# 1.0.0 -- release
%define kernel_extra_version_numeric 0.1.0
%define krelease alt1
%define flavour std-up

# Build options
# You can change compiler by editing and uncommenting this line:
#define kgcc gcc-3.2

# Patches to apply
%add_patch_list kernel-fix-security kernel-fix-build
%add_patch_list kernel-feat-crypto
#add_patch_list kernel-patch-feat-scsi kernel-patch-feat-xfs kernel-patch-feat-splash

## Don't edit below this line ##################################

%define	kversion %{kernel_base_version}%{kernel_extra_version}

%def_enable ccache
%{?__ccache_cc: %define _disable_ccache 1}

%if_enabled ccache
%define kcc "ccache %kgcc"
%else
%define kcc "%kgcc"
%endif



Name: kernel-image-%{flavour}
Version: %{kversion}
Release: %{krelease}

Summary: The Linux kernel (the core of the Linux operating system)
License: GPL
Group: System/Kernel and hardware
Url: http://www.kernel.org/
Packager: Kernel Maintainer Team <kernel@packages.altlinux.org>

Source1: config-%{kversion}-%{flavour}
Source2: rhkmvtag.c
%define rhkmvtag %SOURCE2

ExclusiveOS: Linux

BuildRequires: coreutils libdb4.0-devel perl flex bin86
BuildRequires: rpm >= 4.0.2-75
BuildRequires: kernel-source-%{kernel_base_version} = %{kernel_extra_version_numeric}
BuildRequires: kernel-build-tools
BuildRequires: %get_patch_list
BuildRequires: %(echo %kgcc | sed -e "s/-//")

%if use_ccache
BuildRequires: ccache
%endif

Requires: bootloader-utils >= 0.1-alt7, modutils, mkinitrd >= 1:2.8.6-alt2

Prereq:		coreutils
Prereq:		modutils >= 2.4.17
Obsoletes:	kernel-modules
ExclusiveArch:	%{ix86}


%description
This package contains the Linux kernel that is used to boot and run
your system. It contains few device drivers for specific hardware.
Most hardware is instead supported by modules loaded after booting.
Patches included:%patches

%package -n kernel-headers-%{flavour}
Summary: Header files for the Linux kernel
Group: System/Kernel and hardware

%description -n kernel-headers-%{flavour}
These are the C header files for the Linux kernel, which define
structures and constants that are needed when building most standard
programs under Linux, as well as to rebuild the kernel.
Patches included:%patches

%prep

%__rm -rf kernel-source-%{kernel_base_version}

%__tar -jxvf %{_usrsrc}/kernel/sources/kernel-source-%{kernel_base_version}.tar.bz2

%setup -D -T -n kernel-source-%{kernel_base_version}

echo "patches = %_patch_list"

%apply_patches

%__mv -f Makefile Makefile.orig
%__sed -e 's/EXTRAVERSION =.*/EXTRAVERSION =/g' \
    -e 's/CC.*$(CROSS_COMPILE)gcc/CC		= %{kgcc}/g' \
    Makefile.orig >Makefile


%build

KERNEL_BUILD_DIR=`pwd`


KernelVer=%{kversion}-%{flavour}-%{krelease}

echo "Building Kernel $KernelVer"

:> arch/%{base_arch}/defconfig

%__cat %{SOURCE1} >> arch/%{base_arch}/defconfig

%{__make} mrproper CC=%kcc EXTRAVERSION=%kernel_extra_version-%{flavour}-%{krelease}

%{__make} oldconfig CC=%kcc EXTRAVERSION=%kernel_extra_version-%{flavour}-%{krelease}

### It's a hack, but a useful hack:

cmp -s .config %SOURCE1 || %__cp -vf .config %SOURCE1

%{__make} dep clean CC=%kcc EXTRAVERSION=%kernel_extra_version-%{flavour}-%{krelease}

%{__make} include/linux/version.h CC=%kcc EXTRAVERSION=%kernel_extra_version-%{flavour}-%{krelease}

%{__make} bzImage CC=%kcc EXTRAVERSION=%kernel_extra_version-%{flavour}-%{krelease}

%{__make} modules CC=%kcc EXTRAVERSION=%kernel_extra_version-%{flavour}-%{krelease} YACC="bison -y"

echo "Kernel built $KernelVer"

%install

KernelVer=%{kversion}-%{flavour}-%{krelease}


%__mkdir -p $RPM_BUILD_ROOT/boot
%__install System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
%__cp arch/i386/boot/bzImage $RPM_BUILD_ROOT/boot/vmlinuz-$KernelVer
%__cp .config $RPM_BUILD_ROOT/boot/config-$KernelVer

%{__make} modules_install \
    INSTALL_MOD_PATH=$RPM_BUILD_ROOT \
    KERNELRELEASE=$KernelVer \
    EXTRAVERSION=%kernel_extra_version-%{flavour}-%{krelease}

%__cc -o rhkmvtag %rhkmvtag init/version.o
./rhkmvtag >$RPM_BUILD_ROOT/lib/modules/$KernelVer/.rhkmvtag ||:
%__rm -f rhkmvtag

%__install -d $RPM_BUILD_ROOT%{_prefix}/{include,include/linux-%{version}-%{flavour}/include}

pushd include
%__cp -a . $RPM_BUILD_ROOT/usr/include/linux-%{version}-%{flavour}/include
popd

%__mkdir -p $RPM_BUILD_ROOT/etc/apt/apt.conf.d

echo "
RPM {
    Allow-Duplicated {"^kernel-image-%{flavour}$";};
};
" > $RPM_BUILD_ROOT/etc/apt/apt.conf.d/kernel-image-%{flavour}.conf

%__cp .config $RPM_BUILD_ROOT/usr/include/linux-%{version}-%{flavour}/.config

%post
cd /boot
if [ -x /sbin/installkernel ];then
    /sbin/installkernel -a -c %{kversion}-%{flavour}-%{krelease}
fi


%preun
/sbin/modprobe loop 2> /dev/null > /dev/null

REMOVE=
if [ -f /etc/sysconfig/system ];then
		source /etc/sysconfig/system
		[[ "$CLASS" = "beginner" ]] && REMOVE=yes
fi
if [ -f /etc/sysconfig/installkernel ];then
		source /etc/sysconfig/installkernel
		[[ "$AUTOREMOVE" = [Yy][Ee][Ss] ]] && REMOVE=yes
		[[ "$AUTOREMOVE" = [Nn][Oo] ]] && REMOVE=
fi

BUILD=/lib/modules/%{kversion}-%{flavour}-%{krelease}/build 

[[ -n $REMOVE ]] && /sbin/installkernel -a -R -c %{kversion}-%{flavour}-%{krelease}


%postun
cd /boot
if [ -f initrd-%{kversion}-%{flavour}-%{krelease}.img ];then
		rm -f initrd-%{kversion}-%{flavour}-%{krelease}.img
fi

%files
%defattr(644,root,root,755)
/boot/vmlinuz-%{version}-%{flavour}-%{krelease}
/boot/System.map-%{version}-%{flavour}-%{krelease}
/boot/config-%{version}-%{flavour}-%{krelease}
/lib/modules/%{version}-%{flavour}-%{krelease}
%_sysconfdir/apt/apt.conf.d/kernel-image-%{flavour}.conf
# Exclude drm modules from kernel package

%files -n kernel-headers-%{flavour}
%defattr(644,root,root,755)
%dir %{_prefix}/include/linux-%{version}-%{flavour}
%{_prefix}/include/linux-%{version}-%{flavour}/include/asm
%{_prefix}/include/linux-%{version}-%{flavour}/include/asm-%base_arch
%{_prefix}/include/linux-%{version}-%{flavour}/include/config
%{_prefix}/include/linux-%{version}-%{flavour}/include/linux
%{_prefix}/include/linux-%{version}-%{flavour}/include/math-emu
%{_prefix}/include/linux-%{version}-%{flavour}/include/net
%{_prefix}/include/linux-%{version}-%{flavour}/include/pcmcia
%{_prefix}/include/linux-%{version}-%{flavour}/include/scsi
%{_prefix}/include/linux-%{version}-%{flavour}/include/video
%{_prefix}/include/linux-%{version}-%{flavour}/.config
# Provided by I2C-headers package:
%exclude %{_prefix}/include/linux-%{version}-%{flavour}/include/linux/i2c*

%changelog
* Mon May 12 2003 Peter Novodvorsky <nidd@altlinux.com> kernel-policy-0.99.9
- 0.99.9 policy release.


-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!

Re: [d-kernel] kernel policy (final?)

[aen]

Peter Novodvorsky пишет:

>Please, review it.
>
>Kernel Policy for Sisyphus.
>===========================
>
>Version: 0.99.9
>
>
>  
>
< skip >

>%changelog
>* Mon May 12 2003 Peter Novodvorsky <nidd@altlinux.com> kernel-policy-0.99.9
>- 0.99.9 policy release.
>
Вот эта последняя запись -- полное безобразие. Мне самому diff делать???
Надо запихнуть это в CVS проекта docs.

Если замечаний до завтрашнего утра (~14.00MSK) не поступит, считать 
документ принятым и опубликовать сслыку на него в devel, docs и sisyphus.
Кстати, сейчас есть _постоянный_ URL на самую свежую версию? 2nidd: 
пжста, озаботьтесь.

Rgrds, Алексей

>
>
>  
>

Re: [d-kernel] kernel policy (final?)

[Ed V. Bartosh]

Hello, Peter

>>>>> "PN" == Peter Novodvorsky writes:

 PN>  4. Порядок приложения патчей при сборке по умолчанию
 PN>  ----------------------------------------------------
  
 PN>  for i in `ls -1 $1` ; do
 PN>      if [ ! -s $1/$i ] ; then continue ; fi if [ -f
 PN>      $1/dont_apply_to_${3}_$i ] ; then
 PN>          echo "Denied for the kernel version $3 ..."  continue
 PN>      fi if [ -d $1/$i ] ; then
 PN>          if [ -f patches/APPLIED_`echo $i | sed -e
 PN>          's/^.._\\(.*\\)/\\1/'` ] ; then
 PN>              apply_recursive "$1/$i"
 PN>          fi continue
 PN>      fi echo "Applying patch $i ..."  %__cat $1/$i | patch -p1 -b
 PN>  done
Вот это надо бы обновить из текущего kernel-build-tools, а лучше
сделать здесь ссылку на приложение, в котором привести весь
kernel-macros с рекомендациями к использованию его функционала 
в кернеловых спеках.

 PN>  Appendix A: spec для обычного ядра
 PN>  ----------------------------------
Сюда предлагаю добавить спеки для основных типов ядерных пакетов, могу
прислать десяток-другой на выбор :)
  
И еще надо бы описать какие симлинки ставятся при установке kernel-headers.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy (final?)

[Ed V. Bartosh]

>>>>> "DVL" == Dmitry V. Levin writes:

 >>  И еще надо бы описать какие симлинки ставятся при установке
 >>  kernel-headers.
  
 DVL>  А ещё лучше - реализовать правильное выставление этих ссылок.
 DVL>  Без этого нельзя помещать kernel-headers в Сизиф - сломаются
 DVL>  BTE.

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

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy (final?)

[Dmitry V. Levin]

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

On Tue, May 13, 2003 at 05:28:16PM +0400, Ed V. Bartosh wrote:
> И еще надо бы описать какие симлинки ставятся при установке kernel-headers.

А ещё лучше - реализовать правильное выставление этих ссылок.
Без этого нельзя помещать kernel-headers в Сизиф - сломаются BTE.


--
ldv

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

Re: [d-kernel] kernel policy (final?)

[Dmitry V. Levin]

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

On Tue, May 13, 2003 at 05:50:30PM +0400, Ed V. Bartosh wrote:
>  >>  И еще надо бы описать какие симлинки ставятся при установке
>  >>  kernel-headers.
>   
>  DVL>  А ещё лучше - реализовать правильное выставление этих ссылок.
>  DVL>  Без этого нельзя помещать kernel-headers в Сизиф - сломаются
>  DVL>  BTE.
> 
> Так это же полиси - как опишется, так потом и реализуется.
> Я, например, не знаю как вообще планируется это делать, хотелось бы
> узнать, обсудить.  

Примерно так:

пакет kernel-headers-common:
/usr/include/asm -> /usr/lib/kernel/include/asm
/usr/include/linux -> /usr/lib/kernel/include/linux
%dir /usr/lib/kernel
/usr/lib/kernel/include -> /etc/sysconfig/kernel/include
%dir /etc/sysconfig/kernel (можно и в другой пакет - в какой?)
%ghost /etc/sysconfig/kernel/include -> /usr/include/linux-default/include

Точка переключения, /etc/sysconfig/kernel/include, управляется скриптом,
который должен быть совместим с нынешним gen_kernel_headers, т.е.
поддерживать уже сложившиеся конфигурации.

Никаких /etc/alternatives/.

При наличии /usr/include/linux-default/include следует использовать его,
если все остальные методы не прошли.


--
ldv

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

Re: [d-kernel] kernel policy (final?)

[Alexander Bokovoy]

On Tue, May 13, 2003 at 07:04:50PM +0400, Dmitry V. Levin wrote:
> При наличии /usr/include/linux-default/include следует использовать его,
> если все остальные методы не прошли.
Согласен.

Теперь еще одно предложение для Policy. Касается оно дополнительных
модулей, не входящих в основное ядро. Идея исходит от RedHat и мне она
видится здравой. Я ее немного развил и вот что получилось:

1. Все дополнительные модули, не входящие в основное ядро, размещаются в
linux/drivers/addon/<имя модуля>/

2. Каждый такой модуль содержит дополнительный файл
   linux/drivers/addon/<имя модуля>/Config.in.in с необходимой
   строчкой для linux/drivers/addon/Config.in, например:
   
*** linux/drivers/addon/iscsi-cisco/Config.in.in:
-->8---------------------------------------->8------------------------------------->8------
dep_tristate '   iSCSI support (scsi-over-network), from CISCO' CONFIG_SCSI_ISCSI_CISCO $CONFIG_SCSI m
--8<----------------------------------------8<-------------------------------------8<------  

   Также, каждый модуль имеет свой собственный Makefile. Например, для
   приведенного выше iscsi-cisco он может быть таким:
   
*** linux/drivers/addon/iscsi-cisco/Makefile:
-->8---------------------------------------->8------------------------------------->8------
#
# Makefile for the Cisco iSCSI client
#
# Note! Dependencies are done automagically by 'make dep', which also
# removes any old dependencies. DON'T put your own dependencies here
# unless it's something special (ie not a .c file).
#
# Note 2! The CFLAGS definitions are now in the main makefile...

O_TARGET := iscsi_mod.o

EXTRA_CFLAGS := -I../../scsi -DLINUX

ifeq ($(wildcard $(TOPDIR)/kernel/ksyms.c),$(TOPDIR)/kernel/ksyms.c)
  # check for the presence of certain kernel symbols, and compile accordingly

  SET_USER_NICE:=$(shell grep '^[ \t]*EXPORT_SYMBOL(set_user_nice)' $(TOPDIR)/kernel/ksyms.c 2>/dev/null )
  ifneq ($(SET_USER_NICE),)
     EXTRA_FLAGS += -DHAS_SET_USER_NICE=1
  endif

  REPARENT_TO_INIT:=$(shell grep '^[ \t]*EXPORT_SYMBOL(reparent_to_init)' $(TOPDIR)/kernel/ksyms.c 2>/dev/null )
  ifneq ($(REPARENT_TO_INIT),)
    EXTRA_FLAGS += -DHAS_REPARENT_TO_INIT=1
  endif
endif


obj-y	:= iscsi.o iscsi-probe.o iscsi-login.o iscsiAuthClient.o iscsiAuthClientGlue.o md5.o iscsi-crc.o
obj-m   := $(O_TARGET)

include $(TOPDIR)/Rules.make
--8<----------------------------------------8<-------------------------------------8<------

   Понятное дело, что Makefile у каждого будет такой Makefile различаться,
   важно, что каждый модуль будет собираться по стандартной ядерной схеме.

3. Небольшой скрипт будет проходить по подкаталогам первого уровня в
   linux/drivers/addon/ и генерировать
   linux/drivers/addon/{Config.in,Makefile} следующего содержания:

*** linux/drivers/addon/Config.in:
-->8---------------------------------------->8------------------------------------->8------

#
# device driver configuration for add-on drivers
#
mainmenu_option next_comment
comment 'Additional device driver support'

<СЮДА ВСТАВЛЯЮТСЯ Config.in.in из поддиректорий>

endmenu
--8<----------------------------------------8<-------------------------------------8<------

*** linux/drivers/addon/Makefile:
-->8---------------------------------------->8------------------------------------->8------

# File: drivers/addon/Makefile
#
# Makefile for the device drivers that are not in the main tree but added 
# to the Red Hat linux kernel
#

obj-y           :=
obj-m           :=
obj-n           :=
obj-            :=

mod-subdirs     := <СПИСОК КАТАЛОГОВ>

O_TARGET := addon.o

# All of the (potential) objects that export symbols.
# This list comes from 'grep -l EXPORT_SYMBOL *.[hc]'.

export-objs     :=
list-multi	:=


<СЮДА ВСТАВЛЯЕТСЯ СТРОКИ С ПЕРЕЧИСЛЕНИЕМ КАТАЛОГОВ ВИДА:>
subdir-$(CONFIG_SCSI_ISCSI_CISCO) += iscsi-cisco


include $(TOPDIR)/Rules.make

clean:
	rm -f core *.o *.a *.s *~
--8<----------------------------------------8<-------------------------------------8<------

4.  linux/drivers/addon/Config.in включается в linux/arch/<АРХИТЕКТУРА>/config.in

5.  linux/drivers/addon добавляется в список поддерживаемых в процессе
    сборки целей в linux/drivers/Makefile (subdir-y += addon).

Преимущества схемы:

	- централизованное управление всеми добавками через "Additional
	  device drivers support" в системе конфигурации ядра
	
	- легкость интеграции -- для большинства незатрагивающих другие
	  подсистемы ядра модулей не надо ничего патчить, только приложить
	  два тривиальных Config.in.in и Makefile

	- автоматизация процесса интеграции модулей -- не нужно патчить
	  соответствующие Config.in и Makefile в подсистемах ядра


-- 
/ Alexander Bokovoy
---
I like your game but we have to change the rules.

Re: [d-kernel] kernel policy (final?)

[Alexander Bokovoy]

On Tue, May 13, 2003 at 06:30:04PM +0300, Alexander Bokovoy wrote:
> 5.  linux/drivers/addon добавляется в список поддерживаемых в процессе
>     сборки целей в linux/drivers/Makefile (subdir-y += addon).
Упустил еще одну строчку, на самом деле:
	mod-subdirs += addon
	subdir-y    += addon
	
-- 
/ Alexander Bokovoy
---
As of next Thursday, UNIX will be flushed in favor of TOPS-10.
Please update your programs.

Re: [d-kernel] kernel policy (final?)

[Michael Shigorin]

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

On Tue, May 13, 2003 at 07:04:50PM +0400, Dmitry V. Levin wrote:
> Точка переключения, /etc/sysconfig/kernel/include, управляется скриптом,
> который должен быть совместим с нынешним gen_kernel_headers, т.е.
> поддерживать уже сложившиеся конфигурации.
> 
> Никаких /etc/alternatives/.

А можно поинтересоваться, почему?  В sysconfig вроде как не
"перекидывалки" живут, а plain text configuration files во вполне
общепринятом формате.

Не уверен, что вносить разношерстность будет оправданно.

PS: я понимаю, что "уйти из-под alternatives", но в sysconfig ли?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [d-kernel] kernel policy (final?)

[Dmitry V. Levin]

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

On Tue, May 13, 2003 at 06:58:47PM +0300, Michael Shigorin wrote:
> On Tue, May 13, 2003 at 07:04:50PM +0400, Dmitry V. Levin wrote:
> > Точка переключения, /etc/sysconfig/kernel/include, управляется скриптом,
> > который должен быть совместим с нынешним gen_kernel_headers, т.е.
> > поддерживать уже сложившиеся конфигурации.
> > 
> > Никаких /etc/alternatives/.
> 
> А можно поинтересоваться, почему?

Ибо я не вижу здесь альтернативности.
Наоборот, голая автоматика.

> В sysconfig вроде как не
> "перекидывалки" живут, а plain text configuration files во вполне
> общепринятом формате.

Разве? У меня, например,
$ find /etc/sysconfig/ -mindepth 1 -type d |wc -l
      5


--
ldv

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

Re: [d-kernel] kernel policy (final?)

[Alexander Bokovoy]

On Tue, May 13, 2003 at 08:30:58PM +0400, aen wrote:
> Alexander Bokovoy пишет:
> 
> >On Tue, May 13, 2003 at 07:04:50PM +0400, Dmitry V. Levin wrote:
> > 
> >
> >>При наличии /usr/include/linux-default/include следует использовать его,
> >>если все остальные методы не прошли.
> >>   
> >>
> >Согласен.
> >
> >Теперь еще одно предложение для Policy. Касается оно дополнительных
> >модулей, не входящих в основное ядро. Идея исходит от RedHat и мне она
> >видится здравой. Я ее немного развил и вот что получилось:
> > 
> >
> < skip >
> Кажется, это противоречит уже принятой нами схеме сборки пакетов модулей 
> отдельно от ядра.
> Мне не хотелось бы возвращатсья назад.
Меня не поняли. Существуют модули, которые не включены в основное ядро и
*не могут* быть собраны без преконфигурированных исходников ядра. Таким
место в процессе сборки ядра. Выше речь идет именно о них, в нашей текущей
схеме они просто не учтены.

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

-- 
/ Alexander Bokovoy
---
The UPS is on strike.

Re: [d-kernel] kernel policy (final?)

[Alexander Bokovoy]

On Tue, May 13, 2003 at 06:58:47PM +0300, Michael Shigorin wrote:
> А можно поинтересоваться, почему?  В sysconfig вроде как не
> "перекидывалки" живут, а plain text configuration files во вполне
> общепринятом формате.
> 
> Не уверен, что вносить разношерстность будет оправданно.
> 
> PS: я понимаю, что "уйти из-под alternatives", но в sysconfig ли?
Там живут не только текстовые конфигурационные файлы, но и целые скрипты
(network-scripts, например). Мы обсуждали, куда же их можно положить, и
решили, что %_sysconfdir/sysconfig/kernel -- лучшее место, поскольку там
же можно еще и в будущем дополнительную конфигурационную часть вести.

-- 
/ Alexander Bokovoy
---
The Beatles:
	Paul McCartney's old back-up band.

Re: [d-kernel] kernel policy (final?)

[aen]

Alexander Bokovoy пишет:

>On Tue, May 13, 2003 at 07:04:50PM +0400, Dmitry V. Levin wrote:
>  
>
>>При наличии /usr/include/linux-default/include следует использовать его,
>>если все остальные методы не прошли.
>>    
>>
>Согласен.
>
>Теперь еще одно предложение для Policy. Касается оно дополнительных
>модулей, не входящих в основное ядро. Идея исходит от RedHat и мне она
>видится здравой. Я ее немного развил и вот что получилось:
>  
>
< skip >
Кажется, это противоречит уже принятой нами схеме сборки пакетов модулей 
отдельно от ядра.
Мне не хотелось бы возвращатсья назад.

Rgrds, Алексей

Re: [d-kernel] kernel policy (final?)

[Ed V. Bartosh]

>>>>> "AB" == Alexander Bokovoy writes:

 >>  < skip > Кажется, это противоречит уже принятой нами схеме сборки
 >>  пакетов модулей отдельно от ядра.  Мне не хотелось бы
 >>  возвращатсья назад.
 AB>  Меня не поняли. Существуют модули, которые не включены в
 AB>  основное ядро и *не могут* быть собраны без преконфигурированных
 AB>  исходников ядра. Таким место в процессе сборки ядра. Выше речь
 AB>  идет именно о них, в нашей текущей схеме они просто не учтены.
  
 AB>  Если выносить их совсем, то придется для них собирать пакет с
 AB>  преконфигурированными исходниками ядра, то есть оживлять труп
 AB>  kernel-source, как он был. А вот этого совсем не хотелось бы --
 AB>  абсолютное большинство пользователей проинтерпретирует его
 AB>  появление совершенно неверно, что погубит вообще всю идею
 AB>  нынешней переделки системы сборки ядра.

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

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy (final?)

[Michael Shigorin]

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

On Tue, May 13, 2003 at 08:08:50PM +0400, Dmitry V. Levin wrote:
> Ибо я не вижу здесь альтернативности.
> Наоборот, голая автоматика.

Это понятно.

> > В sysconfig вроде как не
> > "перекидывалки" живут, а plain text configuration files во вполне
> > общепринятом формате.
> Разве? У меня, например,
> $ find /etc/sysconfig/ -mindepth 1 -type d |wc -l

Я вообще-то про "перекидышей" говорил:
trickster:~> find /etc/sysconfig/ -mindepth 1 -type l
/etc/sysconfig/network-scripts/ifdown
/etc/sysconfig/network-scripts/ifup

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [d-kernel] kernel policy (final?)

[Michael Shigorin]

On Tue, May 13, 2003 at 07:12:13PM +0300, Alexander Bokovoy wrote:
> Там живут не только текстовые конфигурационные файлы, но и
> целые скрипты (network-scripts, например). Мы обсуждали, куда
> же их можно положить, и решили, что
> %_sysconfdir/sysconfig/kernel -- лучшее место, поскольку там же
> можно еще и в будущем дополнительную конфигурационную часть
> вести.

А, в таком плане.  Ладно, пас :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [d-kernel] kernel policy (final?)

[Alexander Bokovoy]

On Tue, May 13, 2003 at 08:41:36PM +0400, Ed V. Bartosh wrote:
> 
> >>>>> "AB" == Alexander Bokovoy writes:
> 
>  >>  < skip > Кажется, это противоречит уже принятой нами схеме сборки
>  >>  пакетов модулей отдельно от ядра.  Мне не хотелось бы
>  >>  возвращатсья назад.
>  AB>  Меня не поняли. Существуют модули, которые не включены в
>  AB>  основное ядро и *не могут* быть собраны без преконфигурированных
>  AB>  исходников ядра. Таким место в процессе сборки ядра. Выше речь
>  AB>  идет именно о них, в нашей текущей схеме они просто не учтены.
>   
>  AB>  Если выносить их совсем, то придется для них собирать пакет с
>  AB>  преконфигурированными исходниками ядра, то есть оживлять труп
>  AB>  kernel-source, как он был. А вот этого совсем не хотелось бы --
>  AB>  абсолютное большинство пользователей проинтерпретирует его
>  AB>  появление совершенно неверно, что погубит вообще всю идею
>  AB>  нынешней переделки системы сборки ядра.
> 
> Да, для таких вещей поддерживаю. Только это не модули, а в нашей
> классификации kernel-features. То есть в полиси можно написать, что
> дополнительный функционал, который не затрагивает остальное ядро, и не
> может быть вынесен в модули подлежит оформлению указаным тобой
> методом. И это могут быть не только драйверы, как у Редхата, а что
> угодно. Так ?
Так.
-- 
/ Alexander Bokovoy
---
Beam me up, Scotty!

Re: [d-kernel] adjusting kernel headers

[Dmitry V. Levin]

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

On Tue, May 13, 2003 at 07:04:50PM +0400, Dmitry V. Levin wrote:
> On Tue, May 13, 2003 at 05:50:30PM +0400, Ed V. Bartosh wrote:
> >  >>  И еще надо бы описать какие симлинки ставятся при установке
> >  >>  kernel-headers.
> >   
> >  DVL>  А ещё лучше - реализовать правильное выставление этих ссылок.
> >  DVL>  Без этого нельзя помещать kernel-headers в Сизиф - сломаются
> >  DVL>  BTE.
> > 
> > Так это же полиси - как опишется, так потом и реализуется.
> > Я, например, не знаю как вообще планируется это делать, хотелось бы
> > узнать, обсудить.  
> 
> Примерно так:

Предлагаю несколько модифицированный вариант.

пакет kernel-headers-common:
%_sbindir/adjust_kernel_headers
%_initdir/kheaders
%dir /etc/sysconfig/kernel
/usr/include/asm -> /etc/sysconfig/kernel/include/asm
/usr/include/linux -> /etc/sysconfig/kernel/include/linux
%ghost /etc/sysconfig/kernel/include -> /usr/include/linux-default/include
%dir /usr/lib/kernel
%dir /var/run/kernel
%ghost /var/run/kernel/*

Корректировака kernel headers (путём запуска %_initdir/kheaders) должна
происходить после старта netfs для того, чтобы схема не перестала работать
в случае использования /usr по NFS.

Точка переключения, /etc/sysconfig/kernel/include, управляется скриптом
adjust_kernel_headers, который работает по следующему алгоритму:

+ Определяется полная версия ядра, по умолчанию это $(uname -r)
+ Если существует /usr/include/linux-<версия ядра>-<flavour>/include; то 
	/etc/sysconfig/kernel/include -> /usr/include/linux-<версия ядра>-<flavour>/include
  Иначе если существует /(usr|var)/lib/kernel/<полная версия ядра>; то
  	/etc/sysconfig/kernel/include -> /usr/lib/kernel/include
  	создаются файлы в /var/run/kernel/ (как в нынешнем gen_kernel_headers)
  Иначе если существует /usr/include/linux-default/include; то
  	/etc/sysconfig/kernel/include -> /usr/include/linux-default/include
  Иначе
  	/etc/sysconfig/kernel/include остается неизменным
	и возвращается ошибка.

Преимущества такого управления:
+ на один indirection меньше в случае использования новых kernel headers;
+ не портится ссылка /usr/lib/kernel/include, находящаяся под управлением
update-alternatives, в случае использования старых kernel headers.

Недостаток такого управления:
+ на один indirection больше в случае использования старых kernel headers.

Для совместимости с уже существующими скриптами следует сохранить имя
/etc/rc.d/scripts/gen_kernel_headers, заменив его на обертку к (возможно,
не установленному в системе) %_sbindir/adjust_kernel_headers.


--
ldv

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

Re: [d-kernel] adjusting kernel headers

[Alexander Bokovoy]

On Wed, May 21, 2003 at 03:34:14PM +0400, Dmitry V. Levin wrote:
> Предлагаю несколько модифицированный вариант.
> 
> пакет kernel-headers-common:
> %_sbindir/adjust_kernel_headers
> %_initdir/kheaders
> %dir /etc/sysconfig/kernel
> /usr/include/asm -> /etc/sysconfig/kernel/include/asm
> /usr/include/linux -> /etc/sysconfig/kernel/include/linux
> %ghost /etc/sysconfig/kernel/include -> /usr/include/linux-default/include
> %dir /usr/lib/kernel
> %dir /var/run/kernel
> %ghost /var/run/kernel/*
> 
> Корректировака kernel headers (путём запуска %_initdir/kheaders) должна
> происходить после старта netfs для того, чтобы схема не перестала работать
> в случае использования /usr по NFS.
> 
> Точка переключения, /etc/sysconfig/kernel/include, управляется скриптом
> adjust_kernel_headers, который работает по следующему алгоритму:
> 
> + Определяется полная версия ядра, по умолчанию это $(uname -r)
> + Если существует /usr/include/linux-<версия ядра>-<flavour>/include; то 
> 	/etc/sysconfig/kernel/include -> /usr/include/linux-<версия ядра>-<flavour>/include
>   Иначе если существует /(usr|var)/lib/kernel/<полная версия ядра>; то
>   	/etc/sysconfig/kernel/include -> /usr/lib/kernel/include
>   	создаются файлы в /var/run/kernel/ (как в нынешнем gen_kernel_headers)
>   Иначе если существует /usr/include/linux-default/include; то
>   	/etc/sysconfig/kernel/include -> /usr/include/linux-default/include
>   Иначе
>   	/etc/sysconfig/kernel/include остается неизменным
> 	и возвращается ошибка.
> 
> Преимущества такого управления:
> + на один indirection меньше в случае использования новых kernel headers;
> + не портится ссылка /usr/lib/kernel/include, находящаяся под управлением
> update-alternatives, в случае использования старых kernel headers.
> 
> Недостаток такого управления:
> + на один indirection больше в случае использования старых kernel headers.
> 
> Для совместимости с уже существующими скриптами следует сохранить имя
> /etc/rc.d/scripts/gen_kernel_headers, заменив его на обертку к (возможно,
> не установленному в системе) %_sbindir/adjust_kernel_headers.
Я -- за. Еще мнения?

Давайте по-быстрее завершим разработку политики.

-- 
/ Alexander Bokovoy
---
Goldenstern's Rules:
	(1) Always hire a rich attorney
	(2) Never buy from a rich salesman.

Re: [d-kernel] adjusting kernel headers

[Dmitry V. Levin]

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

On Wed, May 21, 2003 at 03:39:44PM +0300, Alexander Bokovoy wrote:
> On Wed, May 21, 2003 at 03:34:14PM +0400, Dmitry V. Levin wrote:
> > Предлагаю несколько модифицированный вариант.
[...]
> Я -- за. Еще мнения?
> 
> Давайте по-быстрее завершим разработку политики.

Я думаю, что эта часть уже практически реализована.

nidd?


--
ldv

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

Re: [d-kernel] adjusting kernel headers

[Ed V. Bartosh]

>>>>> "DVL" == Dmitry V. Levin writes:

 DVL>  Предлагаю несколько модифицированный вариант.
  
 DVL>  пакет kernel-headers-common: 
 DVL>  %_sbindir/adjust_kernel_headers
 DVL>  %_initdir/kheaders 
 DVL>  %dir /etc/sysconfig/kernel 
 DVL>  /usr/include/asm  -> /etc/sysconfig/kernel/include/asm 
 DVL>  /usr/include/linux -> /etc/sysconfig/kernel/include/linux 
 DVL>  %ghost /etc/sysconfig/kernel/include -> /usr/include/linux-default/include 
 DVL>  %dir /usr/lib/kernel 
 DVL>  %dir /var/run/kernel 
 DVL>  %ghost /var/run/kernel/*

Непонятно что есть linux-default и кто его должен устанавливать и по
каким правилам.

Предлагаю избавиться от /usr/include/linux-<версия ядра>-<flavour>
и использовать для установки хедеров /usr/lib/kernel/<версия ядра>-<flavour>, 
как было в предыдущих ядрах. Зачем ломать схему, которую, возможно,
кто-то использует для сборки ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] adjusting kernel headers

[Ed V. Bartosh]

>>>>> "DVL" == Dmitry V. Levin writes:

 >>  > Предлагаю несколько модифицированный вариант.
 DVL>  [...]
 >>  Я -- за. Еще мнения?
 >>  
 >>  Давайте по-быстрее завершим разработку политики.
  
 DVL>  Я думаю, что эта часть уже практически реализована.
По остальным тоже особых нареканий не было. Если учесть отзывы,
которые были здесь по последней редакции, то есть шанс на этом
закончить эту бадягу.
  
 DVL>  nidd?
Вот именно :)

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] adjusting kernel headers

[Ed V. Bartosh]

>>>>> "PN" == Peter Novodvorsky writes:

 >>  По остальным тоже особых нареканий не было. Если учесть отзывы,
 >>  которые были здесь по последней редакции, то есть шанс на этом
 >>  закончить эту бадягу.
  
 PN>  да
Если 'да', тогда давай полиси :)

Ты там что-нибудь собираешь ? С rc2 поди уже ? Поделился бы с народом,
что ли, а то я тут тоже понасобирал всякого, пока полиси ждал.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] adjusting kernel headers

[Ed V. Bartosh]

>>>>> "PN" == Peter Novodvorsky writes:

 >>  Непонятно что есть linux-default и кто его должен устанавливать и
 >>  по каким правилам.
 >>
 >>  Предлагаю избавиться от /usr/include/linux-<версия
 >>  ядра>-<flavour> и использовать для установки хедеров
 >>  /usr/lib/kernel/<версия ядра>-<flavour>, как было в предыдущих
 >>  ядрах. Зачем ломать схему, которую, возможно, кто-то использует
 >>  для сборки ?
  
 PN>  нет. includes должны лежать в include, и уж никак не
 PN>  /usr/lib. 
 PN>  кроме того уже всё придумали.
Если ты имеешь в виду придумку с расставлением симлинков, то она
никоим образом не противоречит моему предложению.
А насчет должны - это спорно.
Должны быть доступны по /usr/include/linux - так будут.
А для сборки все равно нужно закладываться на конкретные хедеры, и
разницы нет где они будут. Я не пойму чем не устраивает то место, где
они лежат (и используются) сейчас ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] adjusting kernel headers

[Ed V. Bartosh]

>>>>> "PN" == Peter Novodvorsky writes:

 >>  Если 'да', тогда давай полиси :)
 >>
 >>  Ты там что-нибудь собираешь ? С rc2 поди уже ? Поделился бы с
 >>  народом, что ли, а то я тут тоже понасобирал всякого, пока полиси
 >>  ждал.
  
 PN>  ща, скрипт долабаем и пакеты в сизиф выложим, а то раньше
 PN>  нельзя.
  
Дык это, пакеты в Сизиф без полиси нельзя, по-моему. Этот процесс был
приостановлен именно до момента выхода полиси.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] adjusting kernel headers

[Ed V. Bartosh]

>>>>> "PN" == Peter Novodvorsky writes:

 PN>  Мы сейчас с Димой поговорили... поговорили... В общем, я думаю,
 PN>  мы их переместили в /usr/include, чтобы отметить особо, что мы
 PN>  переходим на новую схему. Я думал над причиной в течении минуты,
 PN>  и это единственное похожее на рациональное. 

Хорошая отметина, мимо не пройдешь :)
Я плакалъ :)

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] adjusting kernel headers

[Peter Novodvorsky]

ed@altlinux.ru (Ed V. Bartosh) writes:

>>>>>> "DVL" == Dmitry V. Levin writes:
>
>  >>  > Предлагаю несколько модифицированный вариант.
>  DVL>  [...]
>  >>  Я -- за. Еще мнения?
>  >>  
>  >>  Давайте по-быстрее завершим разработку политики.
>   
>  DVL>  Я думаю, что эта часть уже практически реализована.
> По остальным тоже особых нареканий не было. Если учесть отзывы,
> которые были здесь по последней редакции, то есть шанс на этом
> закончить эту бадягу.

да
>   
>  DVL>  nidd?
> Вот именно :)

да

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!

Re: [d-kernel] adjusting kernel headers

[Peter Novodvorsky]

ed@altlinux.ru (Ed V. Bartosh) writes:

>>>>>> "DVL" == Dmitry V. Levin writes:
>
>  DVL>  Предлагаю несколько модифицированный вариант.
>   
>  DVL>  пакет kernel-headers-common: 
>  DVL>  %_sbindir/adjust_kernel_headers
>  DVL>  %_initdir/kheaders 
>  DVL>  %dir /etc/sysconfig/kernel 
>  DVL>  /usr/include/asm  -> /etc/sysconfig/kernel/include/asm 
>  DVL>  /usr/include/linux -> /etc/sysconfig/kernel/include/linux 
>  DVL>  %ghost /etc/sysconfig/kernel/include -> /usr/include/linux-default/include 
>  DVL>  %dir /usr/lib/kernel 
>  DVL>  %dir /var/run/kernel 
>  DVL>  %ghost /var/run/kernel/*
>
> Непонятно что есть linux-default и кто его должен устанавливать и по
> каким правилам.
>
> Предлагаю избавиться от /usr/include/linux-<версия ядра>-<flavour>
> и использовать для установки хедеров /usr/lib/kernel/<версия ядра>-<flavour>, 
> как было в предыдущих ядрах. Зачем ломать схему, которую, возможно,
> кто-то использует для сборки ?

нет. includes должны лежать в include, и уж никак не /usr/lib. кроме
того уже всё придумали. 

linux-default, это те хедеры, которые идут в glibc-kheaders.

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!

Re: [d-kernel] adjusting kernel headers

[Peter Novodvorsky]

ed@altlinux.ru (Ed V. Bartosh) writes:

>>>>>> "PN" == Peter Novodvorsky writes:
>
>  >>  По остальным тоже особых нареканий не было. Если учесть отзывы,
>  >>  которые были здесь по последней редакции, то есть шанс на этом
>  >>  закончить эту бадягу.
>   
>  PN>  да
> Если 'да', тогда давай полиси :)
>
> Ты там что-нибудь собираешь ? С rc2 поди уже ? Поделился бы с народом,
> что ли, а то я тут тоже понасобирал всякого, пока полиси ждал.

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

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!

Re: [d-kernel] adjusting kernel headers

[Peter Novodvorsky]

ed@altlinux.ru (Ed V. Bartosh) writes:

>>>>>> "PN" == Peter Novodvorsky writes:
>
>  >>  Непонятно что есть linux-default и кто его должен устанавливать и
>  >>  по каким правилам.
>  >>
>  >>  Предлагаю избавиться от /usr/include/linux-<версия
>  >>  ядра>-<flavour> и использовать для установки хедеров
>  >>  /usr/lib/kernel/<версия ядра>-<flavour>, как было в предыдущих
>  >>  ядрах. Зачем ломать схему, которую, возможно, кто-то использует
>  >>  для сборки ?
>   
>  PN>  нет. includes должны лежать в include, и уж никак не
>  PN>  /usr/lib. 
>  PN>  кроме того уже всё придумали.
> Если ты имеешь в виду придумку с расставлением симлинков, то она
> никоим образом не противоречит моему предложению.
> А насчет должны - это спорно.
> Должны быть доступны по /usr/include/linux - так будут.
> А для сборки все равно нужно закладываться на конкретные хедеры, и
> разницы нет где они будут. Я не пойму чем не устраивает то место, где
> они лежат (и используются) сейчас ?

Мы сейчас с Димой поговорили... поговорили... В общем, я думаю, мы их
переместили в /usr/include, чтобы отметить особо, что мы переходим на
новую схему. Я думал над причиной в течении минуты, и это единственное
похожее на рациональное. Я уже собрал пакеты с /usr/include, а так же
это уже прописано в policy.

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!

Re: [d-kernel] adjusting kernel headers

[Michael Shigorin]

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

On Wed, May 21, 2003 at 07:36:28PM +0400, Ed V. Bartosh wrote:
> Хорошая отметина, мимо не пройдешь :)
> Я плакалъ :)

Грабли называется?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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