Re: [d-kernel] Порядок отправки пакетов.

[Evgeny Sinelnikov <sin@altlinux.ru>]

В сообщении от 21 Сентябрь 2004 15:29 Yura Zotov написал(a):
> On Tue, Sep 21, 2004 at 10:44:58AM +0400, Evgeny Sinelnikov wrote:
> > В сообщении от 21 Сентябрь 2004 01:05 Yura Zotov написал(a):
> > > On Mon, Sep 20, 2004 at 11:46:00PM +0400, Evgeny Sinelnikov wrote:
> > > > Здравствуйте.
> > > > Хочу прояснить порядок работы с пакетами относящимися к ядру. Желаю
> > > > выложить ядро kernel-image-rt[26]-{up,smp}. Нужно добавить
> > > > kernel-feat-core-adeos, kernel-modules-rtai и
> > > > kernel-image-rt-[26]-{up,smp} в Kernel CVS, а также
> > > > kernel-source-rtai в Сизиф. С чего начинать?
> > > >
> > > > %description -n kernel-feat-core-adeos
> > > > Adeos nanokernel. Instead of first building the nanokernel and then
> > > > building the client OSes, Adeos started from a live and
> > > >  known-to-be-functional OS, Linux, and inserted a nanokernel beneath
> > > > it. Starting from Adeos, other client OSes can now be put
> > > > side-by-side with the Linux kernel.
> > > >
> > > > %description -n kernel-modules-rtai
> > > > This package contains the RTAI (Real-Time Application Interface)
> > > > system and is intended for developers who are building embedded
> > > > systems that will run the Linux operating system. In fact, RTAI
> > > > is based on the Linux operating system to which it adds real-time
> > > > capabilities that are not natively supported since Linux is a
> > > > user-oriented operating system.
> > >
> > > Ура! Наконец-то оно появится в Сизифе (может лучше в Дедалус для
> > > начала?). Огромное спасибо за работу по подготовке ядра!
> >
> > То есть, можно все просто положить в Deadalus?
> > Хм... Да, тогда Kernel CVS, видимо пока не понадобться, если сборки ядер
> > из cvs идут только Сизиф. А было бы удобно...
>
> Про порядок выкладывания ядер я мало что знаю. Про Дедалус
> сказал, потому что думал так будет лучше, так как это ядро
> может быть нестабильным.
>

Да, я согласен, что нужно тестировать. К сожалению, моих мощностей хватило 
только на тестовую машину для *-up ядер. Как будет себя вести smp даже не 
знаю. Есть вопросы по размещению библиотек, собираемых под каждое ядро, в 
виду тесной связи по включаемым файлам и конкретной конфигурации.
Исходная устанока проводится в каталог /usr/realtime, где аккуратно сложены: 
./bin
./lib
./share
./include
./testsuite
./calibration

Первое, что приходит на ум, это переместить установку в 
каталог /usr/lib/kernel/realtime-%version-%flavor и поручить скриптам 
поправлять ссылку на /usr/realtime. Если нет возражений так и оставлю.
В добавлении ко всему был ещё [./modules], но я его убрал в,
/lib/modules/%kversion-%flavour-%krelease/%module_name
И кстати, чтобы скрипты из ./bin заработали небходим доступ пользователя в 
каталог /lib/modules, поскольку в них используется рекурсивно запускаемый 
sudo insmod, вместо sudo modprobe. Может их лучше оставить там же и ввести 
группу?

> > > Может лучше ядро назвать rtai26, а не rt26? Вроде бы так
> > > понятнее...
> >
> > Я думаю, что rt26 лучше. Дело вот в чем. Изменения ядра минимальны и
> > позволяют использовать не только модули RTAI. По некоторым заявлениям в
> > списках рассылки будущие версии, несколько отставшего, RTLinux для ветки
> > 2.6 предполагаются тоже основывать на ядрах запущенных поверх Adeos.
>
> А! Вот в чём дело. Т.е. на том же самом ядре можно будет
> запустить ещё и rtl? А одновременно rtai и rtl можно? :-)

Если поместить их в разные домены то, может быть что-то и получится, но кто-то 
из них, тогда точно перестанет работать в реальном времени - попадёт в 
виртуальное :)

> В таком случае, может тогда назвать ядро adeos26? Мало ли
> появятся какие-то системы, использующие adeos, но не rt.

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

Sin