Re: Interrupts

[Philippe Gerum <rpm@xenomai.org>]

Russell Johnson <russell.johnson@kratosdefense.com> writes:

> [[S/MIME Signed Part:Undecided]]
>> The recommended way with EVL is to follow the common patterns used for
>
>> developing regular linux drivers, except that the EVL kernel API must be
>
>> used instead of the regular/in-band kernel API for anything which wants
>
>> to synchronize threads over the oob stage.
>
>>
>
>  
>
>> Typically, you could share an EVL semaphore [1] or an event flag group
>
>> [2] between the interrupt handler and the oob_ioctl() or oob_read()
>
>> call, which would block the user-space task until the matching event
>
>> happens. To monitor complex events, you could use an EVL wait queue
>
>> instead of a semaphore or a flag.
>
>>
>
>  
>
>> If you need to monitor multiple event sources in userland, you can use
>
>> the EVL poll API [4] with the file descriptors you would otherwise pass
>
>> to the oob_{ioctl, read, write}() calls.
>
>>
>
>  
>
>> [1] https://evlproject.org/core/user-api/semaphore/
>
>> [2] https://evlproject.org/core/user-api/flags/
>
>> [3] https://evlproject.org/core/kernel-api/wait/
>
>> [4] https://evlproject.org/core/user-api/poll/
>
>>
>
>  
>
>> -- 
>
>> Philippe.
>
>  
>
> If I create an EVL semaphore or event flag group on the userspace side (using the libevl API), how would I go about passing a reference to that down to the kernel driver (through ioctl)? Wouldn’t the kernel driver need to know what a “struct evl_sem” or a “struct evl_flags” is? But those are defined in the libevl usersapce API and the kernel does not have access to those headers from what I can see.
>
>  
>

You could export the file structure of a userland object to a kernel
driver, but this is not the recommended way, especially since this would
require to deal with the lifetime of those objects using the internal
EVL API in kernel space.

The proper way for an application is to create a kernel semaphore/flag,
post it from kernel space (e.g. from an interrupt handler), pend on it
from an oob_ioctl/oob_read handler typically.

The sequence would be as follows:

1. the user task issues oob_ioctl(fd, IOC_WAIT_FOO) or oob_read(fd),
which invokes the corresponding oob_ioctl and/or oob_read handlers in
the kernel driver.

2. Those handlers call e.g. evl_down() on the kernel sem, which the
interrupt handler can post using evl_up() at some point in order to
signal the event. Conversely, the user task would wait for such event,
sleeping in kernel context until it occurs.

-- 
Philippe.