Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi, attached is a patch of Xenomai trunk build system to allow building Linux kernel as part of Xenomai build process. This way, typing make install builds and installs the Linux kernel, kernel modules and Xenomai. The patch is a bit young and still has a few drawbacks, but before spending to much time on it, I would like to know if anyone is opposed to the idea of building Linux in Xenomai build tree. To try this patch, apply and run the bootstrap script. 3 options are then added to configure : --enable-linux-buildBuild Linux in Xenomai build tree --with-linux-srcdir specify the path to Linux sources. Default is to use, if not cross-compiling, the source of the running kernel or /usr/src/linux. --enable-linux-build=linux-tree ? The current approach is to use the sources of the running kernel if the only option specified is --enable-linux-build. Do you mean you find this feature superfluous ? -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi, attached is a patch of Xenomai trunk build system to allow building Linux kernel as part of Xenomai build process. This way, typing make install builds and installs the Linux kernel, kernel modules and Xenomai. The patch is a bit young and still has a few drawbacks, but before spending to much time on it, I would like to know if anyone is opposed to the idea of building Linux in Xenomai build tree. To try this patch, apply and run the bootstrap script. 3 options are then added to configure : --enable-linux-buildBuild Linux in Xenomai build tree --with-linux-srcdir specify the path to Linux sources. Default is to use, if not cross-compiling, the source of the running kernel or /usr/src/linux. --enable-linux-build=linux-tree ? The current approach is to use the sources of the running kernel if the only option specified is --enable-linux-build. Do you mean you find this feature superfluous ? If $enableval is y, then no path has been specified, so you can default to the running kernel in such a case. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
The current approach is to use the sources of the running kernel if the
only option specified is --enable-linux-build. Do you mean you find this
feature superfluous ?
If $enableval is y, then no path has been specified, so you can
default to the running kernel in such a case.
Here is a third version of the patch, where :
* the --enable-sim option is removed
* the --with-linux-srcdir option is removed
* the CC variable is passed to kernel build system
* prepare-kernel.sh no longer removes target directories before
creating symbolic links.
This is needed for creating links in a new kernel for the fist time:
--- scripts/prepare-kernel.sh~ 2006-01-08 20:14:05.0 +0100
+++ scripts/prepare-kernel.sh 2006-01-08 20:19:41.0 +0100
@@ -2,11 +2,12 @@
set -e
do_links() {
-( cd $2
+( if test -x $2; then
+ cd $2
find . \( -name Makefile -o -name $config_file -o -name '*.[chS]' \) |
while read f; do
if test ! -e $1/$f; then rm -f $f; fi
- done
+ done; else true; fi
cd $1
find . \( -name Makefile -o -name $config_file -o -name '*.[chS]' \) |
while read f; do
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: The current approach is to use the sources of the running kernel if the only option specified is --enable-linux-build. Do you mean you find this feature superfluous ? If $enableval is y, then no path has been specified, so you can default to the running kernel in such a case. Here is a third version of the patch, where : * the --enable-sim option is removed * the --with-linux-srcdir option is removed * the CC variable is passed to kernel build system * prepare-kernel.sh no longer removes target directories before creating symbolic links. This is needed for creating links in a new kernel for the fist time: Sorry... Here is the 4th patch. Ok, looks like fairly local and non-intrusive. I'm merged this patch into the main trunk eventually, so that it gets more exposure and testing. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Hi, attached is a patch of Xenomai trunk build system to allow building Linux kernel as part of Xenomai build process. This way, typing make install builds and installs the Linux kernel, kernel modules and Xenomai. The patch is a bit young and still has a few drawbacks, but before spending to much time on it, I would like to know if anyone is opposed to the idea of building Linux in Xenomai build tree. To try this patch, apply and run the bootstrap script. 3 options are then added to configure : --enable-linux-buildBuild Linux in Xenomai build tree --with-linux-srcdir specify the path to Linux sources. Default is to use, if not cross-compiling, the source of the running kernel or /usr/src/linux. --enable-linux-build=linux-tree ? --with-adeos-patch specify the path to the Adeos patch. Default is to infer the patch name from Linux kernel version. When using the --enable-linux-build option, configure creates a linux tree in Xenomai build tree, and run the prepare-kernel.sh script for this tree. Typing make re-runs prepare-kernel.sh (in case some changes occured in Xenomai sources) and run make in the kernel tree. Known limitations are: - it is not very well tested, so, maybe some error cases are not handled correctly ; - it is not tested with Linux 2.4 ; - for an unknown reason, xenomai modules are built every time prepare-kernel.sh is run ; - the cross-compilation prefix is inferred from the CC variable, it should work in most situations, but not all. Happy new year. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe.
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi, attached is a patch of Xenomai trunk build system to allow building Linux kernel as part of Xenomai build process. This way, typing make install builds and installs the Linux kernel, kernel modules and Xenomai. The patch is a bit young and still has a few drawbacks, but before spending to much time on it, I would like to know if anyone is opposed to the idea of building Linux in Xenomai build tree. To try this patch, apply and run the bootstrap script. 3 options are then added to configure : --enable-linux-buildBuild Linux in Xenomai build tree --with-linux-srcdir specify the path to Linux sources. Default is to use, if not cross-compiling, the source of the running kernel or /usr/src/linux. --enable-linux-build=linux-tree ? The current approach is to use the sources of the running kernel if the only option specified is --enable-linux-build. Do you mean you find this feature superfluous ? -- Gilles Chanteperdrix.
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi, attached is a patch of Xenomai trunk build system to allow building Linux kernel as part of Xenomai build process. This way, typing make install builds and installs the Linux kernel, kernel modules and Xenomai. The patch is a bit young and still has a few drawbacks, but before spending to much time on it, I would like to know if anyone is opposed to the idea of building Linux in Xenomai build tree. To try this patch, apply and run the bootstrap script. 3 options are then added to configure : --enable-linux-buildBuild Linux in Xenomai build tree --with-linux-srcdir specify the path to Linux sources. Default is to use, if not cross-compiling, the source of the running kernel or /usr/src/linux. --enable-linux-build=linux-tree ? The current approach is to use the sources of the running kernel if the only option specified is --enable-linux-build. Do you mean you find this feature superfluous ? If $enableval is y, then no path has been specified, so you can default to the running kernel in such a case. -- Philippe.
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Philippe Gerum wrote: Gilles Chanteperdrix wrote: The current approach is to use the sources of the running kernel if the only option specified is --enable-linux-build. Do you mean you find this feature superfluous ? If $enableval is y, then no path has been specified, so you can default to the running kernel in such a case. Here is a third version of the patch, where : * the --enable-sim option is removed * the --with-linux-srcdir option is removed * the CC variable is passed to kernel build system * prepare-kernel.sh no longer removes target directories before creating symbolic links. -- Gilles Chanteperdrix. xeno-build-kernel.3.diff Description: Binary data
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
The current approach is to use the sources of the running kernel if the
only option specified is --enable-linux-build. Do you mean you find this
feature superfluous ?
If $enableval is y, then no path has been specified, so you can
default to the running kernel in such a case.
Here is a third version of the patch, where :
* the --enable-sim option is removed
* the --with-linux-srcdir option is removed
* the CC variable is passed to kernel build system
* prepare-kernel.sh no longer removes target directories before
creating symbolic links.
This is needed for creating links in a new kernel for the fist time:
--- scripts/prepare-kernel.sh~ 2006-01-08 20:14:05.0 +0100
+++ scripts/prepare-kernel.sh 2006-01-08 20:19:41.0 +0100
@@ -2,11 +2,12 @@
set -e
do_links() {
-( cd $2
+( if test -x $2; then
+ cd $2
find . \( -name Makefile -o -name $config_file -o -name '*.[chS]' \) |
while read f; do
if test ! -e $1/$f; then rm -f $f; fi
- done
+ done; else true; fi
cd $1
find . \( -name Makefile -o -name $config_file -o -name '*.[chS]' \) |
while read f; do
--
Philippe.
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: The current approach is to use the sources of the running kernel if the only option specified is --enable-linux-build. Do you mean you find this feature superfluous ? If $enableval is y, then no path has been specified, so you can default to the running kernel in such a case. Here is a third version of the patch, where : * the --enable-sim option is removed * the --with-linux-srcdir option is removed * the CC variable is passed to kernel build system * prepare-kernel.sh no longer removes target directories before creating symbolic links. This is needed for creating links in a new kernel for the fist time: Sorry... Here is the 4th patch. Ok, looks like fairly local and non-intrusive. I'm merged this patch into the main trunk eventually, so that it gets more exposure and testing. -- Philippe.
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Known limitations are: (...) - for an unknown reason, xenomai modules are built every time prepare-kernel.sh is run ; The reason for this limitation is that prepare-kernel.sh remove directories before re-creating them and before creating symbolic links. The previous patch was also incorrect when trying to cross-compile the Linux kernel or building it for ppc. The attached patch fixes these issues. -- Gilles Chanteperdrix. xeno-build-kernel.diff Description: Binary data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Jan Kiszka wrote: The previous patch was also incorrect when trying to cross-compile the Linux kernel or building it for ppc. The attached patch fixes these issues. Regarding your general idea, I'm just trying to imagine the new build process: you prepare and build the kernel + the userspace stuff again in one step?. But you still have to configure both parts separately. The question for me is now if this simplifies the situation expecially for beginners. So far, the separation was clearly visible, now it /may/ become blurred (but I'm not a beginner...). Can you provide a rough comparision of the workflows? Sorry, but I'm too lazy, I mean busy to give it a try. configure --enable-linux-build make xconfig make install If you already have a .config file, the make xconfig step becomes optional. Note that the --enable-linux-build flag is optional too. The simplification is mainly for developping xenomai itself, not for its users. Because with the current scheme, after some modifications, you have to recompile and reinstall both the kernel-space modules and user-space libraries. If you let configure select the proper adeos patch, you are warned when the adeos patch changed in the source directory (after an svn update, for example), and just have to type: rm linux/.xenomai-prepared (Ok, this step is a bit awkward, we may find something better) make install And a new kernel will be built and installed, using the new adeos patch and the same .config. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Jan Kiszka wrote: The previous patch was also incorrect when trying to cross-compile the Linux kernel or building it for ppc. The attached patch fixes these issues. Regarding your general idea, I'm just trying to imagine the new build process: you prepare and build the kernel + the userspace stuff again in one step?. But you still have to configure both parts separately. The question for me is now if this simplifies the situation expecially for beginners. So far, the separation was clearly visible, now it /may/ become blurred (but I'm not a beginner...). Can you provide a rough comparision of the workflows? Sorry, but I'm too lazy, I mean busy to give it a try. configure --enable-linux-build make xconfig make install I'm starting to like this! If you already have a .config file, the make xconfig step becomes optional. Note that the --enable-linux-build flag is optional too. The simplification is mainly for developping xenomai itself, not for its users. Because with the current scheme, after some modifications, you have to recompile and reinstall both the kernel-space modules and user-space libraries. If you let configure select the proper adeos patch, you are warned when the adeos patch changed in the source directory (after an svn update, for example), and just have to type: rm linux/.xenomai-prepared (Ok, this step is a bit awkward, we may find something better) make install And a new kernel will be built and installed, using the new adeos patch and the same .config. Hmm, what about this: Instead of leaving some (probably empty) xenomai-prepared in the kernel tree, better create an xenomai-uninstall script in the same place. It a) can serve as an indication for a prepared kernel and b) can be used to upgrade that tree by first running it and then applying the usual steps on the kernel again. I often forget to save my old adeos patch before updating the xenomai tree, thus I will then have to download the old patch again, reverse-apply it, and can finally run the prepare script for the update. Automating this would be REALLY, REALLY GREAT! Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Known limitations are: (...) - for an unknown reason, xenomai modules are built every time prepare-kernel.sh is run ; The reason for this limitation is that prepare-kernel.sh remove directories before re-creating them and before creating symbolic links. The previous patch was also incorrect when trying to cross-compile the Linux kernel or building it for ppc. The attached patch fixes these issues. -- Gilles Chanteperdrix. xeno-build-kernel.diff Description: Binary data
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Jan Kiszka wrote: The previous patch was also incorrect when trying to cross-compile the Linux kernel or building it for ppc. The attached patch fixes these issues. Regarding your general idea, I'm just trying to imagine the new build process: you prepare and build the kernel + the userspace stuff again in one step?. But you still have to configure both parts separately. The question for me is now if this simplifies the situation expecially for beginners. So far, the separation was clearly visible, now it /may/ become blurred (but I'm not a beginner...). Can you provide a rough comparision of the workflows? Sorry, but I'm too lazy, I mean busy to give it a try. configure --enable-linux-build make xconfig make install I'm starting to like this! If you already have a .config file, the make xconfig step becomes optional. Note that the --enable-linux-build flag is optional too. The simplification is mainly for developping xenomai itself, not for its users. Because with the current scheme, after some modifications, you have to recompile and reinstall both the kernel-space modules and user-space libraries. If you let configure select the proper adeos patch, you are warned when the adeos patch changed in the source directory (after an svn update, for example), and just have to type: rm linux/.xenomai-prepared (Ok, this step is a bit awkward, we may find something better) make install And a new kernel will be built and installed, using the new adeos patch and the same .config. Hmm, what about this: Instead of leaving some (probably empty) xenomai-prepared in the kernel tree, better create an xenomai-uninstall script in the same place. It a) can serve as an indication for a prepared kernel and b) can be used to upgrade that tree by first running it and then applying the usual steps on the kernel again. I often forget to save my old adeos patch before updating the xenomai tree, thus I will then have to download the old patch again, reverse-apply it, and can finally run the prepare script for the update. Automating this would be REALLY, REALLY GREAT! Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Jan Kiszka wrote: If you let configure select the proper adeos patch, you are warned when the adeos patch changed in the source directory (after an svn update, for example), and just have to type: rm linux/.xenomai-prepared (Ok, this step is a bit awkward, we may find something better) make install And a new kernel will be built and installed, using the new adeos patch and the same .config. Hmm, what about this: Instead of leaving some (probably empty) xenomai-prepared in the kernel tree, better create an xenomai-uninstall script in the same place. It a) can serve as an indication for a prepared kernel and b) can be used to upgrade that tree by first running it and then applying the usual steps on the kernel again. I often forget to save my old adeos patch before updating the xenomai tree, thus I will then have to download the old patch again, reverse-apply it, and can finally run the prepare script for the update. Automating this would be REALLY, REALLY GREAT! The current approach try and achieve a similar goal by first copying (it is not a real copy, only symbolic links to the source tree, a bit like lndir would do) an unpatched kernel in Xenomai build tree, and preparing it there. This way, when compilation with a new patch is needed, there is no need to unprepare the kernel, only erase, copy again and prepare the fresh copy, using the new patch. And that is what the current patch automates. unpreparing seems harder. -- Gilles Chanteperdrix.
