* Re: [Xenomai-help] question about task migrating to primary mode
2006-01-11 21:56 [Xenomai-help] question about task migrating to primary mode Stefan Kisdaroczi
@ 2006-01-11 23:03 ` Jan Kiszka
0 siblings, 0 replies; 2+ messages in thread
From: Jan Kiszka @ 2006-01-11 23:03 UTC (permalink / raw)
To: Stefan Kisdaroczi; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 3501 bytes --]
Stefan Kisdaroczi wrote:
> Hi,
>
> I have a question about migrating a task to primary mode.
>
> Following code is from Captain's "Hard Real Time Serial Port (RS232)
> Example" [1]:
> ...
> while (1) {
> /* switch to primary mode */
> ret = rt_task_set_mode(0, T_PRIMARY, NULL);
> if (ret) {
> printf(WTASK_PREFIX "error while rt_task_set_mode, code %d\n",ret);
> goto exit_write_task;
> }
> ret = rt_task_wait_period();
> if (ret) {
> printf(WTASK_PREFIX "error while rt_task_wait_period, code %d\n",ret);
> goto exit_write_task;
> }
> sz = sizeof(buf);
> written = rt_dev_write(my_fd, &buf, sizeof(buf));
> printf(WTASK_PREFIX "rt_dev_write written=%d sz=%d\n", written, sz);
> if (written != sz ) {
> if (written < 0 ) {
> printf(WTASK_PREFIX "error while rt_dev_write, code %d\n",written);
> } else {
> printf(WTASK_PREFIX "only %d / %d byte transmitted\n",written, sz);
> }
> goto exit_write_task;
> }
> }
> ...
>
> Is the rt_task_set_mode(0, T_PRIMARY, NULL) call really necessary?
Damn, this is the old-style RTDM 16550A serial driver example code which
found it way here. I think that even the original code on my side is
still outdated.
No, this is no longer needed here. All native functions automatically
switch to the right mode on invocation. The former issue was with the
RTDM API (rt_dev_xxx) which required the right mode on entry in case the
driver in the background only supports a specific one (e.g. if there is
no blocking read for a specific device from secondary mode - rather usual).
Things evolved, this restriction was removed in Xenomai, the original
demo got reordered, but the mode switches remained. We need to clean
this up.
> I seems the call is used here to migrate to task back to primary mode if a
> error-"printf" switched the task to secondary mode.
>
> From the "Native API Tour"-Document, page 8 [2]:
> "By convention, all Xenomai services which
> might block the caller cause such transition when necessary; in other words, real
> time tasks blocked on Xenomai resources are always aslept in primary mode."
>
> As the next call is rt_task_wait_period which should block, i think its not
> necessary to force a migration "by hand" to primary mode. Is this true ?
>
Yes, definitly. Even with the old RTDM code this would have been redundant.
You only need explicit mode switches with RTDM device in case there are
handlers both for the primary and secondary case and you want to pick a
specific one. Corner cases, but not purely theoretical:
Creating RTnet UDP sockets e.g. can happen in both contexts. In primary
mode, the required buffers are taken from a limited global pool of
pre-allocated buffers. In secondary mode, these buffers are allocated
classically, using Linux kernel services (kmem_cache_alloc). So, when
you are already in a real-time task and want to call rt_dev_socket but
you do have some time, you should explicitely switch to secondary mode
and then issue the request.
That's the idea behind it, and I hope it became a bit clearer than it is
now with existing code and docs.
> Thank you Hannes for all your examples.
>
> Thanks
> kisda
>
> [1] http://www.captain.at/xenomai-serial-port-example.php
> [2]
> http://snail.fsffrance.org/www.xenomai.org/documentation/branches/v2.0.x/pdf/Native-API-Tour.pdf
>
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread