From: Jan Kiszka <jan.kiszka@domain.hid>
To: Nilanjan Roychowdhury <Nilanjan.Roychowdhury@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] driver migration
Date: Thu, 14 Sep 2006 11:27:16 +0200 [thread overview]
Message-ID: <45092074.2070000@domain.hid> (raw)
In-Reply-To: <9D98C51005D80D43A19A3DF329A61D69515623@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]
Nilanjan Roychowdhury wrote:
>
>
> Hi,
> I had a linux driver with functionalities like it blocks a thread on an
> ioctl and wakes it up when an interrupt occurs and does some processing.
> Now I want to migrate to xenomai space. Can I write a user space device
> driver for this like I create an user space rt_task and call
> rt_intr_wait in the entry fuction of the task and whenever I get an
> interrupt I wake up and do the processing. Will I have any performance
> hit?? I will make sure the priority of this xenomai task is higher than
> any other xenomai task as it will do some interrupt processing.
>
> In general, if I need to migrate a traditional linux device driver with
> only user space clients to xenomai space can I write a user - space
> device driver ???
You can. Both native and posix skin provide means to block a user-space
thread on an IRQ event. And if you already have a working user-space
driver, that step should be simple as there are likely no problems with
kernel-only services like DMA management.
It is planned to enhance the Real-Time Driver Model (RTDM) with
user-space support as well, keeping both the programming model for the
driver users (profiles) as well as for the driver developers as far as
feasible. The idea is to make drivers easily re-compilable/portable
between kernel and user-space - but that's something which cannot help
you yet.
>
> Under what scenario we place a driver as a kernel module in xenomai
> space??
Performance will remain a reason to go to kernel-space, specifically if
you either share your device between multiple processes (having a driver
in a separate process comes at a price...) or if you need low latency on
IRQ handling. But there are also reasons to go to user-space, e.g.
license issues. We are trying to address both.
In any case, a clear separation between driver and application design is
highly recommended and something we try to foster with RTDM.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
next prev parent reply other threads:[~2006-09-14 9:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-14 9:10 [Xenomai-help] driver migration Nilanjan Roychowdhury
2006-09-14 9:27 ` Jan Kiszka [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-09-14 9:37 Nilanjan Roychowdhury
2006-09-14 9:40 ` Jan Kiszka
2006-09-14 9:52 Nilanjan Roychowdhury
2006-09-14 10:40 ` Jan Kiszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45092074.2070000@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=Nilanjan.Roychowdhury@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.