What's your prototype for dummy_write? Can you post the function
definition. It looks like there's a rt_write is expecting a different
type.
On Wed, Feb 28, 2018 at 7:16 AM, Pintu Kumar <pintu.p...@gmail.com> wrote:
> Hi,
>
> I am getting some error while building a RTDM driver. Please check my
> inline reply.
>
>
> On Tue, Feb 27, 2018 at 7:09 PM, Pintu Kumar <pintu.p...@gmail.com> wrote:
>> 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 ?
>>
>
> Hi,
>
> I get this errors when compiling a sample RTDM driver.
>
> rtdummy.c:63:15: error: initialization from incompatible pointer type
> [-Werror=incompatible-pointer-types]
> .write_rt = dummy_write,
> ^
> /home/pintu/rtdummy.c:63:15: note: (near initialization for
> ‘dummy_driver.ops.write_rt’)
> cc1: some warnings being treated as errors
>
>
> However, if I comment the write_rt part, the module is build successfully.
> Why this error is coming only for write part, but not for read, open,
> ioctl and others ?
>
> This is my Makefile (simple Makefile used for building linux kernel module)
> --------------------------------
> EXTRA_CFLAGS += -I$(shell pwd)
>
> obj-m := rtdummy.o
>
> KDIR := /lib/modules/$(shell uname -r)/build
> PWD := $(shell pwd)
>
> default:
> $(MAKE) -C $(KDIR) M=$(PWD) modules
>
> clean:
> $(MAKE) -C $(KDIR) M=$(PWD) clean
> --------------------------------
>
> This is the structure used:
>
> -------------------------------------------------------------
> static struct rtdm_driver dummy_driver = {
> .profile_info = RTDM_PROFILE_INFO(dummy,
> RTDM_CLASS_DUMMY,
> RTDM_SUBCLASS_DUMMY,
> 0),
> .device_flags = RTDM_NAMED_DEVICE|RTDM_EXCLUSIVE,
> .device_count = 1,
> .context_size = sizeof(struct dummy_context),
> .ops = {
> .open = dummy_open,
> .read_rt = dummy_read,
> .write_rt = dummy_write,
> .ioctl_rt = dummy_ioctl,
> .ioctl_nrt = dummy_ioctl,
> .close = dummy_close,
> },
> };
> -------------------------------------------------------------
>
> Please let me know how to fix this error ?
>
>
> Thanks,
> Pintu
>
>
>>
>> 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 <g...@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.p...@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.kis...@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
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
