Re: [Xenomai-core] ns vs. tsc as internal timer base
Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Redone the check here on a Centrino 1.6Mhz, and still have roughly x20 improvement (a bit better actually). I'm using Debian/sarge gcc 3.3.5. I think I remember that Pentium M has a much shorter mull instruction than other processors of the family. That would explain. Anyway, as John Stulz put it: math is hard, lets go shopping! Heh. Appropriate that his name (Stultz) comes up here, as his generic-time (GTOD) patchset looks headed for 2.6.18, bringing with it a full re-working of linux timers / timeofday. IN this new world, time is kept on free-running counters. Ive been running this patchset on my soekris for some time, since GTOD detects that the TSC counts slowly, calls it insane, and does timing with the PIT. With GTOD, writing a new clocksource driver is easy, enough so I could do it. My clocksource patch uses the 27 mhz timer on the Geode CPU. Once the TSC is de-rated, mine becomes the best clocksource, and GTOD switches to it. All of which is to say .. new mainline code is coming, should this current rework notion wait, given that its will all need revisited again later ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] ns vs. tsc as internal timer base
Philippe Gerum wrote: Jim Cromie wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Redone the check here on a Centrino 1.6Mhz, and still have roughly x20 improvement (a bit better actually). I'm using Debian/sarge gcc 3.3.5. I think I remember that Pentium M has a much shorter mull instruction than other processors of the family. That would explain. Anyway, as John Stulz put it: math is hard, lets go shopping! Heh. Appropriate that his name (Stultz) comes up here, as his generic-time (GTOD) patchset looks headed for 2.6.18, bringing with it a full re-working of linux timers / timeofday. IN this new world, time is kept on free-running counters. Ive been running this patchset on my soekris for some time, since GTOD detects that the TSC counts slowly, calls it insane, and does timing with the PIT. With GTOD, writing a new clocksource driver is easy, enough so I could do it. My clocksource patch uses the 27 mhz timer on the Geode CPU. Once the TSC is de-rated, mine becomes the best clocksource, and GTOD switches to it. All of which is to say .. new mainline code is coming, should this current rework notion wait, given that its will all need revisited again later Clearly yes, since this is going to impact Adeos too. GTOD is going to fiddle with the PIT channels in a way Adeos needs to be aware of, in order for the client RTOS to reuse such timer. Added to the flow of other core changes planned for 2.6.18, this is likely going to be funky. Find wall. Beat head against same. May not be required: the GTOD and clocksource abstractions could provide a clean way to register some virtual, Adeos- or RTOS-provided clock with Linux. And that clock may even lose ticks without Linux losing its system time! So far for the theory, practice may still require walls... 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] /proc/xenomai broken...
Gilles Chanteperdrix wrote: When using xenomai trunk, it appears that /proc/xenomai is no longer a directory but a file returning 0. Check your recent changes for giving the nucleus a regular syscall table. I would not be surprised of some side-effect there. i.e. something going on with the xnptree_t descriptor? -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] /proc/xenomai broken...
Philippe Gerum wrote: Gilles Chanteperdrix wrote: When using xenomai trunk, it appears that /proc/xenomai is no longer a directory but a file returning 0. Check your recent changes for giving the nucleus a regular syscall table. I would not be surprised of some side-effect there. i.e. something going on with the xnptree_t descriptor? That is exactly the source of the problem, since iface_proc_root in nucleus/module.c has not yet been set, the proc entry for the nucleus interface get created directly under /proc instead of /proc/xenomai/interfaces. Do we need a /proc entry for this interface ? -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] /proc/xenomai broken...
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: When using xenomai trunk, it appears that /proc/xenomai is no longer a directory but a file returning 0. Check your recent changes for giving the nucleus a regular syscall table. I would not be surprised of some side-effect there. i.e. something going on with the xnptree_t descriptor? That is exactly the source of the problem, since iface_proc_root in nucleus/module.c has not yet been set, the proc entry for the nucleus interface get created directly under /proc instead of /proc/xenomai/interfaces. Do we need a /proc entry for this interface ? Not really. This would only give the exact number of processes bound to the nucleus, whilst major interface counters already display the number of bound threads. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] /proc/xenomai broken...
Philippe Gerum wrote: This said, the other option would be to move the call to xnshadow_mount() from the xnarch_init() to __xeno_sys_init() in a kernel-only section, just after xnpod_init_proc() has returned. There is nothing done in the arch-layer for any architecture that would prevent this. Btw, I'd say that core would be better than xenomai to name this internal interface. Ok for renaming. But no thread is ever bound to this interface, so the count is always 0. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Some new test cases for the vxWorks skin
Am Mittwoch, 14. Juni 2006 15:23 schrieb Gilles Chanteperdrix: Niklaus Giger wrote: Is it okay to submit such a patch, which mixes a different test cases or shall I submit the patches in smaller pieces? Should the test that I put into the procedure msgDuringInt better be inlined? Or should I add a new file for these tests? I think it is a good idea to add some more tests to the message queues tests. I also agree with the idea of documenting the differences instead of being bug compatible. However, I would apply a few cosmetic changes to the patch before including it. Comments follow, please tell me if you agree with these changes. -TEST_ASSERT(taskIdVerify(0) == ERROR errno == S_objLib_OBJ_ID_ERROR); +errno = 0; +TEST_ASSERT(taskIdVerify(0) == ERROR errno == 0); This is weird, it means that taskIdVerify does not set errno when passed a null argument, but returns ERROR. Anyway, and this goes for all other checks, I do not like errno = 0. If errno is not set, let us not check it. Okay. That's probably safer. +errno = 0; +TEST_ASSERT(taskIdVerify(malloc(20)) == ERROR errno == S_objLib_OBJ_ID_ERROR); You should memset the new malloced block (or use calloc instead of malloc), in order to be sure that it is invalid. And free it after use. I didn't bother about the memory leak, as the testsuite was not meant to live a long time. And it kept the changes smaller. But I would never accept this kind of code in a production system. So we better clean it up. +TEST_ASSERT_OK(rc); +TEST_ASSERT(errno == 0); There is no guarantee that the syscalls will not set errno when returning OK. I would remove every TEST_ASSERT(errno == 0). Agreed. +TEST_ASSERT(rc == ERROR); +TEST_ASSERT(errno == S_msgQLib_NON_ZERO_TIMEOUT_AT_INT_LEVEL); Here, and in several other places, I would use only one assert, as it is done in other tests. Fine for me. Just while developing test cases it was more convenient to know exactly which condition lead to an error. +errno = 0; qid = msgQCreate(NMESSAGES,sizeof(int),0x); -TEST_ASSERT(qid == 0 errno == S_msgQLib_INVALID_QUEUE_TYPE); +TEST_ASSERT(qid != 0 errno == 0); +if (qid) msgQDelete(qid); Here, it appears that vxworks and xenomai vxworks skin are incompatible, changing the test code will make the test fail for xenomai. Would not it be a better idea to document this difference ? After all, users code is supposed to never use erroneous arguments, and if it does, it is better to learn it when porting code to xenomai than to keep ignoring it silently. Agreed. Do you agree with the following sentence for vxworks-skin.txt? Passing a argument to options with non defined bits for msgQCreate will return 0 under the xenomai skin. VxWorks returns a valid msqId. -rc = msgQSend(qid,(char *)message_list[0],0,WAIT_FOREVER,MSG_PRI_NORMAL); +errno = 0; +rc = msgQSend(qid,(char *)message_list[0],2*message_list[0], WAIT_FOREVER,MSG_PRI_NORMAL); TEST_ASSERT(rc == ERROR errno == S_msgQLib_INVALID_MSG_LENGTH); Accepting null length messages may be a feature, does a receiver receive the null length message with vxworks ? I will check and give you an answer about this later (probably before Friday evening). -rc = msgQReceive(qid,(char *)msg,0,NO_WAIT); -TEST_ASSERT(rc == ERROR errno == S_msgQLib_INVALID_MSG_LENGTH); Null length message again, does this work with the real vxworks ? Same here. +rc = msgQNumMsgs(qid); You do not use this value. Missing TEST_ASSERT ? No. Bad cleanup before sending. I had some redundant tests after this position. Just kill this line. You may either check in a modified version of this patch or wait till I send you one which incorporates your suggestions. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] /proc/xenomai broken...
Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: This said, the other option would be to move the call to xnshadow_mount() from the xnarch_init() to __xeno_sys_init() in a kernel-only section, just after xnpod_init_proc() has returned. There is nothing done in the arch-layer for any architecture that would prevent this. Btw, I'd say that core would be better than xenomai to name this internal interface. Ok for renaming. But no thread is ever bound to this interface, so the count is always 0. xnshadow_sys_bind()/unbind() would be the proper place to track a cumulated count. I'm not sure that this is going to be that useful now, but at some point in the future, maybe we could get a benefit from having a uniform way of talking to any interface using procfs, including to the core one. Commit 1205 does what you suggested. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Porting xeno-{info|load|test} to a busybox system
Philippe Gerum wrote:
Jan Kiszka wrote:
Jim Cromie wrote:
Niklaus Giger wrote:
Am Freitag, 26. Mai 2006 15:52 schrieb Jan Kiszka:
Niklaus Giger wrote:...
If anybody has a working target with a Xenomai + BusyBox
combination and
would be willing to test drive my changes, I would appreciate a
feedback
enormously.
I hope this isnt waiting on my 'approval'.
I think its a great idea, and has been on my (way too stagnant) list
for
a while.
Your work has at least urged me to install busybox on my xeno-box. ;-)
My only concern is whether we've sufficiently distinguished the issues:
1 - ash vs bash
Its not entirely clear to me which flavors of sh busybox has:
ash / dash / not-bash
I gather u worked with ash, and it seems most valuable sh features
work there just fine ( shell-functions, even 'job-control' of a
fashion)
2 - busybox 'executables' only
I coded in a lot of 'full linux' gimme's, like zgrep, script, etc.
Niklaus has repaired many of these. I think a more thorough cleanup is
possible,
esp if things like 'script' are jettisoned for a simpler
shell-functions
or helper scripts.
This all implies a re-write, which is on my list...
(esp the job-control testing and repair)
Just stumbled over this again while cleaning up my mailbox. What's the
status? Waiting for improvements, or waiting for /someone/ to type svn
ci (and improve the topics above later)?
It's queued for now, waiting for a combined ack to merge the current
patch from JimC and Niklaus.
AFAIC, Niklaus is in the lead atm.
Im trying to get some GPIO stuff ready for -mm.
( I'll post separately on this ..)
I ran his changes once, I dont even remember what it did.
(which suggests that it didnt explode ;-)
IMO, take it when Niklaus says its ready.
I have some local changes here, but Ill work them into shape after
Niks changes go in (maybe much later :-(
We should probly confer on the longer-term issues too.
- a rational option-pass-thru, or a means to avoid doing so.
if we assume OPTS_${TOOLNAME} exists, we could
grab it out of env, and pass it into the benchmark prog.
- would require no prog mods, but gives us complete control
- would play nicer than assuming -T secs has meaning for all progs.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: GPIO and RTDM
hi Jan, everyone, Separately.. In this GPIO work, I concluded that I needed to add a sysfs interface to my driver, in order to better fit with LKML expectations. Sysfs GPIO representation of Hardware (v0.2) (v0.1 went to lm-sensors ML, v0.2 to kernelnewbies ML) We need a standard rep for GPIO in sysfs, so heres a strawman. Strike a match, lets have a campfire! Essentially, this seeks to describes the directory of 'device-attribute-files' that are populated by a driver, forex: soekris:/sys/bus/platform/devices/pc8736x_gpio.0# ls bit_0.0_debounced bit_1.2_totem bit_2.5_pullup_enabled bit_0.0_locked bit_1.3_debounced bit_2.5_totem bit_0.0_output_enabled bit_1.3_locked bit_2.6_debounced bit_0.0_pullup_enabled bit_1.3_output_enabled bit_2.6_locked bit_0.0_totem bit_1.3_pullup_enabled bit_2.6_output_enabled bit_0.1_debounced bit_1.3_totem bit_2.6_pullup_enabled bit_0.1_locked bit_1.4_debounced bit_2.6_totem bit_0.1_output_enabled bit_1.4_locked bit_2.7_debounced bit_0.1_pullup_enabled bit_1.4_output_enabled bit_2.7_locked bit_0.1_totem bit_1.4_pullup_enabled bit_2.7_output_enabled bit_0.2_debounced bit_1.4_totem bit_2.7_pullup_enabled bit_0.2_locked bit_1.5_debounced bit_2.7_totem (Ive now seen *1.5* GPIO architectures, so please test this writeup mentally against your GPIO experience). Basic Naming Convention. I havent seen this stated anywhere at an 'all-of-sysfs-level' and I think its true/valid (and so test this here - CMIIW). If Im correct, please suggest the optimal Doc/* file to contain this info. All device-attr-files are named as prefix_id_suffix in LM-sensors: - prefixsensor-type: in(volts), temp, fan, etc.. - idusually single integer - suffixthe sensor attribute in question. GPIO Prefix Names. Basically, GPIO hardware design appears to have 2 top-level factors; pin features, and pin-to-port grouping. These get mapped into filename prefixes suffixes. All GPIOs (Ive seen) are organized as 1-4 ports of 8-32 bits. The bits' attributes are addressable individually, but also accessible as a group via the port_* files. If you change a bit-attribute, that change will also exhibit in the port attr too. IOW, we have bit_*, port_*. They are interconnected at the hardware level, and (I think) there is no need for inter-locks between the sysfs handlers for bit_ and port_ (except for shadow regs, but I digress) GPIO Architectures GPIO pins have lots of hardware / architectural / naming-convention variations, which makes this harder. Drivers should create sysfs 'files' only for attributes that are pertinent for the hardware being driven. Ths way, the absense or presense of files communicates functionality, as does their readonlyness. (these 'behaviors' may be different than lm-sensors) IOW: if a pin is input only, it shouldnt have an _output_enabled attr. if a pin is output only, it shouldnt have an _output_enabled attr. The reason for the 2nd rule: the presense of _output_enabled suggests that it can be changed. OTOH, a readonly _output_enabled would yield the same, but not as visibly (ls vs ls -l) So, Im somewhat ambivalent here, looking for input User-Space Following LM-sensors approach, a user-side library would add the niceties: - provide any equivalences needed by users ie bit_x_tristate = ! bit_x_output_enabled. - sub-port allocation and management. support for 3+3+2 bit sub-ports on an 8 bit port would be nice I suspect that a sophisticated programmer would be able to add a sub-port allocation facility w/in the driver. I cannot, GPIO Pin Features As alluded, pin features are represented as _suffixes 1st: there are several alternative naming schemes: - name-as-verb _output_enable (conveys an 'action') - name-as-state _output_enabled (conveys a 'current state') - feature-name _output (a knob to turn) - feature+state _output+(currval) (currval in name is bad idea) 1,2 are quite close. Ive done 2. FWIW, heres the pin attributes of my GPIOs, as expressed in the syslog by the legacy drivers: (these are [15510.384000] pc8736x_gpio.0: io16: 0x0004 TS OD PUE EDGE LO io:0/1 [15510.564000] pc8736x_gpio.0: io17: 0x0004 TS OD PUE EDGE LO io:1/1 [15510.744000] pc8736x_gpio.0: io18: 0x0004 TS OD PUE EDGE LO io:1/1 [15510.928000] pc8736x_gpio.0: io19: 0x0004 TS OD PUE EDGE LO io:1/1 # whether output-drive is on/off _output_enable # 1 or 0, _tristate # ! _output_enable, logically linked. Now, theres no need to have both of these; if there were, they would have to be intrinsically linked (logically opposite values). IOW, drivers should name the file as one of possible states of the feature, which ever best describes it, and not expose it 2x. To the extent
