[Xenomai] Migrating some kernel code from Xenomai 2.6 to 3.0

[Xenomai] Migrating some kernel code from Xenomai 2.6 to 3.0

[Radu Rendec]

Hi all,

I need to port some kernel and application code from Xenomai 2.6 to
Xenomai 3.0.

The existing code creates a semaphore with sem_open() from the *kernel*
module init function and posts it with sem_post() from a rtdm interrupt
handler (which is also part of the kernel module). The application opens
the same semaphore and synchronizes on it using sem_wait().

I can see that the xenomai/posix/posix.h header is gone from the kernel
tree. What is the correct way of accessing the semaphore from the kernel
code? What headers need to be included?

The migration guide focuses more on the application side, but doesn't
provide much info for the kernel side. By the way, the old link to the
guide at https://xenomai.org/migrating-from-xenomai-2-x-to-3-x/ seems
to be broken after the gitlab migration.

Thanks,
Radu Rendec

Re: [Xenomai] Migrating some kernel code from Xenomai 2.6 to 3.0

[Philippe Gerum]

On 06/27/2018 03:52 PM, Radu Rendec wrote:
> Hi all,
> 
> I need to port some kernel and application code from Xenomai 2.6 to
> Xenomai 3.0.
> 
> The existing code creates a semaphore with sem_open() from the *kernel*
> module init function and posts it with sem_post() from a rtdm interrupt
> handler (which is also part of the kernel module). The application opens
> the same semaphore and synchronizes on it using sem_wait().
> 
> I can see that the xenomai/posix/posix.h header is gone from the kernel
> tree. What is the correct way of accessing the semaphore from the kernel
> code? What headers need to be included?
> 

The only API available from kernel space is RTDM. Since you already have
a RTDM driver in place, all you need to do is to expose a read() or
ioctl() service to userland, which would wait on rtdm_sem_down to be
posted by your IRQ handler via rtdm_sem_up.

The naming part would be solved by opening that particular (named)
device your RTDM driver would create.

e.g. depending on your choice on the kernel side, you would have
something like this in userland:

fd = open("/dev/rtdm/your-device", O_RDWR);
...
ret = read(fd, ...);
OR,
ret = ioctl(fd, ...);

select() could be made available in both cases too.

> The migration guide focuses more on the application side, but doesn't
> provide much info for the kernel side. By the way, the old link to the
> guide at https://xenomai.org/migrating-from-xenomai-2-x-to-3-x/ seems
> to be broken after the gitlab migration.
> 

Fixed, thanks.

-- 
Philippe.

Re: [Xenomai] Migrating some kernel code from Xenomai 2.6 to 3.0

[Radu Rendec]

On Wed, Jun 27, 2018 at 10:55 AM Philippe Gerum <rpm@xenomai.org> wrote:
> The only API available from kernel space is RTDM. Since you already have
> a RTDM driver in place, all you need to do is to expose a read() or
> ioctl() service to userland, which would wait on rtdm_sem_down to be
> posted by your IRQ handler via rtdm_sem_up.

Thanks for the detailed answer, Philippe! This should be enough to get
me going.

On the other hand, the same semaphore is sometimes posted from user
space and that complicates things (I guess I would have to create
another ioctl() that posts the semaphore from kernel space).

Since the project is on a tight schedule, I'm also considering leaving
the code on Xenomai 2.6 for now. So here's another question: is there
any chance Xenomai 2.6 could work on kernel 4.4? How about ipipe-core?

It looks like Xenomai 2.6 requires the "legacy" API of ipipe-core and
that doesn't seem to compile on kernel 4.4.

Thanks,
Radu

Re: [Xenomai] Migrating some kernel code from Xenomai 2.6 to 3.0

[Philippe Gerum]

On 06/27/2018 05:30 PM, Radu Rendec wrote:
> On Wed, Jun 27, 2018 at 10:55 AM Philippe Gerum <rpm@xenomai.org> wrote:
>> The only API available from kernel space is RTDM. Since you already have
>> a RTDM driver in place, all you need to do is to expose a read() or
>> ioctl() service to userland, which would wait on rtdm_sem_down to be
>> posted by your IRQ handler via rtdm_sem_up.
> 
> Thanks for the detailed answer, Philippe! This should be enough to get
> me going.
> 
> On the other hand, the same semaphore is sometimes posted from user
> space and that complicates things (I guess I would have to create
> another ioctl() that posts the semaphore from kernel space).
> 

That should not amount for a lot of additional kernel code. API-wise,
you could also use read/write pairs to pend/post the sema4 instead of
ioctls.

> Since the project is on a tight schedule, I'm also considering leaving
> the code on Xenomai 2.6 for now. So here's another question: is there
> any chance Xenomai 2.6 could work on kernel 4.4? How about ipipe-core?
> 

That support won't happen in mainline, 2.6 is EOL. The changes involved
in supporting this on your end should amount to update Xenomai 2.6 for
building over newer kernels. This may or may not be easy depending on
the arch (x86 is unlikely to be that simple). The legacy I-pipe API is
still there in 4.4 and 4.9 patch series, dropped by 4.14 though.

-- 
Philippe.