Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Romain Lenglet wrote: > > if you see an error, please provide a proper patch. > > Here is a patch that includes the correction of xeno-config.in > and the manpage. If someone wants to add it to the patch tracker > on the Gna! project page, please do it. You are supposed to be able to ad that patch to the tracker: being a logged-in user should be enough to be able to post a patch. I do not think it wise to open it to anonymous users, it would open it for use by spammers. > I am currently working on manpages for xeno-load(1) and > runinfo(5) (for the format of .runinfo files). I will send a > patch with these. Thanks. Note that you will need to document the latency test. This looks important, because this is the first program users should run, before messing with .runinfo. In order to compare Xenomai with other Debian packagees, I checked gtk-config, and I have a few remarks on xeno-config and its manpage. gtk-config is made to be sourced from configure scripts, so that configure scripts have a simple way to know whether GTK is installed, and a simple way to get the glib_* variables and export them to the generated makefiles. When run with no arguments, xeno-config prints the usage, but most importantly returns an error. I would suggest firstly that we do not print anything, after all the standard way to get help is the --help or -h argument, but if you do insist that you want help, I admit configure script may redirect output when sourcing xeno-config. But I strongly suggest we return 0, otherwise, there is no simple way for a configure script to know whether Xenomai is correctly installed. gtk-config has no --verbose option and I wonder how useful this option is. I mean, if you want to have the variables list, you may run (modulo we do not return 1 as status when called with no arguments) . xeno-config set | grep '^XENO' Now, about the manpage itself, unless I am wrong, the DESTDIR feature is not documented, it is very useful when compiling for a target. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Testing the adeos-ipipe-2.6.13-ppc-1.0-00.patch
Fillod Stephane wrote: Hi Philippe, Sorry for the late report, Xenomai appears to work fine on a Freescale e500 board (MPC8541E) under Linux 2.6.13. Xenomai version was v1.9.9, ie. the daily snapshot as of today. Here are some preliminary figures (CPU 800MHz, Bus 133MHz, 32 kiB I-Cache 32 kiB D-Cache, 256 kiB L2): switch $ ./run == Sampling period: 100 us RTH| lat min| lat avg| lat max|lost RTD|3660|3690|8070| 0 kaltency $ ./run RTH|klat min|klat avg|klat max| overrun| RTS| -7350| -5715|6420| 0| 00:03:17/00:03:17 latency $ ./run == Sampling period: 100 us RTT| 00:08:04 RTH|-lat min|-lat avg|-lat max|-overrun| RTS| -6930| -4260|8700| 0| 00:08:06/00:08:06 Great you tested that, thanks. The calibration looks a bit pessimistic, so I guess that a narrowed one would leave us with something in the 10-12 us range worst-case in user-space, which would still be quite decent. Load for klatency/latency was ping flooding on FCC (piece of cake), and cache calibrator. IMHO, we can do nastier. Mixed LTP stuff and dd loops are quite good punishers AFAICS here. -- Philippe.
Re: [Xenomai-core] [bug-reminder] user/kernel space header deps
Gilles Chanteperdrix wrote: Jan Kiszka wrote: > Hi, > > just to avoid that this issue got lost during the migration to Xenomai: Before it get lost again, maybe you would like to use our brand-new bug tracker ? https://gna.org/bugs/?func=additem&group=xenomai Please add the kernel module compilation flags issue you once raised too. This one will be solved when the build system is fully refactored though. -- Philippe.
Re: [Xenomai-core] [bug-reminder] user/kernel space header deps
Jan Kiszka wrote: > Hi, > > just to avoid that this issue got lost during the migration to Xenomai: Before it get lost again, maybe you would like to use our brand-new bug tracker ? https://gna.org/bugs/?func=additem&group=xenomai -- Gilles Chanteperdrix.
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Romain Lenglet wrote: > > if you see an error, please provide a proper patch. > > Here is a patch that includes the correction of xeno-config.in > and the manpage. If someone wants to add it to the patch tracker > on the Gna! project page, please do it. > > > I cannot see the error youve 'corrected' below.. > > You will see in the patch. ;) > The usage mentionned --module-cxxflags and --kernel-cxxflags that > are not allowed, and the actual set of accepted options is > larger than previously displayed in the usage. > > > In fact, youve added one; -v doesnt work, --v does. > > Thanks, corrected in this patch. Thanks a lot, will apply. I would move the man directory under the doc directory though. > If someone applies the patch to the repository, it will be > necessary to run autoreconf once (to regenerate configure and > man/GNUmakefile.in). It does not work on my system, apparently > because my versions of automake and autoconf are too recent, and > some rule files seem to not be included in the repository. The necessary versions of the autotools are the one in Debian Sarge, and their version is given in README.INSTALL: o autoconf 2.59 o automake 1.9.5 o aclocal 1.9.5 o libtool 1.5.6 If you want to regenerate the autotools files, you may enable the "maintainer mode" in Xenomai configuration or run script/bootstrap (you have to run it under the sim directory too). autoreconf does not work because it greps the flags to be passed to aclocal by looking for the ACLOCAL_AMFLAGS variable definition in the top Makefile, but there is no top Makefile in Xenomai, only a top GNUmakefile. I tracked down this issue and changed my autoreconf script a long time ago but am using the bootstrap script now... Automake maintainer mode, on the other hand, works fine with makefiles called GNUmakefile. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Packaging issues and licensing issues
[EMAIL PROTECTED] wrote: > On Sunday 16 October 2005 08:50, Gilles Chanteperdrix wrote: > > Ah, thanks ! The mailing list is the best place for yous wishes, since > > it may start a discussion, and we may even found a volunteer for doing > > the debian package. > > Using the debian/rules I did a few weeks ago as a basis for further work, I > can work with Romain to develop it further. Not sure that having separate > packages for each skin is a good idea, but certainly m-a is worth persuing. > > Somewhere along the way, it would be wise (in my opinion) to appoint a > package > manager with write permissions to svn/cvs and file areas - This would > relieve > the core team of the burden of repository maintenance. That is true. Would you volunteer ? Or maybe Romain, since he seem to have undertaken some part of the remaining work ? -- Gilles Chanteperdrix.
Re: [Xenomai-core] Packaging issues - part 3
Romain Lenglet wrote: > > This looks like separated issues: fixes of the debian > > directory may go in the Xenomai svn repository, and cause a > > debian package update without a new upstream release. But > > there are maybe other issues ? > > Alright, but we should be able to make changes in both the > Xenomai code and the Debian files, independently. > If a package has been released, then if we want to release a new > revision of the package that corrects Debian-only issues, then > we must be able to ignore any modification in the repository > that do not concern the Debian files, to create the new package. > > We can do that with either separate repositories, or branches in > svn. Handling a separate branch mean seems a lot of maintenance, whereas updates of the debian packaging system would go in the debian directory (I mean, except manapges ;-), and work on the trunk would never change the debian directory. Maybe a lighter solution would be to maintain the debian directory at another place in the repository, for example in packages/debian, and to make it appear in trunk using the subversion svn:external attribute. This way the debian directory would appear in all the releases of xenomai. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
> if you see an error, please provide a proper patch. Here is a patch that includes the correction of xeno-config.in and the manpage. If someone wants to add it to the patch tracker on the Gna! project page, please do it. > I cannot see the error youve 'corrected' below.. You will see in the patch. ;) The usage mentionned --module-cxxflags and --kernel-cxxflags that are not allowed, and the actual set of accepted options is larger than previously displayed in the usage. > In fact, youve added one; -v doesnt work, --v does. Thanks, corrected in this patch. If someone applies the patch to the repository, it will be necessary to run autoreconf once (to regenerate configure and man/GNUmakefile.in). It does not work on my system, apparently because my versions of automake and autoconf are too recent, and some rule files seem to not be included in the repository. I am currently working on manpages for xeno-load(1) and runinfo(5) (for the format of .runinfo files). I will send a patch with these. -- Romain Lenglet --- xenomai/GNUmakefile.am 2005-10-08 06:11:23.0 +0900 +++ xenomai-man/GNUmakefile.am 2005-10-18 01:44:09.813960500 +0900 @@ -12,7 +12,8 @@ scripts \ @XENO_MAYBE_DOCDIR@ \ $(subdirs) \ - config + config \ + man EXTRA_DIST = CREDITS makefile Kconfig README.INSTALL README.QUICKINSTALL TROUBLESHOOTING @XENO_MAYBE_SIMDIR@ --- xenomai/configure.in 2005-10-15 23:44:26.0 +0900 +++ xenomai-man/configure.in 2005-10-18 01:54:33.004907500 +0900 @@ -1474,6 +1474,7 @@ include/nucleus/asm-ppc64/GNUmakefile \ include/nucleus/asm-ia64/GNUmakefile \ include/nucleus/asm-uvm/GNUmakefile \ + man/GNUmakefile \ nucleus/GNUmakefile \ scripts/GNUmakefile \ scripts/xeno-config \ --- xenomai/man/GNUmakefile.am 1970-01-01 09:00:00.0 +0900 +++ xenomai-man/man/GNUmakefile.am 2005-10-18 01:43:50.464751250 +0900 @@ -0,0 +1,2 @@ +man1_MANS = xeno-config.man +dist_man1_MANS = $(man1_MANS) --- xenomai/man/xeno-config.man 1970-01-01 09:00:00.0 +0900 +++ xenomai-man/man/xeno-config.man 2005-10-18 02:04:16.497373500 +0900 @@ -0,0 +1,120 @@ +'\" t +.\" ** The above line should force tbl to be a preprocessor ** +.\" Man page for xeno-config +.\" +.\" Copyright (C) 2005 Romain Lenglet <[EMAIL PROTECTED]> +.\" +.\" You may distribute under the terms of the GNU General Public +.\" License as specified in the file COPYING that comes with the +.\" Xenomai distribution. +.\" +.pc +.TH XENO-CONFIG 1 "2005-10-17" "1.9.9" "Xenomai" +.SH NAME +xeno-config \- Display Xenomai libraries configuration +.SH SYNOPSIS +.\" The general command line +.B xeno-config +.br +\fBxeno-config\fP \fB\-\-v\fP | \fB\-\-verbose\fP +.br +.B xeno-config \-\-help +.br +\fBxeno-config\fP [\fB\-\-version\fP] [\fB\-\-cc\fP] [\fB\-\-cross\-compile\fP] [\fB\-\-arch\fP] [\fB\-\-subarch\fP] [\fB\-\-prefix\fP] [\fB\-\-config\fP] [\fB\-\-mod*\-cflags\fP|\fB\-\-module\-cflags\fP|\fB\-\-kernel\-cflags\fP] [\fB\-\-xeno\-cflags\fP|\fB\-\-fusion\-cflags\fP] [\fB\-\-xeno\-ldflags\fP|\fB\-\-fusion\-ldflags\fP] [\fB\-\-posix\-cflags\fP] [\fB\-\-posix\-ldflags\fP] [\fB\-\-uvm\-cflags\fP] [\fB\-\-uvm\-ldflags\fP] [\fB\-\-linux\-dir\fP|\fB\-\-linux\fP] [\fB\-\-linux\-ver*\fP|\fB\-\-linux\-version\fP] [\fB\-\-mod*\-dir\fP|\fB\-\-module\-dir\fP] [\fB\-\-sym*\-dir\fP|\fB\-\-symbol\-dir\fP] [\fB\-\-lib*\-dir\fP|\fB\-\-library\-dir\fP|\fB\-\-libdir\fP|\fB\-\-user\-libdir\fP] +.SH DESCRIPTION +\fBxeno-config\fP is a script that is used to to display the compiler and linker flags that are required for building applications that use Xenomai. +Any combination of options can be chosen (except \fB\-\-verbose\fP and \fB\-\-help\fP) to display configuration information, and options can be given in any order. +The command output one line for each option, in the same order as the options. + +When \fBxeno-config \-\-verbose\fP is executed, all configuration information is displayed in a different, human-readable format. + +When \fBxeno-config\fP is executed without any options, the output is equivalent to than when executing \fBxeno-config \-\-verbose\fP then \fBxeno-config \-\-help\fP. + +.\" +.SH OPTIONS +In an option's description, a \fB*\fP in the option name is meant as a wildcard. For instance, \fB\-\-mod\-cflags\fP, \fB\-\-modu\-cflags\fP and \fB\-\-modanything\-cflags\fP are all valid and synonymous options. +.TP +.B \-\-v, \-\-verbose +Outputs all configuration information, in a human-readable format. +.TP +.B \-\-help +Outputs the list of available command-line options. +.TP +.B \-\-version +Outputs one line with the installed Xenomai version. +.TP +.B \-\-cc +Outputs one line with the path to the C compiler command used to compiled Xenomai. +.TP +.B \-\-cross\-compile +Outputs one line with the name prefix of the commands used to compile Xenomai, in the case it was cross-compiled. +The ouput line is empty if it was not cross-compiled. +.TP +.B \-\-arch +
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Romain Lenglet wrote:
By the way, I noticed that the output of function usage() in that
script was wrong. Here is a correct version, to replace the one
if you see an error, please provide a proper patch.
I cannot see the error youve 'corrected' below..
In fact, youve added one; -v doesnt work, --v does.
in scripts/xeno-config.in:
usage ()
{
cat <
thx
jimc
RE: [Xenomai-core] Testing the adeos-ipipe-2.6.13-ppc-1.0-00.patch
Hi Philippe, Sorry for the late report, Xenomai appears to work fine on a Freescale e500 board (MPC8541E) under Linux 2.6.13. Xenomai version was v1.9.9, ie. the daily snapshot as of today. Here are some preliminary figures (CPU 800MHz, Bus 133MHz, 32 kiB I-Cache 32 kiB D-Cache, 256 kiB L2): switch $ ./run == Sampling period: 100 us RTH| lat min| lat avg| lat max|lost RTD|3660|3690|8070| 0 kaltency $ ./run RTH|klat min|klat avg|klat max| overrun| RTS| -7350| -5715|6420| 0| 00:03:17/00:03:17 latency $ ./run == Sampling period: 100 us RTT| 00:08:04 RTH|-lat min|-lat avg|-lat max|-overrun| RTS| -6930| -4260|8700| 0| 00:08:06/00:08:06 Load for klatency/latency was ping flooding on FCC (piece of cake), and cache calibrator. IMHO, we can do nastier. Thanks! -- Stephane PS: some rtai skin patches are to be expected
Re: [Xenomai-core] [bug-reminder] user/kernel space header deps
Jan Kiszka wrote: Hi, just to avoid that this issue got lost during the migration to Xenomai: It's still not possible to compile a C++ POSIX program with CFLAGS obtained via "xeno-config --posix-ldflags". This is due to the fact that low-level, C++-incompatible headers get included in that case. Moreover, the same scenarion works for native skin programs only by chance at the moment. On the long term, a clear separation between types, defines, function prototypes, etc. needed for the user API on the one and for core compilation on the other side is required. Without duplicating definitions and ABI information, otherwise this would be an absolute nightmare. Suggestions welcome. -- Philippe.
[Xenomai-core] [bug-reminder] user/kernel space header deps
Hi, just to avoid that this issue got lost during the migration to Xenomai: It's still not possible to compile a C++ POSIX program with CFLAGS obtained via "xeno-config --posix-ldflags". This is due to the fact that low-level, C++-incompatible headers get included in that case. Moreover, the same scenarion works for native skin programs only by chance at the moment. On the long term, a clear separation between types, defines, function prototypes, etc. needed for the user API on the one and for core compilation on the other side is required. Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] Testing the adeos-ipipe-2.6.13-ppc-1.0-00.patch
Wolfgang Grandegger wrote: On 10/15/2005 09:17 PM Heikki Lindholm wrote: Wolfgang Grandegger kirjoitti: Hello Philippe, I got Xenomai working on a Ocotea-Board (AMCC 440GX) and a low-end TQM855L-Module (MPC 855) under Linux 2.6.14-rc3 :-). The patch applied with a few hunks and one easy to fix reject and I had to correct two problems. One with FEW_CONTEXT (see attached patch) and the second with "#include " in "xenomai/arch/ppc/hal/switch.S". The include file does not exist (any more) in the kernel tree and therefore I commented out the line. I'm going to perform latency tests on various 4xx and 8xx boards next week. Here are some preliminary figures of the TQM855L-Module (CPU 80 MHz, Bus 40 MHz, 4 kB I-Cache 4 kB D-Cache): If you happen to know some (semi-)comparable figures for the same boards using some commercial RTOS, it would be nice to know them also, for comparison. Well, we only deal with "free" software. But I can compare the result from the klatency test with the one from RTAI/RTHAL under Linux 2.4, of course. This would be a good starting point. -- Philippe.
Re: [Xenomai-core] Testing the adeos-ipipe-2.6.13-ppc-1.0-00.patch
On 10/15/2005 09:17 PM Heikki Lindholm wrote: > Wolfgang Grandegger kirjoitti: >> Hello Philippe, >> >> I got Xenomai working on a Ocotea-Board (AMCC 440GX) and a low-end >> TQM855L-Module (MPC 855) under Linux 2.6.14-rc3 :-). The patch applied >> with a few hunks and one easy to fix reject and I had to correct two >> problems. One with FEW_CONTEXT (see attached patch) and the second with >> "#include " in "xenomai/arch/ppc/hal/switch.S". The >> include file does not exist (any more) in the kernel tree and therefore >> I commented out the line. I'm going to perform latency tests on various >> 4xx and 8xx boards next week. Here are some preliminary figures of the >> TQM855L-Module (CPU 80 MHz, Bus 40 MHz, 4 kB I-Cache 4 kB D-Cache): > > If you happen to know some (semi-)comparable figures for the same boards > using some commercial RTOS, it would be nice to know them also, for > comparison. Well, we only deal with "free" software. But I can compare the result from the klatency test with the one from RTAI/RTHAL under Linux 2.4, of course. Wolfgang.
