* [devel] Re: [d-kernel] Порядок отправки пакетов. @ 2004-09-21 21:14 ` Evgeny Sinelnikov 2004-09-21 21:14 ` Evgeny Sinelnikov 0 siblings, 1 reply; 2+ messages in thread From: Evgeny Sinelnikov @ 2004-09-21 21:14 UTC (permalink / raw) To: devel-kernel; +Cc: ALT Devel discussion list В сообщении от 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 ^ permalink raw reply [flat|nested] 2+ messages in thread
* [devel] Re: [d-kernel] Порядок отправки пакетов. 2004-09-21 21:14 ` [devel] Re: [d-kernel] Порядок отправки пакетов Evgeny Sinelnikov @ 2004-09-21 21:14 ` Evgeny Sinelnikov 0 siblings, 0 replies; 2+ messages in thread From: Evgeny Sinelnikov @ 2004-09-21 21:14 UTC (permalink / raw) To: devel-kernel; +Cc: ALT Devel discussion list В сообщении от 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 _______________________________________________ devel-kernel mailing list devel-kernel@altlinux.ru https://lists.altlinux.ru/mailman/listinfo/devel-kernel ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-09-21 21:14 UTC | newest] Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-09-21 21:14 ` [devel] Re: [d-kernel] Порядок отправки пакетов Evgeny Sinelnikov 2004-09-21 21:14 ` Evgeny Sinelnikov
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git