[Xenomai-help] enable/disable all interrupts from user space

[Xenomai-help] enable/disable all interrupts from user space

[Jeff Weber]

How do I enable/disable all interrupts (Linux and Xenomai) from user space?  
(native skin preferred)

	thanks,
	Jeff

Re: [Xenomai-help] enable/disable all interrupts from user space

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

Jeff Weber wrote:
> How do I enable/disable all interrupts (Linux and Xenomai) from user space?  
> (native skin preferred)

For x86:

iopl(3);
__asm__ __volatile__("cli/sti");

Ugly hack, typical a sign that something should be moved somewhere
else... (there are a few exceptions, though)

We once had some discussion if we shouldn't export domain stalling
features to user-space in order to support things like X-servers that
currently come with such code, toasting any RT kernel. May come one day,
but this will be primarily for legacy non-RT code.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] enable/disable all interrupts from user space

[Jeff Weber]

Thanks Jan.

Another thought: is there a direct Adeos  call to enable/disable all 
interrupts, with nesting from user space?

I'm porting some legacy RTAI code to the Xenomai native skin.  The RTAI code 
has rtai_save_flags_and_cli()/rtai_restore_flags() for enabling/disabling all 
interrupts  direct from user space, with capability to handle nested calls.  

Yes, please add this to the native skin "wish list", along with a nesting 
capability.

        thanks,
        Jeff

On Friday 27 October 2006 08:32, Jan Kiszka wrote:
> Jeff Weber wrote:
> > How do I enable/disable all interrupts (Linux and Xenomai) from user
>
> space?
>
> > (native skin preferred)
>
> For x86:
>
> iopl(3);
> __asm__ __volatile__("cli/sti");
>
> Ugly hack, typical a sign that something should be moved somewhere
> else... (there are a few exceptions, though)

-- 
Jeff Weber
American Superconductor Corp.

Re: [Xenomai-help] enable/disable all interrupts from user space

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

Jeff Weber wrote:
> Thanks Jan.
> 
> Another thought: is there a direct Adeos  call to enable/disable all 
> interrupts, with nesting from user space?

Not yet, but that would be one option for the scenario I described.

> 
> I'm porting some legacy RTAI code to the Xenomai native skin.  The RTAI code 
> has rtai_save_flags_and_cli()/rtai_restore_flags() for enabling/disabling all 
> interrupts  direct from user space, with capability to handle nested calls.  

You can use even more assembly magic in user-space for now:

#define local_irq_save(x) \
	__asm__ __volatile__("pushfl; popl %0; cli":"=g" (x)::"memory")

#define local_irq_restore(x) \
	__asm__ __volatile__("pushl %0; popfl": :"g" (x):"memory", "cc")

Hope your RTAI code takes care of SMP as well (or excludes the execution
on such boxes).

> 
> Yes, please add this to the native skin "wish list", along with a nesting 
> capability.

Won't you? => http://www.xenomai.org/wiki/index.php/TaskMarket

Ideas and requests on the mailing list are starting become volatile with
the increasing traffic we see...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] enable/disable all interrupts from user space

[Philippe Gerum]

On Fri, 2006-10-27 at 15:32 +0200, Jan Kiszka wrote:
> Jeff Weber wrote:
> > How do I enable/disable all interrupts (Linux and Xenomai) from user space?  
> > (native skin preferred)
> 
> For x86:
> 
> iopl(3);
> __asm__ __volatile__("cli/sti");
> 

Gasp...

> Ugly hack, typical a sign that something should be moved somewhere
> else... (there are a few exceptions, though)
> 
> We once had some discussion if we shouldn't export domain stalling
> features to user-space in order to support things like X-servers that
> currently come with such code, toasting any RT kernel. May come one day,
> but this will be primarily for legacy non-RT code.

Providing "cli" emulation to X-Servers would only make sense in order to
stall the Linux domain; controlling the interrupt shield dynamically
using the T_SHIELD bit would allow that already. If I understand
correctly, we are talking about stalling the Xenomai domain too, and
this is a completely different story. The day we would provide such
"feature" as an official API, we would trigger tons of misuses of this
hack, a bit like we have now with the T_PRIMARY bit, a number of people
sprinkle over their code to control the task exec mode, which is most of
the time utterly sub-optimal, and automatically handled by the nucleus
already. IOW, I'm not convinced at all that adding such API would be the
right thing to do.

For the time being, it should be possible to write a simple kernel
module using either the native or RTDM API from kernel space, which
would handle such requests from user-space. For instance, one could use
rt_task_notify() from user-space to signal a helper task in a kernel
module that carries out the job, depending on the signal received. The
same goes for a trivial RTDM driver only implementing the ioctl()
support for the same purpose.

> 
> Jan
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] enable/disable all interrupts from user space

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2620 bytes --]

Philippe Gerum wrote:
> On Fri, 2006-10-27 at 15:32 +0200, Jan Kiszka wrote:
>> Jeff Weber wrote:
>>> How do I enable/disable all interrupts (Linux and Xenomai) from user space?  
>>> (native skin preferred)
>> For x86:
>>
>> iopl(3);
>> __asm__ __volatile__("cli/sti");
>>
> 
> Gasp...
> 
>> Ugly hack, typical a sign that something should be moved somewhere
>> else... (there are a few exceptions, though)
>>
>> We once had some discussion if we shouldn't export domain stalling
>> features to user-space in order to support things like X-servers that
>> currently come with such code, toasting any RT kernel. May come one day,
>> but this will be primarily for legacy non-RT code.
> 
> Providing "cli" emulation to X-Servers would only make sense in order to
> stall the Linux domain; controlling the interrupt shield dynamically
> using the T_SHIELD bit would allow that already.

As far as I understood, the I-shield doesn't come for free. So, having
at least an API to stall the root domain from user-space should be cheaper.

> If I understand
> correctly, we are talking about stalling the Xenomai domain too, and
> this is a completely different story. The day we would provide such
> "feature" as an official API, we would trigger tons of misuses of this
> hack, a bit like we have now with the T_PRIMARY bit, a number of people
> sprinkle over their code to control the task exec mode, which is most of
> the time utterly sub-optimal, and automatically handled by the nucleus
> already. IOW, I'm not convinced at all that adding such API would be the
> right thing to do.

When it comes to *emulate* hacky RTAI APIs - I would not immediately
refrain from considering this. But I agree that this can open Pandora's
box, and having it in the native skip could mess up a lot. Unless we
will see a widely compatible RTAI user-space skin one day, it's probably
better to keep status quo /wrt to non-root domain stalling.

> 
> For the time being, it should be possible to write a simple kernel
> module using either the native or RTDM API from kernel space, which
> would handle such requests from user-space. For instance, one could use
> rt_task_notify() from user-space to signal a helper task in a kernel
> module that carries out the job, depending on the signal received. The
> same goes for a trivial RTDM driver only implementing the ioctl()
> support for the same purpose.

That still remains a hack, though now platform independent :). I would
simply use the assembly + a big fat warning sign saying "This code needs
serious refactoring!"

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] enable/disable all interrupts from user space

[Philippe Gerum]

On Fri, 2006-10-27 at 23:31 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Fri, 2006-10-27 at 15:32 +0200, Jan Kiszka wrote:
> >> Jeff Weber wrote:
> >>> How do I enable/disable all interrupts (Linux and Xenomai) from user space?  
> >>> (native skin preferred)
> >> For x86:
> >>
> >> iopl(3);
> >> __asm__ __volatile__("cli/sti");
> >>
> > 
> > Gasp...
> > 
> >> Ugly hack, typical a sign that something should be moved somewhere
> >> else... (there are a few exceptions, though)
> >>
> >> We once had some discussion if we shouldn't export domain stalling
> >> features to user-space in order to support things like X-servers that
> >> currently come with such code, toasting any RT kernel. May come one day,
> >> but this will be primarily for legacy non-RT code.
> > 
> > Providing "cli" emulation to X-Servers would only make sense in order to
> > stall the Linux domain; controlling the interrupt shield dynamically
> > using the T_SHIELD bit would allow that already.
> 
> As far as I understood, the I-shield doesn't come for free. So, having
> at least an API to stall the root domain from user-space should be cheaper.
> 

The I-shield can be operated on a per-task basis, which reduces the
performance impact. Additionally, tweaking the Linux domain bit by hand
won't work: there are places in the kernel where it's purely reset. The
only way to do this sanely is to have an intermediate domain between
Xenomai and Linux that regulates the interrupt flow through it's own
stall control. IOW, like the interrupt shield does.

> > If I understand
> > correctly, we are talking about stalling the Xenomai domain too, and
> > this is a completely different story. The day we would provide such
> > "feature" as an official API, we would trigger tons of misuses of this
> > hack, a bit like we have now with the T_PRIMARY bit, a number of people
> > sprinkle over their code to control the task exec mode, which is most of
> > the time utterly sub-optimal, and automatically handled by the nucleus
> > already. IOW, I'm not convinced at all that adding such API would be the
> > right thing to do.
> 
> When it comes to *emulate* hacky RTAI APIs - I would not immediately
> refrain from considering this.

API emulation is done through a skin, in which case, I would have no
objection to see such support implemented there, since well, a skin is
aimed at emulating syntax, semantics and behaviour, including the bad
ones.

>  But I agree that this can open Pandora's
> box, and having it in the native skip could mess up a lot. Unless we
> will see a widely compatible RTAI user-space skin one day, it's probably
> better to keep status quo /wrt to non-root domain stalling.
> 

Indeed, this is my point, especially since there are other ways to
implement those operations for the purpose of porting RTAI code, without
polluting the native skin uselessly.

> > 
> > For the time being, it should be possible to write a simple kernel
> > module using either the native or RTDM API from kernel space, which
> > would handle such requests from user-space. For instance, one could use
> > rt_task_notify() from user-space to signal a helper task in a kernel
> > module that carries out the job, depending on the signal received. The
> > same goes for a trivial RTDM driver only implementing the ioctl()
> > support for the same purpose.
> 
> That still remains a hack, though now platform independent :). I would
> simply use the assembly + a big fat warning sign saying "This code needs
> serious refactoring!"

The difference is that such hack would work on any platform, and other
people having the same issue to solve could be suggested to use this
approach. Not all architectures allow to fiddle with the processor's
interrupt flag from non-privileged mode; actually, x86 is rather the
exception than the rule here.

> 
> Jan
> 
-- 
Philippe.