On 01/12/2012 02:36 PM, Jan-Erik Lange wrote:
>> Date: Wed, 11 Jan 2012 20:03:25 +0100 From:
>> gilles.chanteperd...@xenomai.org To: jan0...@hotmail.de CC:
>> xenomai-core@gna.org Subject: Re: [Xenomai-core] Question about
>> context switching
>> On 01/11/2012 07:12 PM, Jan-Erik Lange wrote:
>>> Hello,
>>> I have a question about the context switching:
>>> Unless that there a rtdm_copy_to_user() available in the rtdm
>>> API. Would cause the function copy_to_user() in an xenomai kernel
>>> based rt task a switch into the secondary domain? Because
>>> copy_to_user() not actually a syscall right?
>> Absolutely no function in kernel-space causes an automatic switch
>> to secondary mode. As Philippe answered to the very first mail you
>> posted to this list, the only events which cause a switch to
>> secondary mode are:
>> - invoking a regular linux syscall - receiving a linux signal (e.g.
>> kill(2) and GDB) - causing a CPU trap (e.g. invalid memory access),
>> hitting a breakpoint (e.g. GDB)
>> All these events only happen for threads in user-space.
> Sorry I'm new in Xenomai.
> But is it generaly possible that the xenomai kernel-space task can
> interact with a common Linux task over this way? I mean is it
> possible to get data with the standard copy_to_user()-function from
> the Xenomai kernel-space into the Linux user space? Aren't the adress
> spaces strictly seperated and you have to need the rt-pipe service to
> interact between the xenomai kernel space and the linux userspace?

drivers should use rtdm_copy_to_user. As most linux kernel services,
copy_to_user/copy_from_user may not be safe to be used in primary mode
(depending on the architecture). A xenomai kernel-space task has no
user-space mapping, so it has no reason to use these services.

Whether the address space are strictly separated depend on the
architecture and implementation of linux on that archietcture. On some
architectures (think uclinux for instance), the user-space/kernel-space
division is simply the division between the addresses below 0xC0000000
and the adresses above.


Xenomai-core mailing list

Reply via email to