Niklaus Giger wrote:

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 <name>  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 <name>, 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.

( back in Nov, I set up a gmail acct, and tried to fetch mail from it with a script.
gmail wants TLS security, and didnt let me in, so I punted/shelved this. )
Niklaus' message brought me back on this topic.

So Im considering poaching code from LiveCD that does url-encoding,
or just using curl to post to some file-upload url.
How would you do this if you only had busybox ??

Anyway, both email and url-upload are suboptimal wrt spam,
latter is also a server support issue.

(May be patch xeno-config to emit also the revision of the svn checkout?)

perhaps as a 4th number on the version, that way xeno-config can stay as is.

[EMAIL PROTECTED] bin]# ./xeno-config --version
Id like instead:

This seems better than pokinh around a filesystem, looking for the xenomai svn
(which may be on the build-host, not the run-host)

b) Setup an e-mail account [EMAIL PROTECTED]

getting messages thru the anti-spam filters is the issue here,

c) Add a archiver which generates daily a gzipped tar file of all messages ever sent to [EMAIL PROTECTED] (e.g. of its mbox). Make it available somewhere on the internet.
or a daily/weekly digest/tarball

d) Write a converter the raw messages into more suitable representation, eg. a MySQL-DB, a spreadsheet format. Extract the raw message and kernel config and store the publicly accessible on the internet. The DB/spreadsheet will contain pointers (URLs) to the raw message/kernel config.
certainly not a bad idea. Will simplify collection/selection of data-sets for various things, esp more complicated selections (with ands, ors, etc).
e) Write viewers which present interesting statistics. E.g. X/HTML pages to present a ordered (by architecture, board, version, etc) view of the available results.

Ive done minimal dabbling with gnuplot, R, both have possibilities.

With gnuplot, I tried graphing the RTD data, failed cuz theres no time column
(couldnt figure out how to create/infer a synthetic 'index' column).
It has some capability to select data out of files using awk,etc subcommands, but for complicated data files like xeno-test outputs (multiple sections, different formats),
I think it (the selection, reformating capabilities) might be over-matched.

R can apparently manage complex data-sets, and select data out of them.
It sounds tremendously capable (after the learning curve)
That said, Ive not grokked its use yet.

Xenomai-core mailing list

Reply via email to