[Xenomai] [RTDM] Converting existing Linux char driver to rtdm driver

Pintu Kumar pintu.ping at gmail.com
Tue Feb 27 14:39:53 CET 2018


Dear Greg & Jan,

Thank you so much for your help. Yes I am looking into existing sample
drivers to understand. I think I got some clue.
Basically I am developing a dummy RTDM char driver for some
experimentation and analysis purpose.
As you said, since there is no proper documentation for developing a
RTDM driver, I might be having some more silly queries (if I am
stuck).

1)
> What's confusing about the context?
As I see, there is a context_size that we need to set in rtdm_driver structure.
Is this really required to set ? Can I set it to 0 ?
Anyways, I currently set like this (for time being):
struct dummy_context {
        unsigned char *buffer;
        unsigned int len;
};
Hope this fine ?

2)
> The other question is do you need at RTDM driver?
Yes, I need to develop a RTDM driver because I need to compare it with
normal kernel driver.
Later I need to add some specific use case for some purpose.

3) How do we allocate memory in RTDM driver ?
    I see rtdm_malloc()/free() is used. Is this in kernel allocation
like kmalloc/vmalloc ?
    Or, I need to directly use kmalloc/vmalloc itself , considering
similar scenario like normal kernel approach.

4) ^^Most important^^: how to I compile a sample RTDM char driver?
    Is it the same method like normal kernel Makefile and using the
xeno_config in addition ?
    Is there any RTDM Makefile reference available ?


5) When I install the RTDM driver (using insmod or modprobe), will it
create the /dev node automatically like "misc" ?
    I am registering the driver using: RTDM_CLASS_MISC


Thanks,
Pintu


On Mon, Feb 26, 2018 at 10:58 PM, Greg Gallagher <greg at embeddedgreg.com> wrote:
> You'd have to decide what functionality you want with respect to rt
> and non rt for your driver.  What's confusing about the context?  The
> gpio driver is pretty up to date, you can look at it for some
> guidance.  Unfortunately there isn't a lot of documentation at the
> moment, so your best bet is to look at some of the existing drivers.
> It's easier to answer specific questions you may have about the RTDM
> framework.  The other question is do you need at RTDM driver?  Could
> you use the UDD framework instead?  With the UDD framework you just
> need to support a small RTDM driver and the rest of the driver lives
> in user space.
>
> -Greg
>
> On Mon, Feb 26, 2018 at 12:20 PM, Pintu Kumar <pintu.ping at gmail.com> wrote:
>> Dear Jan,
>>
>> This thread is about porting a normal misc char driver to rtdm model.
>>
>> Anyways I got some clue by looking into rtdmtest driver.
>> But what is confusing to me is the rtdm context_ part and the rt, nrt part.
>> How can I map this eith my exusting driver?
>> Can I leave the context part NULL and use only rt for all other calls.
>>
>> Thanks,
>> Pintu
>>
>> On 26 Feb 2018 7:54 pm, "Jan Kiszka" <jan.kiszka at siemens.com> wrote:
>>>
>>> On 2018-02-26 12:26, Pintu Kumar wrote:
>>> > Hi,
>>> >
>>> > I have a sample linux char driver which I am registering using normal
>>> > misc_register/deregister function.
>>> > In this driver, I have used, open, read, write, ioctl, release system
>>> > calls.
>>> >
>>> > Now I wanted to convert this driver to RTDM interface and compare it.
>>> > Later I wanted to add some more use cases related to interrupt
>>> > processing by connecting some external peripheral.
>>> >
>>> > Firstly, please guide me how to easily convert an existing linux char
>>> > driver to RTDM model.
>>> >
>>>
>>> Conversion of existing Linux UART drivers to RTDM is not straightforward
>>> as the former relies on a larger hierarchy of Linux drivers, starting
>>> with the tty core over the serial core and possibly some chip
>>> abstractions (8250). RTDM, as you can see from the existing drivers in
>>> kernel/drivers/serial, is rather compact and does not come with that
>>> infrastructure, primarily as it has a confined use case. Best is to
>>> study those drivers, use one as template and replace the required
>>> hardware accesses.
>>>
>>> Jan
>>>
>>> --
>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>>> Corporate Competence Center Embedded Linux



More information about the Xenomai mailing list