* Mixing cobalt and alchemy?
@ 2019-03-06 9:59 Richard Weinberger
2019-03-06 17:25 ` Jan Kiszka
0 siblings, 1 reply; 3+ messages in thread
From: Richard Weinberger @ 2019-03-06 9:59 UTC (permalink / raw)
To: xenomai
Hi!
I have a Xenomai 2.6 application which makes heavy usage of
rt_dev_ioctl() and shadow threads
with rt_task_shadow().
If I understand the new Xenomai 3 API correctly, rt_dev_ioctl() for
userspace is gone and the cobalt wrappers should be used such that
plain ioctl() calls will be routed through libcobalt.
What I don't fully understand is how to mix these with the alchemy
skin such that the application can use rt_task_shadow() and friends
because the cobalt wrapper also wraps pthread_create().
The application simply does not fully fit in either cobalt nor alchemy skins.
Is it legal to modify lib/cobalt/cobalt.wrappers to wrap only read/close/ioctl?
Or can I directly issue cobalt syscalls from the application?
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Mixing cobalt and alchemy?
2019-03-06 9:59 Mixing cobalt and alchemy? Richard Weinberger
@ 2019-03-06 17:25 ` Jan Kiszka
2019-03-06 20:20 ` Richard Weinberger
0 siblings, 1 reply; 3+ messages in thread
From: Jan Kiszka @ 2019-03-06 17:25 UTC (permalink / raw)
To: Richard Weinberger, xenomai
On 06.03.19 10:59, Richard Weinberger via Xenomai wrote:
> Hi!
>
> I have a Xenomai 2.6 application which makes heavy usage of
> rt_dev_ioctl() and shadow threads
> with rt_task_shadow().
>
> If I understand the new Xenomai 3 API correctly, rt_dev_ioctl() for
> userspace is gone and the cobalt wrappers should be used such that
> plain ioctl() calls will be routed through libcobalt.
> What I don't fully understand is how to mix these with the alchemy
> skin such that the application can use rt_task_shadow() and friends
> because the cobalt wrapper also wraps pthread_create().
> The application simply does not fully fit in either cobalt nor alchemy skins.
>
> Is it legal to modify lib/cobalt/cobalt.wrappers to wrap only read/close/ioctl?
> Or can I directly issue cobalt syscalls from the application?
>
You can do __RT(ioctl(...)), that's also what the transition kit (trank) does to
provide rt_dev_ioctl.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Mixing cobalt and alchemy?
2019-03-06 17:25 ` Jan Kiszka
@ 2019-03-06 20:20 ` Richard Weinberger
0 siblings, 0 replies; 3+ messages in thread
From: Richard Weinberger @ 2019-03-06 20:20 UTC (permalink / raw)
To: Jan Kiszka, xenomai
Am Mittwoch, 6. März 2019, 18:25:56 CET schrieb Jan Kiszka:
> On 06.03.19 10:59, Richard Weinberger via Xenomai wrote:
> > Hi!
> >
> > I have a Xenomai 2.6 application which makes heavy usage of
> > rt_dev_ioctl() and shadow threads
> > with rt_task_shadow().
> >
> > If I understand the new Xenomai 3 API correctly, rt_dev_ioctl() for
> > userspace is gone and the cobalt wrappers should be used such that
> > plain ioctl() calls will be routed through libcobalt.
> > What I don't fully understand is how to mix these with the alchemy
> > skin such that the application can use rt_task_shadow() and friends
> > because the cobalt wrapper also wraps pthread_create().
> > The application simply does not fully fit in either cobalt nor alchemy skins.
> >
> > Is it legal to modify lib/cobalt/cobalt.wrappers to wrap only read/close/ioctl?
> > Or can I directly issue cobalt syscalls from the application?
> >
>
> You can do __RT(ioctl(...)), that's also what the transition kit (trank) does to
> provide rt_dev_ioctl.
Good to know!
Then I'll use alchemy and the __RT() wrappers.
Thanks,
//richard
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-03-06 20:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-06 9:59 Mixing cobalt and alchemy? Richard Weinberger
2019-03-06 17:25 ` Jan Kiszka
2019-03-06 20:20 ` Richard Weinberger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.