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

["Ignacio García Pérez" <iggarpe@domain.hid>]

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.