Re: [Xenomai-core] [patch] xeno-test email addition
Philippe Gerum wrote: > Jim Cromie wrote: > > Jim Cromie wrote: > >> Niklaus Giger wrote: > >>> Hi > >>> > >>> Following a suggestion from Philippe Gerum I propose to > >>> collect and prepare like this: > >>> > >>> a) Make it easy to collect information > >>> > >>> add -s/-c option to xeno-test, help text would look like > >>> -s send output of xeno-test to [EMAIL PROTECTED] -c > >>> if -s, send also kernel config file to > >>> [EMAIL PROTECTED] > >> > >> attached patch adds new -m -M flags for xeno-test, (-s flag > >> is taken, for statistics) > >> former for a fixed addy (to be patched later), latter > >> taking any email as arg. > >> > >> I didnt add -c , since xeno-test already does > >> something similar; if you build with > >> CONFIG_IKCONFIG_PROC=y, xeno-test greps XENO out of > >> /proc/config.gz > >> (probably needs a few more grep terms, and perhaps a > >> -verbose mode which cats the whole thing.) > >> > >> The -M option works, since I just received an email Id sent > >> earlier, but I also sent one to xenomai-core, and it hasnt > >> shown up yet. I suspect that the mail looks like spam, and > >> has been rejected, since my hostname is not a real FQDN. > >> So Im not so sure that email is the best way here, but it > >> is conceptually simple. > > > > Oof. Now attached. > > Applied, thanks. Here is its little brother patch which updates the manpage. -- Romain LENGLET --- xenomai/ChangeLog 2006-04-19 12:30:32.503520224 +0900 +++ xenomai-xenotestmail/ChangeLog 2006-04-19 12:49:28.379840776 +0900 @@ -1,3 +1,8 @@ +2006-04-19 Romain Lenglet <[EMAIL PROTECTED]> + + * doc/man/xeno-test.man.in: Add documentation for the new -m and -M + options added to the xeno-test script. + 2006-04-18 Jim Cromie <[EMAIL PROTECTED]> * scripts/xeno-test.in: Add -[Mm] options for automated --- xenomai/doc/man/xeno-test.man.in 2006-03-28 14:12:36.109329864 +0900 +++ xenomai-xenotestmail/doc/man/xeno-test.man.in 2006-04-19 12:48:53.585130376 +0900 @@ -9,11 +9,11 @@ .\" Xenomai distribution. .\" .pc -.TH XENO-TEST 1 "2005-10-19" "@PACKAGE_VERSION@" "Xenomai" +.TH XENO-TEST 1 "2006-04-19" "@PACKAGE_VERSION@" "Xenomai" .SH NAME -xeno\-test \- Tests and mesures the performance of a Xenomai installation +xeno\-test \- Tests and measures the performance of a Xenomai installation .SH SYNOPSIS -\fBxeno\-test\fP [\fB\-w\fP \fIworkloads\fP] [\fB\-d\fP \fIdevice\fP] [\fB\-W\fP \fIcommand\fP] [\fB\-p\fP \fIcommand\fP] [\fB\-L\fP [\fB\-N\fP \fIprefix\fP]] [\fB\-s\fP] [\fB\-l\fP \fIsamples\fP] [\fB\-h\fP [\fB\-H\fP \fIcategories\fP] [\fB\-B\fP \fIgranularity\fP]] [\fB\-T\fP \fIseconds\fP [\fB\-q\fP]] [\fB\-\-\fP] [\fIargs\fP] ... +\fBxeno\-test\fP [\fB\-w\fP \fIworkloads\fP] [\fB\-d\fP \fIdevice\fP] [\fB\-W\fP \fIcommand\fP] [\fB\-p\fP \fIcommand\fP] [\fB\-L\fP [\fB\-N\fP \fIprefix\fP]] [\fB\-m\fP | \fB\-M\fP \fIemail\fP] [\fB\-s\fP] [\fB\-l\fP \fIsamples\fP] [\fB\-h\fP [\fB\-H\fP \fIcategories\fP] [\fB\-B\fP \fIgranularity\fP]] [\fB\-T\fP \fIseconds\fP [\fB\-q\fP]] [\fB\-\-\fP] [\fIargs\fP] ... .SH DESCRIPTION \fBxeno\-test\fP measures the performance of Xenomai, by executing Xenomai's \fBlatency\fP and \fBklatency\fP tests while generating a high workload on the system. The default command that is executed to simulate workload (if no alternate command is specified with a \fB-W\fP \fIcommand\fP option) is: @@ -29,6 +29,8 @@ If an invalid option is specified, \fBxeno\-test\fP prints out an usage help message and exits. +You are strongly encouraged to use the \fB\-m\fP option, to anonymously help the Xenomai team collecting statistics about Xenomai's performance on the widest range of systems. + .SH OPTIONS These following options are specific to \fBxeno\-test\fP: .TP @@ -55,6 +57,12 @@ \fB\-N\fP \fIprefix\fP Prepends \fIprefix\fP\fB\-\fP to the log file name, hence if the \fB\-L\fP option is also specified the log file name is \fIprefix\fP\fB\-test\-\fP\fIkernel_release\fP. This option is useful to create the log file in a different directory, by specifying a \fIprefix\fP that starts with the relative path to that directory. +.TP +\fB\-m\fP +Sends the results of the tests to the Xenomai team's email address, to help collecting statistics about Xenomai's performance. The email is sent using the system's mail(1) command. +.TP +\fB\-M\fP \fIemail\fP +Sends the results of the tests to the specified email address. The email is sent using the system's mail(1) command. .PP The following options are directly passed to the \fBlatency\fP and \fBklatency\fP test commands executed by \fBxeno\-test\fP. If no such options are specified, the \fB\-s \-T 10 \-q\fP options are passed by default by \fBxeno\-test\fP. @@ -111,5 +119,8 @@ .BR uname (1) .SH HISTORY .TP +2006-04-19 +Updated to document the new -m and -M options. +.TP 2005-10-19 Written by Romain Lenglet <[EMAIL PROTECTED]> ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-
Re: [Xenomai-core] Kernel becomes 2.6.16.7
Sorry, actually, 2.6.17 is not ready yet. I've read it on hurry... it is actually a 2.6.16.7... Working perfectly fine with current patch... Sorry for the confusion, Rodrigo. Em Terça 18 Abril 2006 18:08, Jan Kiszka escreveu: >Rodrigo Rosenfeld Rosas wrote: >> Just informing... (in the hope of downloading a new adeos patch soon ;) ) > >Go ahead and give it a try: my "port" for x86 to 2.6.16 was about fixing >4 failing hunks in the 2.6.15-patch (+ some minor namespace collision in >the posix skin). > >Jan ___ Novo Yahoo! Messenger com voz: Instale agora e faça ligações de graça. http://br.messenger.yahoo.com/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATH] fix pthread.h include
--- include/posix/pthread.h (revision 946) +++ include/posix/pthread.h (working copy) @@ -137,6 +137,7 @@ typedef struct #include #include_next +#include struct timespec; [In order to use PTHREAD_WARNSW in userspace.] 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] Kernel becomes 2.6.17
Rodrigo Rosenfeld Rosas wrote: > Just informing... (in the hope of downloading a new adeos patch soon ;) ) > Go ahead and give it a try: my "port" for x86 to 2.6.16 was about fixing 4 failing hunks in the 2.6.15-patch (+ some minor namespace collision in the posix skin). Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [patch] readme.install & troubleshooting
heres another try, adjusting per Rodrigo's, Gilles' feedback, and filling in from linux Kconfig and wikipedia on ACPI. FYI, the latter is quite informative, esp on sleep states. The speculative content continues - I dont mind being wrong, esp when its temporary / corrected :-) I held back a bit on one wild conjecture, which connects to the xeno-stats effort / discussion. Ill start with a Q, and see where it goes: (feel free to change subject when replying ;-) Ive seen idle=poll boot-arg fix the Geode SC-1100's buggy TSC by preventing it from entering C1 state (conjecture-1 ? ;). Might this also 'fix' the latency problems caused by ACPI_PROCESSOR ? If so, it improves flexibility by a little, allowing some latency decisions to be made at boot time rather than compile time. Not quite as flexible as toggling linux-scheduler-idle behavior via sysctl, but it doesnt introduce new code either. I'll be testing this notion on my laptop (which has an ACPI BIOS) when time permits, but would appreciate guesses as to probability of useful results, tips, etc. Index: TROUBLESHOOTING === --- TROUBLESHOOTING (revision 946) +++ TROUBLESHOOTING (working copy) @@ -6,6 +6,57 @@ GENERIC === +Q: Which CONFIG_* items are latency killers, and should be avoided ? + +A: Heres an enumeration. Several of these are discussed in greater +detail in following sections. + +CONFIG_CPU_FREQ: This allows the CPU frequency to be modulated with +workload, but many CPUs change the TSC counting frequency also, which +makes it useless for accurate timing when the CPU clock can change. +Also some CPUs can take several milliseconds to ramp up to full speed. + +APM: The APM model assigns power management control to the BIOS, and +BIOS code is never written with RT-latency in mind. If configured, +APM routines are invoked with SMI priority, which breaks the rule that +adeos-ipipe must be in charge of such things. DISABLE_SMI doesnt help +here (more later). + +ACPI_PROCESSOR: For systems with ACPI support in the BIOS, this ACPI +sub-option installs an 'idle' handler that uses ACPI C2 and C3 +processor states to save power. The CPU must 'warm-up' from these +sleep states, increasing latency in ways dependent upon both the +BIOS's ACPI tables and code. You may be able to suppress the sleeping +with 'idle=poll' boot-arg, test to find out + +Summarizing, the latencies incurred here are dependent upon CPU, BIOS, +and motherboard; ie they're hard to predict, so we are conservative. +Feel free to test on your platform, (xeno-test runs testsuite/latency +in 3 modes), but keep in mind that before you rely on the numbers, you +must test with workloads that will exercise all the hardware used for +your RT application. + +__ + +Q: How do I adequately stress-test ? + +A: xeno-test has a very basic workload generator, whose main virtue is +that its nearly universally available. + +dd if=/dev/zero of=/dev/null + +You can change the input device (-d /dev/hda1) to get real device +activity and interrupts, and/or -w 4 to run more workload tasks. For +more thorough testing, use -W . + +If you are looking for real heavy loads, cache benchmarks tend to +stress your system the most, http://www.cwi.nl/~manegold/Calibrator +for example. Combine them with heavy i/o load (flood ping etc.) to +generate device interrupts. Also consider benchmarking software, such +as bonnie++, cpuburn, lmbench. + +__ + Q: My user-space application has unexpected latencies which seem to appear when transitioning from primary (Xenomai) to secondary (native Linux) real-time modes. Why? Index: README.INSTALL === --- README.INSTALL (revision 946) +++ README.INSTALL (working copy) @@ -74,12 +74,14 @@ Once the target kernel has been prepared, all Xenomai configuration options are available from the "Real-time subsystem" toplevel menu. -Once configured, the kernel should be built as usual. +There are several configure options that cause large latencies; they +should be avoided. The TROUBLESHOOTING file identifies them and +explains the issues with their use. Once configured, the kernel +should be built as usual. -It might be a good idea to put all the output into a different build -directory as to build from from linux source several targets. For each -target add O=../build- to each make invocation. See section 2.2 -for an example. +If you want several different configs/builds at hand, you can reuse +the same source by adding O=../build- to each make +invocation. See section 2.2 for an example. In order to cross-compile the Linux kernel, pass an ARCH and CROSS_COMPILE variable on make command line. S
[Xenomai-core] Kernel becomes 2.6.17
Just informing... (in the hope of downloading a new adeos patch soon ;) ) Regards, Rodrigo. ___ Abra sua conta no Yahoo! Mail: 1GB de espaço, alertas de e-mail no celular e anti-spam realmente eficaz. http://br.info.mail.yahoo.com/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] collecting xenomai statistics
Niklaus Giger wrote: > But I would be very interested in knowing exactly which kind of information > the core developers are interested in. How should it be presented? In > tabular > form? Graphs, which ones? And kind of feedback will be evaluated and > integrated. I did some similar work once, so I have some ideas. What I would like to have is, given a configuration (.config) build all versions of Adeos+Xenomai for a given set of compilers. Then, present the result in a tabular form. Each cell would give the number of warnings and errors for the corresponding build, with links to browseable build logs. Maybe the cell could have different colors (green, orange, red) depending on the number of warnings and errors. What would also be interesting, is to test the "distcheck" target. The interesting result being a comparison between the source directory contents and the generated tarball contents (if distcheck is successful). -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Check for NPTL and factor user-space skins initialization.
Gilles Chanteperdrix wrote: Philippe Gerum wrote: > > Is this worth doing also ? > > Some deeply embedded stuff (something like buried in the silicon > actually...) might configure out CONFIG_PROC_FS, so we can't rely on > this pseudo-fs to be always present. Maybe we could use the information if available? It would be redundant, since the nucleus already tells us whether sep is known or not at kernel level. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] collecting xenomai statistics
Jim Cromie wrote: > perhaps as a 4th number on the version, that way xeno-config can stay as is. > > [EMAIL PROTECTED] bin]# ./xeno-config --version > 2.1.50 > Id like instead: > 2.1.50.941 > > This seems better than pokinh around a filesystem, looking for the > xenomai svn > (which may be on the build-host, not the run-host) If you want to change the version returned by xeno-config, simply modify config/version and re-run scripts/bootstrap before building Xenomai. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Check for NPTL and factor user-space skins initialization.
Philippe Gerum wrote: > > Is this worth doing also ? > > Some deeply embedded stuff (something like buried in the silicon > actually...) might configure out CONFIG_PROC_FS, so we can't rely on > this pseudo-fs to be always present. Maybe we could use the information if available? -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] collecting xenomai statistics
Jim Cromie wrote: > The -M option works, since I just received an email Id sent earlier, > but I also sent one to xenomai-core, and it hasnt shown up yet. In order to avoid spam, the xenomai-core list probably only accept mail from registered members. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Check for NPTL and factor user-space skins initialization.
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > >
> > > -ENOPARSE here. Which code is expected to call xeno_mlock_alert_end()?
> >
> > pthread_set_mode_np and rt_task_set_mode. Sorry.
>
> The issue I see doing so, is that you are going to trigger a SIGXCPU
> right after setting the XNTRAPSW bit for the current thread, as a result
> of calling sigaction and friends. This is why I used a plain and dumb
> memory flag instead, the logic being:
>
> - first, trap SIGXCPU in the library ctor to detect the lack of process
> memory locking when mapping a shadow thread, and emit an explanatory
> message when caught.
>
> - as soon as a thread succeeds in setting modes (set_mode_np and
> friends), then we know that a previous shadow mapping for the current
> Linux task has succeeded, otherwise the nucleus would not have been able
> to carry out the set_mode request. In such a case, make sure to cause
> our internal SIGXCPU handler to switch to the default behaviour, in case
> we did set the WARNSW bit for the current thread successfully. In all
> other cases, either the user has set its own SIGXCPU handler overriding
> our internal one, and we have no part in the play, or she did not and we
> won't spuriously emit the "missing mlock" message.
Ok. Another try.
--
Gilles Chanteperdrix.
Index: include/asm-i386/features.h
===
--- include/asm-i386/features.h (revision 941)
+++ include/asm-i386/features.h (working copy)
@@ -76,4 +76,33 @@
}
}
+#ifndef __KERNEL__
+#include
+#include
+#include
+#include
+
+static inline void xeno_x86_features_check(void)
+{
+#ifdef CONFIG_XENO_X86_SEP
+ size_t n = confstr(_CS_GNU_LIBPTHREAD_VERSION, NULL, 0);
+ if (n > 0)
+ {
+ char buf[n];
+
+ confstr (_CS_GNU_LIBPTHREAD_VERSION, buf, n);
+
+ if (strstr (buf, "NPTL"))
+ return;
+ }
+
+ fprintf(stderr, "Xenomai: SEP instruction needs NPTL and NPTL was not
detected"
+ "\nplease install NPTL or rebuild the user-space support passing "
+ "--disable-x86-sep.\n");
+ exit(1);
+#endif /* CONFIG_XENO_X86_SEP */
+}
+#define xeno_arch_features_check() xeno_x86_features_check()
+#endif /* __KERNEL__ */
+
#endif /* !_XENO_ASM_I386_FEATURES_H */
Index: include/nucleus/Makefile.am
===
--- include/nucleus/Makefile.am (revision 941)
+++ include/nucleus/Makefile.am (working copy)
@@ -22,3 +22,5 @@
types.h \
version.h \
xenomai.h
+
+EXTRA_DIST = skin_init.h
Index: src/skins/rtai/init.c
===
--- src/skins/rtai/init.c (revision 941)
+++ src/skins/rtai/init.c (working copy)
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
int __rtai_muxid = -1;
@@ -26,45 +27,5 @@
static __attribute__((constructor)) void __init_rtai_interface(void)
{
-xnfeatinfo_t finfo;
-int muxid;
-
-muxid = XENOMAI_SYSBIND(RTAI_SKIN_MAGIC,
- XENOMAI_FEAT_DEP,
- XENOMAI_ABI_REV,
- &finfo);
-switch (muxid)
- {
- case -EINVAL:
-
- fprintf(stderr,"Xenomai: incompatible feature set\n");
- fprintf(stderr,"(required=\"%s\", present=\"%s\",
missing=\"%s\").\n",
- finfo.feat_man_s,finfo.feat_all_s,finfo.feat_mis_s);
- exit(1);
-
- case -ENOEXEC:
-
- fprintf(stderr,"Xenomai: incompatible ABI revision level\n");
- fprintf(stderr,"(needed=%lu, current=%lu).\n",
- XENOMAI_ABI_REV,finfo.abirev);
- exit(1);
-
- case -ENOSYS:
- case -ESRCH:
-
- fprintf(stderr,"Xenomai: RTAI skin or CONFIG_XENO_OPT_PERVASIVE
disabled.\n");
- fprintf(stderr,"(modprobe xeno_rtai?)\n");
- exit(1);
-
- default:
-
- if (muxid < 0)
- {
- fprintf(stderr,"Xenomai: binding failed:
%s.\n",strerror(-muxid));
- exit(1);
- }
-
- __rtai_muxid = muxid;
- break;
- }
+__rtai_muxid = xeno_user_skin_init(RTAI_SKIN_MAGIC, "RTAI", "xeno_rtai");
}
Index: src/skins/posix/init.c
===
--- src/skins/posix/init.c (revision 941)
+++ src/skins/posix/init.c (working copy)
@@ -23,85 +23,22 @@
#include
#include
#include
+#include
#include
#include
#include
int __pse51_muxid = -1;
-int __pse51_sigxcpu_no_mlock = 1;
int __rtdm_muxid = -1;
int __rtdm_fd_start = INT_MAX;
-void __handle_lock_alert (int sig)
-
-{
-struct sigaction sa;
-
-if (__pse51_sigxcpu_no_mlock)
- {
- fprintf(stderr,"Xenomai: process memory not locked (missing
mlockall?)\n");
-
[Xenomai-core] /proc/cpuinfo missing sep - closure
just to follow up: I built a xeno-kernel for my laptop, the sep flag was on, so it was Fedora specific. I asked on fedora-list, got this answer: > This is pretty obscure, and I havent seen any problems because of it, > but it is a bit odd. > > Can someone(s) > - confirm its absence on 2.6.16-1.2069_FC4 or other > - check their FC-5 /proc/cpuinfo, and report back. > - explain why this is a good thing, or how it might have happened > accidentally ? SEP is incompatible with segment-based NX emulation provided by exec-shield in the Fedora kernel. The reason for this is that a SYSRET resets the segment limits. I presume this distinction is well hidden inside glibc etc.. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [patch] xeno-test email addition
Jim Cromie wrote: Jim Cromie wrote: Niklaus Giger wrote: Hi Following a suggestion from Philippe Gerum I propose to collect and prepare like this: a) Make it easy to collect information add -s/-c option to xeno-test, help text would look like -s send output of xeno-test to [EMAIL PROTECTED] -c if -s, send also kernel config file to [EMAIL PROTECTED] attached patch adds new -m -M flags for xeno-test, (-s flag is taken, for statistics) former for a fixed addy (to be patched later), latter taking any email as arg. I didnt add -c , since xeno-test already does something similar; if you build with CONFIG_IKCONFIG_PROC=y, xeno-test greps XENO out of /proc/config.gz (probably needs a few more grep terms, and perhaps a -verbose mode which cats the whole thing.) The -M option works, since I just received an email Id sent earlier, but I also sent one to xenomai-core, and it hasnt shown up yet. I suspect that the mail looks like spam, and has been rejected, since my hostname is not a real FQDN. So Im not so sure that email is the best way here, but it is conceptually simple. Oof. Now attached. Applied, thanks. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Check for NPTL and factor user-space skins initialization.
Jim Cromie wrote:
Gilles Chanteperdrix wrote:
For review...
+#ifndef __KERNEL__
+#include
+#include
+#include
+#include
+
+static inline void xeno_x86_features_check(void)
+{
+#ifdef CONFIG_XENO_X86_SEP
+ size_t n = confstr(_CS_GNU_LIBPTHREAD_VERSION, NULL, 0);
+ if (n > 0)
+ {
since this is user code, its possible to read /proc/cpuinfo,
and find the sep flag.
Is this worth doing also ?
Some deeply embedded stuff (something like buried in the silicon
actually...) might configure out CONFIG_PROC_FS, so we can't rely on
this pseudo-fs to be always present.
if so, I can work a patch up later, unless you feel the urge.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [patch] xeno-test email addition
Jim Cromie wrote:
Niklaus Giger wrote:
Hi
Following a suggestion from Philippe Gerum I propose to collect and
prepare like this:
a) Make it easy to collect information
add -s/-c option to xeno-test, help text would look like -s
send output of xeno-test to [EMAIL PROTECTED]
-c if -s, send also kernel config file to [EMAIL PROTECTED]
attached patch adds new -m -M flags for xeno-test, (-s flag is taken,
for statistics)
former for a fixed addy (to be patched later), latter taking any email
as arg.
I didnt add -c , since xeno-test already does something similar;
if you build with CONFIG_IKCONFIG_PROC=y, xeno-test greps XENO out of
/proc/config.gz
(probably needs a few more grep terms, and perhaps a -verbose mode which
cats the whole thing.)
The -M option works, since I just received an email Id sent earlier,
but I also sent one to xenomai-core, and it hasnt shown up yet.
I suspect that the mail looks like spam, and has been rejected,
since my hostname is not a real FQDN.
So Im not so sure that email is the best way here, but it is
conceptually simple.
Oof. Now attached.
Index: scripts/xeno-test.in
===
--- scripts/xeno-test.in(revision 943)
+++ scripts/xeno-test.in(working copy)
@@ -17,6 +17,8 @@
-L writes to logfile (default "test-`uname -r`") (via script)
-N same as -L, but prepend "$name-" (without -L, logname="$name-")
prepending allows you to give a full path.
+ -m sends output file to [EMAIL PROTECTED]
+ -Msends output file to given addy
# following options are passed thru to latency, klatency
-s print statistics of sampled data (default on)
@@ -136,8 +138,11 @@
logprefix=
prepost= # command to run pre, and post test (ex ntpq -p)
-while getopts 'd:shqT:l:H:B:uLN:w:W:p:' FOO ; do
+email='[EMAIL PROTECTED]'
+sendit=
+while getopts 'd:shqT:l:H:B:uLN:w:W:p:mM:' FOO ; do
+
case $FOO in
s|h|q)
pass="$pass -$FOO" ;;
@@ -166,6 +171,11 @@
p)
prepost=$OPTARG
loadpass="$loadpass -p '$OPTARG'" ;;
+ M)
+ email=$OPTARG
+ sendit=1 ;;
+ m)
+ sendit=1 ;;
?)
myusage ;;
esac
@@ -179,6 +189,10 @@
# restart inside a script invocation, passing all
date=`date +%y%m%d.%H%M%S`
script -c "./xeno-test $loadpass $pass $*" "$logprefix$logfile-$date"
+if [ $sendit == 1 ]; then
+ echo "mailing $logprefix$logfile-$date to $email"
+ mail -s 'xeno-test results' $email < "$logprefix$logfile-$date"
+fi
else
if [ "$altwork" != "" ]; then
mkload() { exec $altwork; }
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Check for NPTL and factor user-space skins initialization.
Gilles Chanteperdrix wrote: Philippe Gerum wrote: > > -ENOPARSE here. Which code is expected to call xeno_mlock_alert_end()? pthread_set_mode_np and rt_task_set_mode. Sorry. The issue I see doing so, is that you are going to trigger a SIGXCPU right after setting the XNTRAPSW bit for the current thread, as a result of calling sigaction and friends. This is why I used a plain and dumb memory flag instead, the logic being: - first, trap SIGXCPU in the library ctor to detect the lack of process memory locking when mapping a shadow thread, and emit an explanatory message when caught. - as soon as a thread succeeds in setting modes (set_mode_np and friends), then we know that a previous shadow mapping for the current Linux task has succeeded, otherwise the nucleus would not have been able to carry out the set_mode request. In such a case, make sure to cause our internal SIGXCPU handler to switch to the default behaviour, in case we did set the WARNSW bit for the current thread successfully. In all other cases, either the user has set its own SIGXCPU handler overriding our internal one, and we have no part in the play, or she did not and we won't spuriously emit the "missing mlock" message. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Check for NPTL and factor user-space skins initialization.
Gilles Chanteperdrix wrote:
For review...
+#ifndef __KERNEL__
+#include
+#include
+#include
+#include
+
+static inline void xeno_x86_features_check(void)
+{
+#ifdef CONFIG_XENO_X86_SEP
+ size_t n = confstr(_CS_GNU_LIBPTHREAD_VERSION, NULL, 0);
+ if (n > 0)
+ {
since this is user code, its possible to read /proc/cpuinfo,
and find the sep flag.
Is this worth doing also ?
if so, I can work a patch up later, unless you feel the urge.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Check for NPTL and factor user-space skins initialization.
Philippe Gerum wrote:
>
> -ENOPARSE here. Which code is expected to call xeno_mlock_alert_end()?
pthread_set_mode_np and rt_task_set_mode. Sorry.
--
Gilles Chanteperdrix.
Index: include/asm-i386/features.h
===
--- include/asm-i386/features.h (revision 941)
+++ include/asm-i386/features.h (working copy)
@@ -76,4 +76,35 @@
}
}
+#ifndef __KERNEL__
+#include
+#include
+#include
+#include
+
+static inline void xeno_x86_features_check(void)
+{
+#ifdef CONFIG_XENO_X86_SEP
+ size_t n = confstr(_CS_GNU_LIBPTHREAD_VERSION, NULL, 0);
+ if (n > 0)
+ {
+ char *buf = malloc(n);
+ int isnptl;
+
+ confstr (_CS_GNU_LIBPTHREAD_VERSION, buf, n);
+ isnptl = strstr (buf, "NPTL") != NULL;
+ free(buf);
+
+ if (isnptl)
+ return;
+ }
+
+ fprintf(stderr, "Xenomai: SEP instruction needs NPTL and NPTL was not
detected"
+ "\nplease install NPTL or recompile Xenomai without enabling
SEP.\n");
+ exit(1);
+#endif /* CONFIG_XENO_X86_SEP */
+}
+#define xeno_arch_features_check() xeno_x86_features_check()
+#endif /* __KERNEL__ */
+
#endif /* !_XENO_ASM_I386_FEATURES_H */
Index: include/nucleus/Makefile.am
===
--- include/nucleus/Makefile.am (revision 941)
+++ include/nucleus/Makefile.am (working copy)
@@ -22,3 +22,5 @@
types.h \
version.h \
xenomai.h
+
+EXTRA_DIST = skin_init.h
Index: src/skins/rtai/init.c
===
--- src/skins/rtai/init.c (revision 941)
+++ src/skins/rtai/init.c (working copy)
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
int __rtai_muxid = -1;
@@ -26,45 +27,5 @@
static __attribute__((constructor)) void __init_rtai_interface(void)
{
-xnfeatinfo_t finfo;
-int muxid;
-
-muxid = XENOMAI_SYSBIND(RTAI_SKIN_MAGIC,
- XENOMAI_FEAT_DEP,
- XENOMAI_ABI_REV,
- &finfo);
-switch (muxid)
- {
- case -EINVAL:
-
- fprintf(stderr,"Xenomai: incompatible feature set\n");
- fprintf(stderr,"(required=\"%s\", present=\"%s\",
missing=\"%s\").\n",
- finfo.feat_man_s,finfo.feat_all_s,finfo.feat_mis_s);
- exit(1);
-
- case -ENOEXEC:
-
- fprintf(stderr,"Xenomai: incompatible ABI revision level\n");
- fprintf(stderr,"(needed=%lu, current=%lu).\n",
- XENOMAI_ABI_REV,finfo.abirev);
- exit(1);
-
- case -ENOSYS:
- case -ESRCH:
-
- fprintf(stderr,"Xenomai: RTAI skin or CONFIG_XENO_OPT_PERVASIVE
disabled.\n");
- fprintf(stderr,"(modprobe xeno_rtai?)\n");
- exit(1);
-
- default:
-
- if (muxid < 0)
- {
- fprintf(stderr,"Xenomai: binding failed:
%s.\n",strerror(-muxid));
- exit(1);
- }
-
- __rtai_muxid = muxid;
- break;
- }
+__rtai_muxid = xeno_user_skin_init(RTAI_SKIN_MAGIC, "RTAI", "xeno_rtai");
}
Index: src/skins/posix/init.c
===
--- src/skins/posix/init.c (revision 941)
+++ src/skins/posix/init.c (working copy)
@@ -23,85 +23,23 @@
#include
#include
#include
+#include
#include
#include
#include
int __pse51_muxid = -1;
-int __pse51_sigxcpu_no_mlock = 1;
int __rtdm_muxid = -1;
int __rtdm_fd_start = INT_MAX;
-void __handle_lock_alert (int sig)
-
-{
-struct sigaction sa;
-
-if (__pse51_sigxcpu_no_mlock)
- {
- fprintf(stderr,"Xenomai: process memory not locked (missing
mlockall?)\n");
- fflush(stderr);
- exit(4);
- }
-else
- {
- /* PTHREAD_WARNSW was set for the thread but no user-defined
- handler has been set to override our internal handler, so
- let's invoke the default signal action. */
- sa.sa_handler = SIG_DFL;
- sigemptyset(&sa.sa_mask);
- sa.sa_flags = 0;
- sigaction(SIGXCPU,&sa,NULL);
- pthread_kill(pthread_self(),SIGXCPU);
- }
-}
-
static __attribute__((constructor)) void __init_posix_interface(void)
{
struct sigaction sa;
-xnfeatinfo_t finfo;
int muxid;
+
+__pse51_muxid = xeno_user_skin_init(PSE51_SKIN_MAGIC, "POSIX",
"xeno_posix");
-muxid = XENOMAI_SYSBIND(PSE51_SKIN_MAGIC,
- XENOMAI_FEAT_DEP,
- XENOMAI_ABI_REV,
- &finfo);
-switch (muxid)
- {
- case -EINVAL:
-
- fprintf(stderr,"Xenomai: incompatible feature set\n");
- fprintf(stderr,"(required=\"%s\", present=\"%s\",
missing=\"%s\").\n",
- finfo.feat_man_s,finfo.feat_all_s,finfo.feat_mis_s);
-
Re: [Xenomai-core] [PATCH] Check for NPTL and factor user-space skins initialization.
Gilles Chanteperdrix wrote:
For review...
Index: include/asm-i386/features.h
===
--- include/asm-i386/features.h (revision 941)
+++ include/asm-i386/features.h (working copy)
@@ -76,4 +76,35 @@
}
}
+#ifndef __KERNEL__
+#include
+#include
+#include
+#include
+
+static inline void xeno_x86_features_check(void)
+{
+#ifdef CONFIG_XENO_X86_SEP
+ size_t n = confstr(_CS_GNU_LIBPTHREAD_VERSION, NULL, 0);
+ if (n > 0)
+ {
+ char *buf = malloc(n);
+ int isnptl;
+
+ confstr (_CS_GNU_LIBPTHREAD_VERSION, buf, n);
+ isnptl = strstr (buf, "NPTL") != NULL;
+ free(buf);
+
+ if (isnptl)
+ return;
+ }
+
+ fprintf(stderr, "Xenomai: SEP instruction needs NPTL and NPTL was not
detected"
+ "\nplease install NPTL or recompile Xenomai without enabling
SEP.\n");
- "\nplease install NPTL or recompile Xenomai without enabling
SEP.\n");
+ "\nplease install NPTL or rebuild the user-space support
passing --disable-x86-sep.\n");
+static inline void xeno_mlock_alert_end(void)
+{
+struct sigaction sa;
+
+sigaction(SIGXCPU, NULL, &sa);
+if (sa.sa_handler == &xeno_handle_mlock_alert)
+{
+sa.sa_handler = SIG_DFL;
+sigaction(SIGXCPU, &sa, NULL);
+}
+}
+
-ENOPARSE here. Which code is expected to call xeno_mlock_alert_end()?
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Check for NPTL and factor user-space skins initialization.
For review...
--
Gilles Chanteperdrix.
Index: include/asm-i386/features.h
===
--- include/asm-i386/features.h (revision 941)
+++ include/asm-i386/features.h (working copy)
@@ -76,4 +76,35 @@
}
}
+#ifndef __KERNEL__
+#include
+#include
+#include
+#include
+
+static inline void xeno_x86_features_check(void)
+{
+#ifdef CONFIG_XENO_X86_SEP
+ size_t n = confstr(_CS_GNU_LIBPTHREAD_VERSION, NULL, 0);
+ if (n > 0)
+ {
+ char *buf = malloc(n);
+ int isnptl;
+
+ confstr (_CS_GNU_LIBPTHREAD_VERSION, buf, n);
+ isnptl = strstr (buf, "NPTL") != NULL;
+ free(buf);
+
+ if (isnptl)
+ return;
+ }
+
+ fprintf(stderr, "Xenomai: SEP instruction needs NPTL and NPTL was not
detected"
+ "\nplease install NPTL or recompile Xenomai without enabling
SEP.\n");
+ exit(1);
+#endif /* CONFIG_XENO_X86_SEP */
+}
+#define xeno_arch_features_check() xeno_x86_features_check()
+#endif /* __KERNEL__ */
+
#endif /* !_XENO_ASM_I386_FEATURES_H */
Index: include/nucleus/Makefile.am
===
--- include/nucleus/Makefile.am (revision 941)
+++ include/nucleus/Makefile.am (working copy)
@@ -22,3 +22,5 @@
types.h \
version.h \
xenomai.h
+
+EXTRA_DIST = skin_init.h
Index: src/skins/rtai/init.c
===
--- src/skins/rtai/init.c (revision 941)
+++ src/skins/rtai/init.c (working copy)
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
int __rtai_muxid = -1;
@@ -26,45 +27,5 @@
static __attribute__((constructor)) void __init_rtai_interface(void)
{
-xnfeatinfo_t finfo;
-int muxid;
-
-muxid = XENOMAI_SYSBIND(RTAI_SKIN_MAGIC,
- XENOMAI_FEAT_DEP,
- XENOMAI_ABI_REV,
- &finfo);
-switch (muxid)
- {
- case -EINVAL:
-
- fprintf(stderr,"Xenomai: incompatible feature set\n");
- fprintf(stderr,"(required=\"%s\", present=\"%s\",
missing=\"%s\").\n",
- finfo.feat_man_s,finfo.feat_all_s,finfo.feat_mis_s);
- exit(1);
-
- case -ENOEXEC:
-
- fprintf(stderr,"Xenomai: incompatible ABI revision level\n");
- fprintf(stderr,"(needed=%lu, current=%lu).\n",
- XENOMAI_ABI_REV,finfo.abirev);
- exit(1);
-
- case -ENOSYS:
- case -ESRCH:
-
- fprintf(stderr,"Xenomai: RTAI skin or CONFIG_XENO_OPT_PERVASIVE
disabled.\n");
- fprintf(stderr,"(modprobe xeno_rtai?)\n");
- exit(1);
-
- default:
-
- if (muxid < 0)
- {
- fprintf(stderr,"Xenomai: binding failed:
%s.\n",strerror(-muxid));
- exit(1);
- }
-
- __rtai_muxid = muxid;
- break;
- }
+__rtai_muxid = xeno_user_skin_init(RTAI_SKIN_MAGIC, "RTAI", "xeno_rtai");
}
Index: src/skins/posix/init.c
===
--- src/skins/posix/init.c (revision 941)
+++ src/skins/posix/init.c (working copy)
@@ -23,85 +23,23 @@
#include
#include
#include
+#include
#include
#include
#include
int __pse51_muxid = -1;
-int __pse51_sigxcpu_no_mlock = 1;
int __rtdm_muxid = -1;
int __rtdm_fd_start = INT_MAX;
-void __handle_lock_alert (int sig)
-
-{
-struct sigaction sa;
-
-if (__pse51_sigxcpu_no_mlock)
- {
- fprintf(stderr,"Xenomai: process memory not locked (missing
mlockall?)\n");
- fflush(stderr);
- exit(4);
- }
-else
- {
- /* PTHREAD_WARNSW was set for the thread but no user-defined
- handler has been set to override our internal handler, so
- let's invoke the default signal action. */
- sa.sa_handler = SIG_DFL;
- sigemptyset(&sa.sa_mask);
- sa.sa_flags = 0;
- sigaction(SIGXCPU,&sa,NULL);
- pthread_kill(pthread_self(),SIGXCPU);
- }
-}
-
static __attribute__((constructor)) void __init_posix_interface(void)
{
struct sigaction sa;
-xnfeatinfo_t finfo;
int muxid;
+
+__pse51_muxid = xeno_user_skin_init(PSE51_SKIN_MAGIC, "POSIX",
"xeno_posix");
-muxid = XENOMAI_SYSBIND(PSE51_SKIN_MAGIC,
- XENOMAI_FEAT_DEP,
- XENOMAI_ABI_REV,
- &finfo);
-switch (muxid)
- {
- case -EINVAL:
-
- fprintf(stderr,"Xenomai: incompatible feature set\n");
- fprintf(stderr,"(required=\"%s\", present=\"%s\",
missing=\"%s\").\n",
- finfo.feat_man_s,finfo.feat_all_s,finfo.feat_mis_s);
- exit(1);
-
- case -ENOEXEC:
-
- fprintf(stderr,"Xenomai: incompatible ABI revision level\n");
- fprintf(stde
Re: [Xenomai-core] [PATCH] let skins select nucleus features
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi, this patch aims at avoiding to select unneeded nucleus features if no user is requiring it in the skins. Particularly, it addresses the nucleus registry and the pipes. I have spent no effort on 2.4 yet as I first want to wait for comments. Furthermore, 2.4. is lacking "select", so the feature selection has to remain manually there anyway. Looks good. Merged, thanks. In the same sense, but not that comfortable, here is the a 2.4 variant of the patch. I don't agree with the logic of this patch. All user-space enabled skins may also run in pure kernel-space in non pervasive mode. A core dependency exists from CONFIG_XENO_OPT_REGISTRY on CONFIG_XENO_OPT_PERVASIVE, and it should be defined explicitely. In any case, maybe it's not worth trying to be too smart with the 2.4 configuration system when it comes to dealing with features inter-dependencies, since we really miss the proper support to do that. Sorry, doesn't parse for me yet. You that when CONFIG_XENO_OPT_PERVASIVE is enabled CONFIG_XENO_OPT_REGISTRY is required (which was not correct, see POSIX skin)? The POSIX skin is an exception, since it implemented its own registry support before the native registry was moved as a generic nucleus feature; at some point in time, the POSIX registry should be rebased on the nucleus support. We must now consider that having CONFIG_XENO_OPT_PERVASIVE set requires CONFIG_XENO_OPT_REGISTRY to be set too. OTOH, you can have CONFIG_XENO_OPT_REGISTRY set without CONFIG_XENO_OPT_PERVASIVE, if you want to run skins in kernel space only, whilst still providing registry support for inter-modules requests. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] let skins select nucleus features
Philippe Gerum wrote: > Jan Kiszka wrote: >> Philippe Gerum wrote: >> >>> Jan Kiszka wrote: >>> Hi, this patch aims at avoiding to select unneeded nucleus features if no user is requiring it in the skins. Particularly, it addresses the nucleus registry and the pipes. I have spent no effort on 2.4 yet as I first want to wait for comments. Furthermore, 2.4. is lacking "select", so the feature selection has to remain manually there anyway. >>> >>> Looks good. Merged, thanks. >>> >> >> >> In the same sense, but not that comfortable, here is the a 2.4 variant >> of the patch. > > I don't agree with the logic of this patch. All user-space enabled skins > may also run in pure kernel-space in non pervasive mode. A core > dependency exists from CONFIG_XENO_OPT_REGISTRY on > CONFIG_XENO_OPT_PERVASIVE, and it should be defined explicitely. In any > case, maybe it's not worth trying to be too smart with the 2.4 > configuration system when it comes to dealing with features > inter-dependencies, since we really miss the proper support to do that. > Sorry, doesn't parse for me yet. You that when CONFIG_XENO_OPT_PERVASIVE is enabled CONFIG_XENO_OPT_REGISTRY is required (which was not correct, see POSIX skin)? 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] [PATCH] let skins select nucleus features
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi, this patch aims at avoiding to select unneeded nucleus features if no user is requiring it in the skins. Particularly, it addresses the nucleus registry and the pipes. I have spent no effort on 2.4 yet as I first want to wait for comments. Furthermore, 2.4. is lacking "select", so the feature selection has to remain manually there anyway. Looks good. Merged, thanks. In the same sense, but not that comfortable, here is the a 2.4 variant of the patch. I don't agree with the logic of this patch. All user-space enabled skins may also run in pure kernel-space in non pervasive mode. A core dependency exists from CONFIG_XENO_OPT_REGISTRY on CONFIG_XENO_OPT_PERVASIVE, and it should be defined explicitely. In any case, maybe it's not worth trying to be too smart with the 2.4 configuration system when it comes to dealing with features inter-dependencies, since we really miss the proper support to do that. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
