[Xenomai-help] user mode vs. kernel module

[Xenomai-help] user mode vs. kernel module

[Ignacio García Pérez]

Hi,

So far I've had my application implemented entirely as a kernel module 
with some user mode helper programs. I've had in mind changing to user 
mode but never felt compelled enough.

Now, having a new requirement to implement, I think it's the moment to 
give it a try, and I'm porting it. I have a couple of questions:

1- How significative, in real world terms, is the overhead involved in 
operaing in user mode?. As far as I know all operations are executed via 
"pods" which involve one or more system calls and context switches. I'm 
using a Geode board right now but there are plans to move to a more 
low-end platform (486).

2- ioperm. This is a true headache. I've spent countless hours debugging 
this and banging my head agaist the wall. I'm not 100% sure of what's 
going on here, but it looks like the ioperm call must be issued from 
primary mode if you are doing the I/O from primary mode. Something like 
this would segfault:

ioperm(0x443, 0x01, 1);
rt_mutex_lock(...)
outb(0x01, 0x443)

While this works fine:

rt_mutex_lock(...)
ioperm(0x443, 0x01, 1);
outb(0x01, 0x443);

While leads me to think that the rt_mutex_lock puts the task in primary 
mode and then both ioperm and outb are executed in the same mode so 
everything works.

Is this right?. If so, I find this extremely inconvenient...

Nacho.

Re: [Xenomai-help] user mode vs. kernel module

[Philippe Gerum]

Ignacio García Pérez wrote:
> Hi,
> 
> So far I've had my application implemented entirely as a kernel module 
> with some user mode helper programs. I've had in mind changing to user 
> mode but never felt compelled enough.
> 
> Now, having a new requirement to implement, I think it's the moment to 
> give it a try, and I'm porting it. I have a couple of questions:
> 
> 1- How significative, in real world terms, is the overhead involved in 
> operaing in user mode?. As far as I know all operations are executed via 
> "pods" which involve one or more system calls and context switches. I'm 
> using a Geode board right now but there are plans to move to a more 
> low-end platform (486).
> 
> 2- ioperm. This is a true headache. I've spent countless hours debugging 
> this and banging my head agaist the wall. I'm not 100% sure of what's 
> going on here, but it looks like the ioperm call must be issued from 
> primary mode if you are doing the I/O from primary mode. Something like 
> this would segfault:
> 
> ioperm(0x443, 0x01, 1);
> rt_mutex_lock(...)
> outb(0x01, 0x443)
> 
> While this works fine:
> 
> rt_mutex_lock(...)
> ioperm(0x443, 0x01, 1);
> outb(0x01, 0x443);
> 
> While leads me to think that the rt_mutex_lock puts the task in primary 
> mode and then both ioperm and outb are executed in the same mode so 
> everything works.
> 
> Is this right?

No.

. If so, I find this extremely inconvenient...
> 

Fixed in the repository. Use iopl(3) as a work-around, or resync.

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


-- 

Philippe.

Re: [Xenomai-help] user mode vs. kernel module

[Philippe Gerum]

Philippe Gerum wrote:
> Ignacio García Pérez wrote:
> 
>> Hi,
>>
>> So far I've had my application implemented entirely as a kernel module 
>> with some user mode helper programs. I've had in mind changing to user 
>> mode but never felt compelled enough.
>>
>> Now, having a new requirement to implement, I think it's the moment to 
>> give it a try, and I'm porting it. I have a couple of questions:
>>
>> 1- How significative, in real world terms, is the overhead involved in 
>> operaing in user mode?. As far as I know all operations are executed 
>> via "pods" which involve one or more system calls and context 
>> switches. I'm using a Geode board right now but there are plans to 
>> move to a more low-end platform (486).
>>
>> 2- ioperm. This is a true headache. I've spent countless hours 
>> debugging this and banging my head agaist the wall. I'm not 100% sure 
>> of what's going on here, but it looks like the ioperm call must be 
>> issued from primary mode if you are doing the I/O from primary mode. 
>> Something like this would segfault:
>>
>> ioperm(0x443, 0x01, 1);
>> rt_mutex_lock(...)
>> outb(0x01, 0x443)
>>
>> While this works fine:
>>
>> rt_mutex_lock(...)
>> ioperm(0x443, 0x01, 1);
>> outb(0x01, 0x443);
>>
>> While leads me to think that the rt_mutex_lock puts the task in 
>> primary mode and then both ioperm and outb are executed in the same 
>> mode so everything works.
>>
>> Is this right?
> 
> 
> No.
> 
> . If so, I find this extremely inconvenient...
> 
>>
> 
> Fixed in the repository. Use iopl(3) as a work-around, or resync.
> 

Btw, the fix concerns the active i/o bitmap ownership in the TSS for kernel 
versions >= 2.6.15, but the segfault you encounter is likely an application error: 
ioperm() cannot be used for ports above 0x3ff. You must resort to using iopl() to 
access port address 0x443.

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


-- 

Philippe.

Re: [Xenomai-help] user mode vs. kernel module

[Ignacio García Pérez]

Philippe Gerum escribió:
> Ignacio García Pérez wrote:
>> Hi,
>>
>> So far I've had my application implemented entirely as a kernel 
>> module with some user mode helper programs. I've had in mind changing 
>> to user mode but never felt compelled enough.
>>
>> Now, having a new requirement to implement, I think it's the moment 
>> to give it a try, and I'm porting it. I have a couple of questions:
>>
>> 1- How significative, in real world terms, is the overhead involved 
>> in operaing in user mode?. As far as I know all operations are 
>> executed via "pods" which involve one or more system calls and 
>> context switches. I'm using a Geode board right now but there are 
>> plans to move to a more low-end platform (486).
>>
>> 2- ioperm. This is a true headache. I've spent countless hours 
>> debugging this and banging my head agaist the wall. I'm not 100% sure 
>> of what's going on here, but it looks like the ioperm call must be 
>> issued from primary mode if you are doing the I/O from primary mode. 
>> Something like this would segfault:
>>
>> ioperm(0x443, 0x01, 1);
>> rt_mutex_lock(...)
>> outb(0x01, 0x443)
>>
>> While this works fine:
>>
>> rt_mutex_lock(...)
>> ioperm(0x443, 0x01, 1);
>> outb(0x01, 0x443);
>>
>> While leads me to think that the rt_mutex_lock puts the task in 
>> primary mode and then both ioperm and outb are executed in the same 
>> mode so everything works.
>>
>> Is this right?
>
> No.
>
> . If so, I find this extremely inconvenient...
>>
>
> Fixed in the repository. Use iopl(3) as a work-around, or resync.
Whoa. Now that's a quick fix. I'll go for the cutting edge svn version, 
though as pointed out in another message, I must anyway use iopl to 
access ports above 0x3FF.

Thank you.

Nacho.