[Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Jan Kiszka]

[-- Attachment #1.1: Type: text/plain, Size: 578 bytes --]

Hi all,

this is a first attempt to add the requested mmap functionality to the
RTDM driver API. Anyone interested in this feature is invited to test my
patch (Rodrigo... ;) ). Comments on the implementation are welcome as well.

Philippe, I need xnarch_remap_page_range for this and added a #define
XENO_HEAP_MODULE hack to rtdm/drvlib.c therefore. What would you suggest
as a cleaner approach? Make this function available unconditionally or
introduce something like XENO_RTDM_MODULE? Moreover, isn't this
implementation also interesting for nucleus/heap.c?

Jan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: rtdm_mmap.patch --]
[-- Type: text/x-patch; name="rtdm_mmap.patch", Size: 4956 bytes --]

Index: include/rtdm/rtdm_driver.h
===================================================================
--- include/rtdm/rtdm_driver.h	(Revision 551)
+++ include/rtdm/rtdm_driver.h	(Arbeitskopie)
@@ -995,6 +995,10 @@
     xnfree(ptr);
 }
 
+int rtdm_mmap_to_user(rtdm_user_info_t *user_info, void *src_addr, size_t len,
+                      int prot, void **pptr);
+int rtdm_munmap(rtdm_user_info_t *user_info, void *ptr, size_t len);
+
 static inline int rtdm_read_user_ok(rtdm_user_info_t *user_info,
                                     const void __user *ptr, size_t size)
 {
Index: ksrc/skins/rtdm/drvlib.c
===================================================================
--- ksrc/skins/rtdm/drvlib.c	(Revision 551)
+++ ksrc/skins/rtdm/drvlib.c	(Arbeitskopie)
@@ -31,7 +31,9 @@
 
 
 #include <linux/delay.h>
+#include <linux/mman.h>
 
+#define XENO_HEAP_MODULE
 #include <rtdm/rtdm_driver.h>
 
 
@@ -1286,7 +1288,7 @@
  * Rescheduling: never.
  */
 int rtdm_irq_disable(rtdm_irq_t *irq_handle);
-/** @} */
+/** @} Interrupt Management Services */
 
 
 /*!
@@ -1358,16 +1360,127 @@
  * environments.
  */
 void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig);
-/** @} */
+/** @} Non-Real-Time Signalling Services */
 
+#endif /* DOXYGEN_CPP */
 
+
 /*!
  * @ingroup driverapi
  * @defgroup util Utility Services
  * @{
  */
 
+static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct *vma)
+{
+    return xnarch_remap_page_range(vma, vma->vm_start,
+                                   virt_to_phys(filp->private_data),
+                                   vma->vm_end - vma->vm_start, PAGE_SHARED);
+}
+
+static struct file_operations rtdm_mmap_fops = {
+    .mmap = rtdm_mmap_buffer,
+};
+
 /**
+ * Map a kernel memory range into the address space of the user.
+ *
+ * @param[in] user_info User information pointer as passed to the invoked
+ * device operation handler
+ * @param[in] src_addr Kernel address to be mapped
+ * @param[in] len Length of the memory range
+ * @param[in] prot Protection flags for the user's memory range, typically
+ * either PROT_READ or PROT_READ|PROT_WRITE
+ * @param[in,out] pptr Address of a pointer containing the desired user
+ * address or NULL on entry and the finally assigned address on return
+ *
+ * @return 0 on success, otherwise:
+ *
+ * - -EXXX is returned if .
+ *
+ * @note An RTDM driver is expected to invoke rtdm_munmap on every mapped
+ * memory range either when the user requests it explicitly or when the
+ * related device is closed.
+ *
+ * Environments:
+ *
+ * This service can be called from:
+ *
+ * - Kernel module initialization/cleanup code
+ * - User-space task (non-RT)
+ *
+ * Rescheduling: possible.
+ */
+int rtdm_mmap_to_user(rtdm_user_info_t *user_info, void *src_addr, size_t len,
+                      int prot, void **pptr)
+{
+    struct file             *filp;
+    struct file_operations  *old_fops;
+    void                    *old_priv_data;
+    void                    *user_ptr;
+
+    filp = filp_open("/dev/zero", O_RDWR, 0);
+    if (IS_ERR(filp))
+        return PTR_ERR(filp);
+
+    old_fops = filp->f_op;
+    filp->f_op = &rtdm_mmap_fops;
+
+    old_priv_data = filp->private_data;
+    filp->private_data = src_addr;
+
+    down_write(&user_info->mm->mmap_sem);
+    user_ptr = (void *)do_mmap(filp, (unsigned long)*pptr, len, prot,
+                               MAP_SHARED, 0);
+    up_write(&user_info->mm->mmap_sem);
+
+    filp->f_op = old_fops;
+    filp->private_data = old_priv_data;
+
+    filp_close(filp, user_info->files);
+
+    if (IS_ERR(user_ptr))
+        return PTR_ERR(user_ptr);
+
+    *pptr = user_ptr;
+    return 0;
+}
+
+/**
+ * Unmap a user memory range.
+ *
+ * @param[in] user_info User information pointer as passed to
+ * rtdm_mmap_to_user() when requesting to map the memory range
+ * @param[in] ptr User address or the memory range
+ * @param[in] len Length of the memory range
+ *
+ * @return 0 on success, otherwise:
+ *
+ * - -EXXX is returned if .
+ *
+ * Environments:
+ *
+ * This service can be called from:
+ *
+ * - Kernel module initialization/cleanup code
+ * - User-space task (non-RT)
+ *
+ * Rescheduling: possible.
+ */
+int rtdm_munmap(rtdm_user_info_t *user_info, void *ptr, size_t len)
+{
+    int err;
+
+    down_write(&user_info->mm->mmap_sem);
+    err = do_munmap(user_info->mm, (unsigned long)ptr, len);
+    up_write(&user_info->mm->mmap_sem);
+
+    return err;
+}
+
+#ifdef DOXYGEN_CPP /* Only used for doxygen doc generation */
+
+/**
  * Real-time safe message printing on kernel console
  *
  * @param[in] format Format string (conforming standard @c printf())
@@ -1583,6 +1696,6 @@
  */
 int rtdm_in_rt_context(void);
 
-/** @} */
+#endif /* DOXYGEN_CPP */
 
-#endif /* DOXYGEN_CPP */
+/** @} Utility Services */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Jan Kiszka]

[-- Attachment #1.1: Type: text/plain, Size: 293 bytes --]

Jan Kiszka wrote:
> Hi all,
> 
> this is a first attempt to add the requested mmap functionality to the
> RTDM driver API.

... and this version is even more useful than the previous one (now with
EXPORT_SYMBOL!). Be warned: I just compiled it, I count on third-party
testers.

Jan

[-- Attachment #1.2: rtdm_mmap.patch-v2 --]
[-- Type: text/plain, Size: 5034 bytes --]

Index: include/rtdm/rtdm_driver.h
===================================================================
--- include/rtdm/rtdm_driver.h	(Revision 556)
+++ include/rtdm/rtdm_driver.h	(Arbeitskopie)
@@ -995,6 +995,10 @@
     xnfree(ptr);
 }
 
+int rtdm_mmap_to_user(rtdm_user_info_t *user_info, void *src_addr, size_t len,
+                      int prot, void **pptr);
+int rtdm_munmap(rtdm_user_info_t *user_info, void *ptr, size_t len);
+
 static inline int rtdm_read_user_ok(rtdm_user_info_t *user_info,
                                     const void __user *ptr, size_t size)
 {
Index: ksrc/skins/rtdm/drvlib.c
===================================================================
--- ksrc/skins/rtdm/drvlib.c	(Revision 556)
+++ ksrc/skins/rtdm/drvlib.c	(Arbeitskopie)
@@ -31,7 +31,9 @@
 
 
 #include <linux/delay.h>
+#include <linux/mman.h>
 
+#define XENO_HEAP_MODULE
 #include <rtdm/rtdm_driver.h>
 
 
@@ -1286,7 +1288,7 @@
  * Rescheduling: never.
  */
 int rtdm_irq_disable(rtdm_irq_t *irq_handle);
-/** @} */
+/** @} Interrupt Management Services */
 
 
 /*!
@@ -1358,16 +1360,133 @@
  * environments.
  */
 void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig);
-/** @} */
+/** @} Non-Real-Time Signalling Services */
 
+#endif /* DOXYGEN_CPP */
 
+
 /*!
  * @ingroup driverapi
  * @defgroup util Utility Services
  * @{
  */
 
+static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct *vma)
+{
+    return xnarch_remap_page_range(vma, vma->vm_start,
+                                   virt_to_phys(filp->private_data),
+                                   vma->vm_end - vma->vm_start, PAGE_SHARED);
+}
+
+static struct file_operations rtdm_mmap_fops = {
+    .mmap = rtdm_mmap_buffer,
+};
+
 /**
+ * Map a kernel memory range into the address space of the user.
+ *
+ * @param[in] user_info User information pointer as passed to the invoked
+ * device operation handler
+ * @param[in] src_addr Kernel address to be mapped
+ * @param[in] len Length of the memory range
+ * @param[in] prot Protection flags for the user's memory range, typically
+ * either PROT_READ or PROT_READ|PROT_WRITE
+ * @param[in,out] pptr Address of a pointer containing the desired user
+ * address or NULL on entry and the finally assigned address on return
+ *
+ * @return 0 on success, otherwise:
+ *
+ * - -EXXX is returned if .
+ *
+ * @note An RTDM driver is expected to invoke rtdm_munmap on every mapped
+ * memory range either when the user requests it explicitly or when the
+ * related device is closed.
+ *
+ * Environments:
+ *
+ * This service can be called from:
+ *
+ * - Kernel module initialization/cleanup code
+ * - User-space task (non-RT)
+ *
+ * Rescheduling: possible.
+ */
+int rtdm_mmap_to_user(rtdm_user_info_t *user_info, void *src_addr, size_t len,
+                      int prot, void **pptr)
+{
+    struct file             *filp;
+    struct file_operations  *old_fops;
+    void                    *old_priv_data;
+    void                    *user_ptr;
+
+    filp = filp_open("/dev/zero", O_RDWR, 0);
+    if (IS_ERR(filp))
+        return PTR_ERR(filp);
+
+    old_fops = filp->f_op;
+    filp->f_op = &rtdm_mmap_fops;
+
+    old_priv_data = filp->private_data;
+    filp->private_data = src_addr;
+
+    down_write(&user_info->mm->mmap_sem);
+    user_ptr = (void *)do_mmap(filp, (unsigned long)*pptr, len, prot,
+                               MAP_SHARED, 0);
+    up_write(&user_info->mm->mmap_sem);
+
+    filp->f_op = old_fops;
+    filp->private_data = old_priv_data;
+
+    filp_close(filp, user_info->files);
+
+    if (IS_ERR(user_ptr))
+        return PTR_ERR(user_ptr);
+
+    *pptr = user_ptr;
+    return 0;
+}
+
+EXPORT_SYMBOL(rtdm_mmap_to_user);
+
+
+/**
+ * Unmap a user memory range.
+ *
+ * @param[in] user_info User information pointer as passed to
+ * rtdm_mmap_to_user() when requesting to map the memory range
+ * @param[in] ptr User address or the memory range
+ * @param[in] len Length of the memory range
+ *
+ * @return 0 on success, otherwise:
+ *
+ * - -EXXX is returned if .
+ *
+ * Environments:
+ *
+ * This service can be called from:
+ *
+ * - Kernel module initialization/cleanup code
+ * - User-space task (non-RT)
+ *
+ * Rescheduling: possible.
+ */
+int rtdm_munmap(rtdm_user_info_t *user_info, void *ptr, size_t len)
+{
+    int err;
+
+    down_write(&user_info->mm->mmap_sem);
+    err = do_munmap(user_info->mm, (unsigned long)ptr, len);
+    up_write(&user_info->mm->mmap_sem);
+
+    return err;
+}
+
+EXPORT_SYMBOL(rtdm_munmap);
+
+
+#ifdef DOXYGEN_CPP /* Only used for doxygen doc generation */
+
+/**
  * Real-time safe message printing on kernel console
  *
  * @param[in] format Format string (conforming standard @c printf())
@@ -1583,6 +1702,6 @@
  */
 int rtdm_in_rt_context(void);
 
-/** @} */
+#endif /* DOXYGEN_CPP */
 
-#endif /* DOXYGEN_CPP */
+/** @} Utility Services */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Rodrigo Rosenfeld Rosas]

Hi Jan, I started the tests and had problems on unloading the module.

I am probably doing something wrong but I think the driver shouldn't crash.
Probably it is missing some sanity checks on rtdm_munmap like 

if (! (user_info && user_info->mm))
	return -EXXX;

I'll investigate the problems... I had some unexpected things to investigate 
today and haven't had enought time to test the patch but hopefully I'll do it 
on monday...

That was the result:

Unable to handle kernel NULL pointer dereference at virtual address 00000030
 printing eip:
e0a1f2fc
*pde = 00000000
Oops: 0002 [#1]
PREEMPT
Modules linked in: rt_dt3153 parport_pc lp parport af_packet nls_iso8859_1 
nls_cp437 v4l2_common videodev video_buf xeno_rtdm xeno_native xeno_nucleus 
snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq 
snd_seq_device snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss 
snd_mixer_oss snd_pcm e100 mii snd_timer evdev snd soundcore snd_page_alloc 
hw_random i2c_i801 i2c_core ehci_hcd intel_agp agpgart ide_cd uhci_hcd 
usbcore cdrom
CPU:    0
EIP:    0060:[<e0a1f2fc>]    Not tainted VLI
EFLAGS: 00010286   (2.6.15.4-adeos)
EIP is at rtdm_munmap+0x11/0x44 [xeno_rtdm]
eax: 00000030   ebx: d2e45a70   ecx: 00000000   edx: ffff0001
esi: bfd72660   edi: 00000880   ebp: c2b20000   esp: c2b21f4c
ds: 007b   es: 007b   ss: 0068
Process rmmod (pid: 4254, threadinfo=c2b20000 task=d70bf550)
Stack: e0bfafa0 bfd72660 e0bf7cbc d2e45a70 b7d92000 00096000 e0bfad80 c0132e0d
       645f7472 35313374 c0320033 00000246 c03fa4cc c013c881 00000021 c0324200
       00000246 c2b21fbc 00000021 00000001 c0324200 bfd72660 00d72660 00000000
Call Trace:
 [<e0bf7cbc>] cleanup_module+0x24/0x50 [rt_dt3153]
 [<c0132e0d>] sys_delete_module+0x12e/0x15f
 [<c013c881>] __ipipe_dispatch_event+0x56/0xd5
 [<c0102fc8>] syscall_call+0x7/0xb
Code: 5f 89 e8 81 fd 18 fc ff ff 77 08 8b 5c 24 2c 89 2b 31 c0 59 5b 5b 5e 5f 
5d c3 56 53 8b 5c 24 0c 8b 4b 78 8d 41 30 ba 01 00 ff ff <0f> c1 10 85 d2 75 
4c ff 74 24 14 ff 74 24 14 ff 73 78 e8 2f 02

Regards,

Rodrigo.

____________________________________________________________
Em Quinta 09 Fevereiro 2006 22:37, Jan Kiszka escreveu:

>Jan Kiszka wrote:
>> Hi all,
>>
>> this is a first attempt to add the requested mmap functionality to the
>> RTDM driver API.
>
>... and this version is even more useful than the previous one (now with
>EXPORT_SYMBOL!). Be warned: I just compiled it, I count on third-party
>testers.
>
>Jan

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Rodrigo Rosenfeld Rosas]

Hi Jan, it just happened once and I couldn't reproduce (I didn't want to=20
reproduce it too since I would need to restart my computer because the driv=
er=20
wouldn't unload)...

When it happened I forgot to start the timer running the latency program an=
d=20
my driver failed to load and due to some mistake I've made (I have not=20
indentified it yet), it crashed on rmmoding. I need to check this, but I=20
still think it is a good idea to make the sanity checks...

I have not written the user-space program yet, so you'll have to wait until=
=20
monday, when I'll be able to test it, hopefully. But it seems to be=20
working... I changed my driver design. I do the mmap's on driver=20
initialization and just pass the returned addresses on the IOCTL, so I can =
do=20
them in a RT-context. The problem is that even if the user call an IOCTL to=
=20
munmap, it will still be possible to him to continue using the provided=20
address and this would result in a problem. But, as in all situations, ther=
e=20
are trade-offs and I prefer to rely on the user, while providing a=20
RT-MMAP-IOCTL. Of course it isn't really a mmap, but if the user don't mess=
=20
with the pointers, it will work like if it was...

Hope you understood me, I wrote it a little confusing... :)

Until monday! ;)

Rodrigo.

____________________________________________________________
Em Sexta 10 Fevereiro 2006 18:58, Rodrigo Rosenfeld Rosas escreveu:

>Hi Jan, I started the tests and had problems on unloading the module.
>
>I am probably doing something wrong but I think the driver shouldn't crash.
>Probably it is missing some sanity checks on rtdm_munmap like
>
>if (! (user_info && user_info->mm))
>	return -EXXX;
>
>I'll investigate the problems... I had some unexpected things to investiga=
te
>today and haven't had enought time to test the patch but hopefully I'll do
> it on monday...
>
>That was the result:
>
>Unable to handle kernel NULL pointer dereference at virtual address 000000=
30
> printing eip:
>e0a1f2fc
>*pde =3D 00000000
>Oops: 0002 [#1]
>PREEMPT
>Modules linked in: rt_dt3153 parport_pc lp parport af_packet nls_iso8859_1
>nls_cp437 v4l2_common videodev video_buf xeno_rtdm xeno_native xeno_nucleus
>snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event
> snd_seq snd_seq_device snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_o=
ss
> snd_mixer_oss snd_pcm e100 mii snd_timer evdev snd soundcore snd_page_all=
oc
> hw_random i2c_i801 i2c_core ehci_hcd intel_agp agpgart ide_cd uhci_hcd
> usbcore cdrom
>CPU:    0
>EIP:    0060:[<e0a1f2fc>]    Not tainted VLI
>EFLAGS: 00010286   (2.6.15.4-adeos)
>EIP is at rtdm_munmap+0x11/0x44 [xeno_rtdm]
>eax: 00000030   ebx: d2e45a70   ecx: 00000000   edx: ffff0001
>esi: bfd72660   edi: 00000880   ebp: c2b20000   esp: c2b21f4c
>ds: 007b   es: 007b   ss: 0068
>Process rmmod (pid: 4254, threadinfo=3Dc2b20000 task=3Dd70bf550)
>Stack: e0bfafa0 bfd72660 e0bf7cbc d2e45a70 b7d92000 00096000 e0bfad80
> c0132e0d 645f7472 35313374 c0320033 00000246 c03fa4cc c013c881 00000021
> c0324200 00000246 c2b21fbc 00000021 00000001 c0324200 bfd72660 00d72660
> 00000000 Call Trace:
> [<e0bf7cbc>] cleanup_module+0x24/0x50 [rt_dt3153]
> [<c0132e0d>] sys_delete_module+0x12e/0x15f
> [<c013c881>] __ipipe_dispatch_event+0x56/0xd5
> [<c0102fc8>] syscall_call+0x7/0xb
>Code: 5f 89 e8 81 fd 18 fc ff ff 77 08 8b 5c 24 2c 89 2b 31 c0 59 5b 5b 5e
> 5f 5d c3 56 53 8b 5c 24 0c 8b 4b 78 8d 41 30 ba 01 00 ff ff <0f> c1 10 85
> d2 75 4c ff 74 24 14 ff 74 24 14 ff 73 78 e8 2f 02
>
>Regards,
>
>Rodrigo.
>
>____________________________________________________________
>
>Em Quinta 09 Fevereiro 2006 22:37, Jan Kiszka escreveu:
>>Jan Kiszka wrote:
>>> Hi all,
>>>
>>> this is a first attempt to add the requested mmap functionality to the
>>> RTDM driver API.
>>
>>... and this version is even more useful than the previous one (now with
>>EXPORT_SYMBOL!). Be warned: I just compiled it, I count on third-party
>>testers.
>>
>>Jan
>
>_______________________________________________________
>Yahoo! Acesso Gr=E1tis - Internet r=E1pida e gr=E1tis. Instale o discador =
agora!
>http://br.acesso.yahoo.com
>
>
>_______________________________________________
>Xenomai-core mailing list
>Xenomai-core@domain.hid
>https://mail.gna.org/listinfo/xenomai-core

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Jan Kiszka]

Rodrigo Rosenfeld Rosas wrote:
> Hi Jan, it just happened once and I couldn't reproduce (I didn't want to 
> reproduce it too since I would need to restart my computer because the driver 
> wouldn't unload)...
> 
> When it happened I forgot to start the timer running the latency program and 

Already running latest SVN version? rt_timer_start&friends became
deprecated last weekend, so you can't forget this step anymore.

> my driver failed to load and due to some mistake I've made (I have not 
> indentified it yet), it crashed on rmmoding. I need to check this, but I 
> still think it is a good idea to make the sanity checks...

We need some XENO_ASSERT that is only active when CONFIG_XENO_OPT_DEBUG
is set. I don't want to put such checks in production code, but I see
that they may help debugging early drivers.

> 
> I have not written the user-space program yet, so you'll have to wait until 
> monday, when I'll be able to test it, hopefully. But it seems to be 
> working... I changed my driver design. I do the mmap's on driver 
> initialization and just pass the returned addresses on the IOCTL, so I can do 
> them in a RT-context. The problem is that even if the user call an IOCTL to 

Hmm, I guess there is still some lacking documentation about what is
possible with RTDM. If you call an IOCTL from RT context, you end up in
the _rt-handler the driver of a device may have registered (if there is
no _rt-handler at all, the _nrt one is invoked, but this is likely not
relevant here).

I assume that you were wondering how to call rtdm_mmap_to_user from this
real-time handler, right? Well, the trick is to return -ENOSYS for those
IOCTL codes that can only be handled by the _nrt-handler. Xenomai will
then switch your RT task to secondary mode, restart the IOCTL, and the
mmap can safely be executed.

Well, maybe you do not have any arguments for rtdm_mmap_to_user that
should be influenced by the user's IOCTL. In this case your current
driver design is ok as well. I just wanted to underline that it is not
necessarily the only way.

> munmap, it will still be possible to him to continue using the provided 
> address and this would result in a problem. But, as in all situations, there 

When rtdm_munmap is executed, the virtual address range becomes invalid
for the user. Thus any further access to it will raise a segfault.
That's the only problem, but it will not influence the driver integrity.

> are trade-offs and I prefer to rely on the user, while providing a 
> RT-MMAP-IOCTL. Of course it isn't really a mmap, but if the user don't mess 
> with the pointers, it will work like if it was...

The user can only access the window you mapped in and only as long as it
is mapped. And if you map it read-only, there is even no chance to
destroy potential management structures of the hardware or the driver
within this range.

> 
> Hope you understood me, I wrote it a little confusing... :)

We will see...

> 
> Until monday! ;)
> 
> Rodrigo.
> 

Happy WE,
Jan

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Rodrigo Rosenfeld Rosas]

Jan Kiszka escreveu:
> Rodrigo Rosenfeld Rosas wrote:
>   
>> Hi Jan, it just happened once and I couldn't reproduce (I didn't want to 
>> reproduce it too since I would need to restart my computer because the driver 
>> wouldn't unload)...
>>
>> When it happened I forgot to start the timer running the latency program and 
>>     
>
> Already running latest SVN version?
Almost there ;) That is why your patch didn't apply cleany, but I just 
needed to include two "#include" and "#define" lines to drvlib.c or 
something like...

>  rt_timer_start&friends became
> deprecated last weekend, so you can't forget this step anymore.
>   
I didn't use rt_timer_start at all. I was doing as you suggested, 
calling another program to start the timer, like "latency".

>> my driver failed to load and due to some mistake I've made (I have not 
>> indentified it yet), it crashed on rmmoding. I need to check this, but I 
>> still think it is a good idea to make the sanity checks...
>>     
>
> We need some XENO_ASSERT that is only active when CONFIG_XENO_OPT_DEBUG
> is set. I don't want to put such checks in production code, but I see
> that they may help debugging early drivers.
>   
I understand your concernings but I really don't think they are 
relevant... This checks will be much faster then the procedure itself 
and it would conform to normal munmap behaviour. From man page:

"The address start must be a multiple of the page size. All pages 
containing a part of the indicated range are unmapped, and subsequent 
references to these pages will generate SIGSEGV. It is not an error if 
the indicated range does not contain any mapped pages."

I think that if there was an extra parameter for user_info, it would 
also verify for validity. BTW, I think there is missing some 
documentation about the user_info parameter. I had to remember our 
conversation and look at the code to understand that I should record 
"current" on this parameter on the moment I called mmap and passing it 
again on munmap. And it would be good to see the rtdm_user_info_t 
defined as struct task_struct on the documentation.

>> I have not written the user-space program yet, so you'll have to wait until 
>> monday, when I'll be able to test it, hopefully. But it seems to be 
>> working... I changed my driver design. I do the mmap's on driver 
>> initialization and just pass the returned addresses on the IOCTL, so I can do 
>> them in a RT-context. The problem is that even if the user call an IOCTL to 
>>     
>
> Hmm, I guess there is still some lacking documentation about what is
> possible with RTDM. If you call an IOCTL from RT context, you end up in
> the _rt-handler the driver of a device may have registered (if there is
> no _rt-handler at all, the _nrt one is invoked, but this is likely not
> relevant here).
>
> I assume that you were wondering how to call rtdm_mmap_to_user from this
> real-time handler, right?
No. I know it is not possible from the moment. I think I did not explain 
myself very well. I was wondering how to define a RT mmap like ioctl. As 
I know I could not use rtdm_mmap_to_user then, I thought in another way 
of doing it. So I mmaped on driver initialization. On the IOCTL I just 
passed the already known addresses to the user requesting it. I would 
have to explain you how these buffers work on V4L2. It is a bit long 
explanation but I can explain it on other message if you wish.

> Well, the trick is to return -ENOSYS for those
> IOCTL codes that can only be handled by the _nrt-handler. Xenomai will
> then switch your RT task to secondary mode, restart the IOCTL, and the
> mmap can safely be executed.
>   
But as I've said, it is not the behaviour I want :)

> Well, maybe you do not have any arguments for rtdm_mmap_to_user that
> should be influenced by the user's IOCTL.
That is my case.

> In this case your current driver design is ok as well. I just wanted to underline that it is not necessarily the only way.
>   
But I couldn't find other way of doing it in a RT-context.

>> munmap, it will still be possible to him to continue using the provided 
>> address and this would result in a problem. But, as in all situations, there 
>>     
>
> When rtdm_munmap is executed, the virtual address range becomes invalid
> for the user. Thus any further access to it will raise a segfault.
> That's the only problem, but it will not influence the driver integrity.
>   
Yes, that is the problem. Since I only mark as unused on the munmap 
IOCTL, it would be possible to the user to continue using that address 
even after the munmap IOCTL call. It I was using a really rtdm_munmap, 
it wouldn't be possible. It would be a better behaviour, but it would 
not be run on RT-context. That is the trade-off.

>> are trade-offs and I prefer to rely on the user, while providing a 
>> RT-MMAP-IOCTL. Of course it isn't really a mmap, but if the user don't mess 
>> with the pointers, it will work like if it was...
>>     
>
> The user can only access the window you mapped in and only as long as it
> is mapped.
In my case, it is always mapped to make possible the RT-IOCTLs.
> And if you map it read-only, there is even no chance to
> destroy potential management structures of the hardware or the driver
> within this range.
>   
I do not want to make it read-only because it will probably be very 
usefull to the user to write on it. The user may want to capture a frame 
and do some image processing routines on the same memory area when it is 
possible, avoiding to copy that memory region.
>> Hope you understood me, I wrote it a little confusing... :)
>>     
>
> We will see...
>   
:)
> Happy WE,
>   
Happy weekend for you too,

Rodrigo.


		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 8534 bytes --]

Rodrigo Rosenfeld Rosas wrote:
> Jan Kiszka escreveu:
>> Rodrigo Rosenfeld Rosas wrote:
>>  
>>> Hi Jan, it just happened once and I couldn't reproduce (I didn't want
>>> to reproduce it too since I would need to restart my computer because
>>> the driver wouldn't unload)...
>>>
>>> When it happened I forgot to start the timer running the latency
>>> program and     
>>
>> Already running latest SVN version?
> Almost there ;) That is why your patch didn't apply cleany, but I just
> needed to include two "#include" and "#define" lines to drvlib.c or
> something like...
> 
>>  rt_timer_start&friends became
>> deprecated last weekend, so you can't forget this step anymore.
>>   
> I didn't use rt_timer_start at all. I was doing as you suggested,
> calling another program to start the timer, like "latency".
> 
>>> my driver failed to load and due to some mistake I've made (I have
>>> not indentified it yet), it crashed on rmmoding. I need to check
>>> this, but I still think it is a good idea to make the sanity checks...
>>>     
>>
>> We need some XENO_ASSERT that is only active when CONFIG_XENO_OPT_DEBUG
>> is set. I don't want to put such checks in production code, but I see
>> that they may help debugging early drivers.
>>   
> I understand your concernings but I really don't think they are
> relevant... This checks will be much faster then the procedure itself
> and it would conform to normal munmap behaviour. From man page:
> 
> "The address start must be a multiple of the page size. All pages
> containing a part of the indicated range are unmapped, and subsequent
> references to these pages will generate SIGSEGV. It is not an error if
> the indicated range does not contain any mapped pages."

XENO_ASSERT will not be a procedure, it will be a macro containing the
check for the assertion and the code to be executed on failure. The
point is just to control if this code will make it into the kernel or
not - via CONFIG_XENO_OPT_DEBUG. Kind of #ifdef CONFIG_XENO_OPT_DEBUG,
just more comfortable. A typical bug-free driver will not need such
checks as it will just pass those values already use for or returned by
rtdm_mmap_to_user. This is not just about speed, it's also about code size.

> 
> I think that if there was an extra parameter for user_info, it would
> also verify for validity. BTW, I think there is missing some
> documentation about the user_info parameter. I had to remember our
> conversation and look at the code to understand that I should record
> "current" on this parameter on the moment I called mmap and passing it
> again on munmap. And it would be good to see the rtdm_user_info_t
> defined as struct task_struct on the documentation.

This is intentionally opaque to the driver developer. As you receive a
rtdm_user pointer via the device handler invocation (as documented in
rtdm_mmap_to_user - feel free to improve my description!), you don't
need to (and you actually shouldn't) deal with task_struct or even mm
directly.

Moreover, I have an experimental (and unreleased) Xenomai skin with RTDM
support here which maps rtdm_user_info_t to a different type.

> 
>>> I have not written the user-space program yet, so you'll have to wait
>>> until monday, when I'll be able to test it, hopefully. But it seems
>>> to be working... I changed my driver design. I do the mmap's on
>>> driver initialization and just pass the returned addresses on the
>>> IOCTL, so I can do them in a RT-context. The problem is that even if
>>> the user call an IOCTL to     
>>
>> Hmm, I guess there is still some lacking documentation about what is
>> possible with RTDM. If you call an IOCTL from RT context, you end up in
>> the _rt-handler the driver of a device may have registered (if there is
>> no _rt-handler at all, the _nrt one is invoked, but this is likely not
>> relevant here).
>>
>> I assume that you were wondering how to call rtdm_mmap_to_user from this
>> real-time handler, right?
> No. I know it is not possible from the moment. I think I did not explain
> myself very well. I was wondering how to define a RT mmap like ioctl. As
> I know I could not use rtdm_mmap_to_user then, I thought in another way
> of doing it. So I mmaped on driver initialization. On the IOCTL I just
> passed the already known addresses to the user requesting it. I would
> have to explain you how these buffers work on V4L2. It is a bit long
> explanation but I can explain it on other message if you wish.

I had a look at a V4L2 tutorial, and I think I grabbed the idea. This
idea does *not* include any mmap during runtime, just once after device
opening and buffer setup. I think you shouldn't follow the syntactic
V4L2 interface, rather grab it's overall model.

That's also why I cannot follow your desire for a transparent rt-mmap
implementation. I tried to define such a wrapper, but I didn't find it
useful, rather problematic as a lot of restrictions from the normal mmap
had to be defined.

Don't forget that normal mmap is a very generic interface, covering also
a lot of use cases (files e.g.) we will never see with RTDM. As it is
the standard interface for mapping, V4L2 likely does this split-up of
buffer allocation (via IOCTL) and mapping (via mmap). With
rtdm_mmap_to_user, this is not required! There are a few DRM Linux
driver unifying those steps as well, BTW.

> 
>> Well, the trick is to return -ENOSYS for those
>> IOCTL codes that can only be handled by the _nrt-handler. Xenomai will
>> then switch your RT task to secondary mode, restart the IOCTL, and the
>> mmap can safely be executed.
>>   
> But as I've said, it is not the behaviour I want :)
> 
>> Well, maybe you do not have any arguments for rtdm_mmap_to_user that
>> should be influenced by the user's IOCTL.
> That is my case.
> 
>> In this case your current driver design is ok as well. I just wanted
>> to underline that it is not necessarily the only way.
>>   
> But I couldn't find other way of doing it in a RT-context.

As explained before, it doesn't make sense to mmap in time-constraint
contexts, even if we are only talking about standard Linux. No
high-speed capturing application will do this - especially under Linux.

> 
>>> munmap, it will still be possible to him to continue using the
>>> provided address and this would result in a problem. But, as in all
>>> situations, there     
>>
>> When rtdm_munmap is executed, the virtual address range becomes invalid
>> for the user. Thus any further access to it will raise a segfault.
>> That's the only problem, but it will not influence the driver integrity.
>>   
> Yes, that is the problem. Since I only mark as unused on the munmap
> IOCTL, it would be possible to the user to continue using that address
> even after the munmap IOCTL call. It I was using a really rtdm_munmap,
> it wouldn't be possible. It would be a better behaviour, but it would
> not be run on RT-context. That is the trade-off.

If you avoid mmap in RT, there will also be no need for munmap in this
context. Just release it on closure.

> 
>>> are trade-offs and I prefer to rely on the user, while providing a
>>> RT-MMAP-IOCTL. Of course it isn't really a mmap, but if the user
>>> don't mess with the pointers, it will work like if it was...
>>>     
>>
>> The user can only access the window you mapped in and only as long as it
>> is mapped.
> In my case, it is always mapped to make possible the RT-IOCTLs.
>> And if you map it read-only, there is even no chance to
>> destroy potential management structures of the hardware or the driver
>> within this range.
>>   
> I do not want to make it read-only because it will probably be very
> usefull to the user to write on it. The user may want to capture a frame
> and do some image processing routines on the same memory area when it is
> possible, avoiding to copy that memory region.

I see, this makes sense. Then just prepare enough buffers for the
capturing, preprocessing, and potentially forwarding steps so that you
can continue to capture even if the user still hogs on a few previously
filled buffers. In the end it's just a cyclic process, and the only
question is how many spare buffers have to be created to keep it running.

>>> Hope you understood me, I wrote it a little confusing... :)
>>>     
>>
>> We will see...
>>   
> :)
>> Happy WE,
>>   
> Happy weekend for you too,
> 
> Rodrigo.
> 
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Rodrigo Rosenfeld Rosas]

...
>> I understand your concernings but I really don't think they are
>> relevant... This checks will be much faster then the procedure itself
>> and it would conform to normal munmap behaviour. From man page:
>>
>> "The address start must be a multiple of the page size. All pages
>> containing a part of the indicated range are unmapped, and subsequent
>> references to these pages will generate SIGSEGV. It is not an error if
>> the indicated range does not contain any mapped pages."
>>     
>
> XENO_ASSERT will not be a procedure, it will be a macro containing the
> check for the assertion and the code to be executed on failure.
Yes, I understood, I just don't agree...
> The point is just to control if this code will make it into the kernel or
> not - via CONFIG_XENO_OPT_DEBUG. Kind of #ifdef CONFIG_XENO_OPT_DEBUG,
> just more comfortable. A typical bug-free driver will not need such
> checks
I'm not very sure about that. It can work for most situations but there 
could be one situation where it would crash just because it was chosen 
to have a little smaller code size and a little speed gain... I would 
not like to think in the consequences of a crash in the driver while a 
RT-system is working on real world...
> as it will just pass those values already use for or returned by
> rtdm_mmap_to_user. This is not just about speed, it's also about code size.
>
>   
>> I think that if there was an extra parameter for user_info, it would
>> also verify for validity. BTW, I think there is missing some
>> documentation about the user_info parameter. I had to remember our
>> conversation and look at the code to understand that I should record
>> "current" on this parameter on the moment I called mmap and passing it
>> again on munmap. And it would be good to see the rtdm_user_info_t
>> defined as struct task_struct on the documentation.
>>     
>
> This is intentionally opaque to the driver developer. As you receive a
> rtdm_user pointer via the device handler invocation (as documented in
> rtdm_mmap_to_user - feel free to improve my description!), you don't
> need to (and you actually shouldn't) deal with task_struct or even mm
> directly.
>   
Sorry, I didn't understand the description in documentation and continue 
not understanding it. In which device handler invocation I did receive 
this pointer? I didn't find reference for it anywhere else...
> Moreover, I have an experimental (and unreleased) Xenomai skin with RTDM
> support here which maps rtdm_user_info_t to a different type.
>
>   
>>>> I have not written the user-space program yet, so you'll have to wait
>>>> until monday, when I'll be able to test it, hopefully. But it seems
>>>> to be working... I changed my driver design. I do the mmap's on
>>>> driver initialization and just pass the returned addresses on the
>>>> IOCTL, so I can do them in a RT-context. The problem is that even if
>>>> the user call an IOCTL to     
>>>>         
>>> Hmm, I guess there is still some lacking documentation about what is
>>> possible with RTDM. If you call an IOCTL from RT context, you end up in
>>> the _rt-handler the driver of a device may have registered (if there is
>>> no _rt-handler at all, the _nrt one is invoked, but this is likely not
>>> relevant here).
>>>
>>> I assume that you were wondering how to call rtdm_mmap_to_user from this
>>> real-time handler, right?
>>>       
>> No. I know it is not possible from the moment. I think I did not explain
>> myself very well. I was wondering how to define a RT mmap like ioctl. As
>> I know I could not use rtdm_mmap_to_user then, I thought in another way
>> of doing it. So I mmaped on driver initialization. On the IOCTL I just
>> passed the already known addresses to the user requesting it. I would
>> have to explain you how these buffers work on V4L2. It is a bit long
>> explanation but I can explain it on other message if you wish.
>>     
>
> I had a look at a V4L2 tutorial, and I think I grabbed the idea. This
> idea does *not* include any mmap during runtime, just once after device
> opening and buffer setup. I think you shouldn't follow the syntactic
> V4L2 interface, rather grab it's overall model.
>   
Yes, but it would be simpler for new developers used to the V4L2 API to 
migrate to a similar RT-Video interface. Anyway, as I've already said, I 
don't think some users would do any mmap during runtime, but maybe for 
some reconfiguration for some reason and they would like to make this in 
a RT-context. I can't really imagine a practical situation from the 
moment, but I think it is still possible to happen...
> That's also why I cannot follow your desire for a transparent rt-mmap
> implementation. I tried to define such a wrapper, but I didn't find it
> useful, rather problematic as a lot of restrictions from the normal mmap
> had to be defined.
>
> Don't forget that normal mmap is a very generic interface, covering also
> a lot of use cases (files e.g.) we will never see with RTDM. As it is
> the standard interface for mapping, V4L2 likely does this split-up of
> buffer allocation (via IOCTL) and mapping (via mmap). With
> rtdm_mmap_to_user, this is not required! There are a few DRM Linux
> driver unifying those steps as well, BTW.
>   
That is something I could change in my driver... Making the mmap on the 
VIDIOC_REQBUFS ioctl request. But, as a driver could return a different 
number of buffers than the requested, the user could not be satisfied 
with the returned buffers and the mmap would have been useless... I 
still don't know how will the final design be like, but I'm fine with 
your already provided rtdm_mmap_to_user solution. But I still want to 
keep the API as closer as possible to V4L2 for facilitating the users to 
migrate to real-time while taking advantage of the already available 
V4L2 documentation and examples all over the web and just doing the 
minimal needed modifications.
>   
>>> Well, the trick is to return -ENOSYS for those
>>> IOCTL codes that can only be handled by the _nrt-handler. Xenomai will
>>> then switch your RT task to secondary mode, restart the IOCTL, and the
>>> mmap can safely be executed.
>>>   
>>>       
>> But as I've said, it is not the behaviour I want :)
>>
>>     
>>> Well, maybe you do not have any arguments for rtdm_mmap_to_user that
>>> should be influenced by the user's IOCTL.
>>>       
>> That is my case.
>>
>>     
>>> In this case your current driver design is ok as well. I just wanted
>>> to underline that it is not necessarily the only way.
>>>   
>>>       
>> But I couldn't find other way of doing it in a RT-context.
>>     
>
> As explained before, it doesn't make sense to mmap in time-constraint
> contexts, even if we are only talking about standard Linux. No
> high-speed capturing application will do this - especially under Linux.
>   
I know that. I was just wondering if someone would need to reconfigure 
the system for some reason in a rt-context...
>   
>>>> munmap, it will still be possible to him to continue using the
>>>> provided address and this would result in a problem. But, as in all
>>>> situations, there     
>>>>         
>>> When rtdm_munmap is executed, the virtual address range becomes invalid
>>> for the user. Thus any further access to it will raise a segfault.
>>> That's the only problem, but it will not influence the driver integrity.
>>>   
>>>       
>> Yes, that is the problem. Since I only mark as unused on the munmap
>> IOCTL, it would be possible to the user to continue using that address
>> even after the munmap IOCTL call. It I was using a really rtdm_munmap,
>> it wouldn't be possible. It would be a better behaviour, but it would
>> not be run on RT-context. That is the trade-off.
>>     
>
> If you avoid mmap in RT, there will also be no need for munmap in this
> context. Just release it on closure.
>   
Not that there is a need for munmaping, but it is useful. If the user 
frees some memory when not using it anymore but is still using the file 
descriptor, that memory will be then available for use by another process.
>   
>>>> are trade-offs and I prefer to rely on the user, while providing a
>>>> RT-MMAP-IOCTL. Of course it isn't really a mmap, but if the user
>>>> don't mess with the pointers, it will work like if it was...
>>>>     
>>>>         
>>> The user can only access the window you mapped in and only as long as it
>>> is mapped.
>>>       
>> In my case, it is always mapped to make possible the RT-IOCTLs.
>>     
>>> And if you map it read-only, there is even no chance to
>>> destroy potential management structures of the hardware or the driver
>>> within this range.
>>>   
>>>       
>> I do not want to make it read-only because it will probably be very
>> usefull to the user to write on it. The user may want to capture a frame
>> and do some image processing routines on the same memory area when it is
>> possible, avoiding to copy that memory region.
>>     
>
> I see, this makes sense. Then just prepare enough buffers for the
> capturing, preprocessing, and potentially forwarding steps so that you
> can continue to capture even if the user still hogs on a few previously
> filled buffers. In the end it's just a cyclic process, and the only
> question is how many spare buffers have to be created to keep it running.
>   
This option is given to the user on V4L2 interface. That is not the 
question. The problem arises on the follow situation (I'll try to be 
more didactic this time):

1 - User A maps the buffer via ioctl.
2 - As the driver doesn't really do a mmap on ioctl, it just returns the 
addresses to be used for the user.
3 - User A frees the buffer.
4 - The driver will mark that region as free but won't do any munmap for 
keep doing it on RT-context.
5 - User B request buffer and mmap that same memory region via ioctl.
6 - Same goes on driver.
7 - A continue using the address he/she requested. If a munmap was 
really called, this would result in SEGFAULT. But, in this case, he/she 
will be able to continue messing with that area.
8 - User B will have unexpected behaviour.

That is the trade-off of using this approach for making it possible to 
deal with buffers in a RT-context...

Best Regards,

Rodrigo.


		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 12613 bytes --]

Rodrigo Rosenfeld Rosas wrote:
> ...
>>> I understand your concernings but I really don't think they are
>>> relevant... This checks will be much faster then the procedure itself
>>> and it would conform to normal munmap behaviour. From man page:
>>>
>>> "The address start must be a multiple of the page size. All pages
>>> containing a part of the indicated range are unmapped, and subsequent
>>> references to these pages will generate SIGSEGV. It is not an error if
>>> the indicated range does not contain any mapped pages."
>>>     
>>
>> XENO_ASSERT will not be a procedure, it will be a macro containing the
>> check for the assertion and the code to be executed on failure.
> Yes, I understood, I just don't agree...
>> The point is just to control if this code will make it into the kernel or
>> not - via CONFIG_XENO_OPT_DEBUG. Kind of #ifdef CONFIG_XENO_OPT_DEBUG,
>> just more comfortable. A typical bug-free driver will not need such
>> checks
> I'm not very sure about that. It can work for most situations but there
> could be one situation where it would crash just because it was chosen
> to have a little smaller code size and a little speed gain... I would
> not like to think in the consequences of a crash in the driver while a
> RT-system is working on real world...

And I would not like to think of having instrumented RTOS cores and a
drivers in the field. This would rather indicate to me that someone did
not do his/her homework: testing and debugging the system before
delivering it.

>> as it will just pass those values already use for or returned by
>> rtdm_mmap_to_user. This is not just about speed, it's also about code
>> size.
>>
>>  
>>> I think that if there was an extra parameter for user_info, it would
>>> also verify for validity. BTW, I think there is missing some
>>> documentation about the user_info parameter. I had to remember our
>>> conversation and look at the code to understand that I should record
>>> "current" on this parameter on the moment I called mmap and passing it
>>> again on munmap. And it would be good to see the rtdm_user_info_t
>>> defined as struct task_struct on the documentation.
>>>     
>>
>> This is intentionally opaque to the driver developer. As you receive a
>> rtdm_user pointer via the device handler invocation (as documented in
>> rtdm_mmap_to_user - feel free to improve my description!), you don't
>> need to (and you actually shouldn't) deal with task_struct or even mm
>> directly.
>>   
> Sorry, I didn't understand the description in documentation and continue
> not understanding it. In which device handler invocation I did receive
> this pointer? I didn't find reference for it anywhere else...

Via any invocation, just check the handler prototypes:
rtdm_open_handler_t, rtdm_close_handler_t, rtdm_ioctl_handler_t, ...

>> Moreover, I have an experimental (and unreleased) Xenomai skin with RTDM
>> support here which maps rtdm_user_info_t to a different type.
>>
>>  
>>>>> I have not written the user-space program yet, so you'll have to wait
>>>>> until monday, when I'll be able to test it, hopefully. But it seems
>>>>> to be working... I changed my driver design. I do the mmap's on
>>>>> driver initialization and just pass the returned addresses on the
>>>>> IOCTL, so I can do them in a RT-context. The problem is that even if
>>>>> the user call an IOCTL to             
>>>> Hmm, I guess there is still some lacking documentation about what is
>>>> possible with RTDM. If you call an IOCTL from RT context, you end up in
>>>> the _rt-handler the driver of a device may have registered (if there is
>>>> no _rt-handler at all, the _nrt one is invoked, but this is likely not
>>>> relevant here).
>>>>
>>>> I assume that you were wondering how to call rtdm_mmap_to_user from
>>>> this
>>>> real-time handler, right?
>>>>       
>>> No. I know it is not possible from the moment. I think I did not explain
>>> myself very well. I was wondering how to define a RT mmap like ioctl. As
>>> I know I could not use rtdm_mmap_to_user then, I thought in another way
>>> of doing it. So I mmaped on driver initialization. On the IOCTL I just
>>> passed the already known addresses to the user requesting it. I would
>>> have to explain you how these buffers work on V4L2. It is a bit long
>>> explanation but I can explain it on other message if you wish.
>>>     
>>
>> I had a look at a V4L2 tutorial, and I think I grabbed the idea. This
>> idea does *not* include any mmap during runtime, just once after device
>> opening and buffer setup. I think you shouldn't follow the syntactic
>> V4L2 interface, rather grab it's overall model.
>>   
> Yes, but it would be simpler for new developers used to the V4L2 API to
> migrate to a similar RT-Video interface. Anyway, as I've already said, I
> don't think some users would do any mmap during runtime, but maybe for
> some reconfiguration for some reason and they would like to make this in
> a RT-context. I can't really imagine a practical situation from the
> moment, but I think it is still possible to happen...

Ok, but then you can still offer mmap via secondary mode even to RT
tasks. It's a corner case, and mmap will never have a deterministic
execution time without changing the vmm rather fundamentally, so the
user can't expect such behaviour. If (s)he does so, the application
design is broken anyway.

>> That's also why I cannot follow your desire for a transparent rt-mmap
>> implementation. I tried to define such a wrapper, but I didn't find it
>> useful, rather problematic as a lot of restrictions from the normal mmap
>> had to be defined.
>>
>> Don't forget that normal mmap is a very generic interface, covering also
>> a lot of use cases (files e.g.) we will never see with RTDM. As it is
>> the standard interface for mapping, V4L2 likely does this split-up of
>> buffer allocation (via IOCTL) and mapping (via mmap). With
>> rtdm_mmap_to_user, this is not required! There are a few DRM Linux
>> driver unifying those steps as well, BTW.
>>   
> That is something I could change in my driver... Making the mmap on the
> VIDIOC_REQBUFS ioctl request. But, as a driver could return a different
> number of buffers than the requested, the user could not be satisfied
> with the returned buffers and the mmap would have been useless... I
> still don't know how will the final design be like, but I'm fine with
> your already provided rtdm_mmap_to_user solution. But I still want to
> keep the API as closer as possible to V4L2 for facilitating the users to
> migrate to real-time while taking advantage of the already available
> V4L2 documentation and examples all over the web and just doing the
> minimal needed modifications.

Ok, I see the idea behind it, and under those constraints it does make
sense to provide some wrapper for mmap over the RT capturing device.

>>  
>>>> Well, the trick is to return -ENOSYS for those
>>>> IOCTL codes that can only be handled by the _nrt-handler. Xenomai will
>>>> then switch your RT task to secondary mode, restart the IOCTL, and the
>>>> mmap can safely be executed.
>>>>         
>>> But as I've said, it is not the behaviour I want :)
>>>
>>>    
>>>> Well, maybe you do not have any arguments for rtdm_mmap_to_user that
>>>> should be influenced by the user's IOCTL.
>>>>       
>>> That is my case.
>>>
>>>    
>>>> In this case your current driver design is ok as well. I just wanted
>>>> to underline that it is not necessarily the only way.
>>>>         
>>> But I couldn't find other way of doing it in a RT-context.
>>>     
>>
>> As explained before, it doesn't make sense to mmap in time-constraint
>> contexts, even if we are only talking about standard Linux. No
>> high-speed capturing application will do this - especially under Linux.
>>   
> I know that. I was just wondering if someone would need to reconfigure
> the system for some reason in a rt-context...
>>  
>>>>> munmap, it will still be possible to him to continue using the
>>>>> provided address and this would result in a problem. But, as in all
>>>>> situations, there             
>>>> When rtdm_munmap is executed, the virtual address range becomes invalid
>>>> for the user. Thus any further access to it will raise a segfault.
>>>> That's the only problem, but it will not influence the driver
>>>> integrity.
>>>>         
>>> Yes, that is the problem. Since I only mark as unused on the munmap
>>> IOCTL, it would be possible to the user to continue using that address
>>> even after the munmap IOCTL call. It I was using a really rtdm_munmap,
>>> it wouldn't be possible. It would be a better behaviour, but it would
>>> not be run on RT-context. That is the trade-off.
>>>     
>>
>> If you avoid mmap in RT, there will also be no need for munmap in this
>> context. Just release it on closure.
>>   
> Not that there is a need for munmaping, but it is useful. If the user
> frees some memory when not using it anymore but is still using the file
> descriptor, that memory will be then available for use by another process.
>>  
>>>>> are trade-offs and I prefer to rely on the user, while providing a
>>>>> RT-MMAP-IOCTL. Of course it isn't really a mmap, but if the user
>>>>> don't mess with the pointers, it will work like if it was...
>>>>>             
>>>> The user can only access the window you mapped in and only as long
>>>> as it
>>>> is mapped.
>>>>       
>>> In my case, it is always mapped to make possible the RT-IOCTLs.
>>>    
>>>> And if you map it read-only, there is even no chance to
>>>> destroy potential management structures of the hardware or the driver
>>>> within this range.
>>>>         
>>> I do not want to make it read-only because it will probably be very
>>> usefull to the user to write on it. The user may want to capture a frame
>>> and do some image processing routines on the same memory area when it is
>>> possible, avoiding to copy that memory region.
>>>     
>>
>> I see, this makes sense. Then just prepare enough buffers for the
>> capturing, preprocessing, and potentially forwarding steps so that you
>> can continue to capture even if the user still hogs on a few previously
>> filled buffers. In the end it's just a cyclic process, and the only
>> question is how many spare buffers have to be created to keep it running.
>>   
> This option is given to the user on V4L2 interface. That is not the
> question. The problem arises on the follow situation (I'll try to be
> more didactic this time):
> 
> 1 - User A maps the buffer via ioctl.
> 2 - As the driver doesn't really do a mmap on ioctl, it just returns the
> addresses to be used for the user.
> 3 - User A frees the buffer.
> 4 - The driver will mark that region as free but won't do any munmap for
> keep doing it on RT-context.
> 5 - User B request buffer and mmap that same memory region via ioctl.
> 6 - Same goes on driver.
> 7 - A continue using the address he/she requested. If a munmap was
> really called, this would result in SEGFAULT. But, in this case, he/she
> will be able to continue messing with that area.
> 8 - User B will have unexpected behaviour.
> 
> That is the trade-off of using this approach for making it possible to
> deal with buffers in a RT-context...

I think I now got your goals completely:

 1. keep the interface of V4L2
 2. completely provide it a deterministic way

I can understand the first goal. Keeping the V4L2 interface for a
potential RTDM frame grabbing device profile can make sense if it
doesn't complicate the rt-driver internals too much or stresses it
rt-guarantees.

But I still have some doubts that aiming for 2. regarding mmap is worth
the effort. The problem is that you cannot predict how many buffers have
to be pre-mapped in order to provide them with bounded delay via some
rt-mmap. I wouldn't spent time on this.

Ok, but even if you decide to let rt-mmap be non-deterministic, you
still need some means to prevent the scenario you described above.
Actually, all you need is some callback when the mapped memory block was
actually released (munmap/application exit). Such a callback can be
registered inside the rtdm_mmap handler as a vma_fileop. It will run in
non-RT, and could be used to mark the related hardware buffer as finally
free for re-allocation. I will draft some extension of the current
rtdm_mmap_to_user function, but likely not before tomorrow evening or so.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Rodrigo Rosenfeld Rosas]

Jan Kiszka escreveu:
> ...
>> I'm not very sure about that. It can work for most situations but there
>> could be one situation where it would crash just because it was chosen
>> to have a little smaller code size and a little speed gain... I would
>> not like to think in the consequences of a crash in the driver while a
>> RT-system is working on real world...
>>     
>
> And I would not like to think of having instrumented RTOS cores and a
> drivers in the field. This would rather indicate to me that someone did
> not do his/her homework: testing and debugging the system before
> delivering it.
>   
Ok, I'm not really interested on this topic for continue discussing it. 
It is fine for me to do that checks on my own code before calling 
rtdm_mmap_to_user...
> ...
> Via any invocation, just check the handler prototypes:
> rtdm_open_handler_t, rtdm_close_handler_t, rtdm_ioctl_handler_t, ...
>   
Now I've found them! I think I was a bit lazy at that time... :) Thanks!

>>> ...  
>>>       
>> Yes, but it would be simpler for new developers used to the V4L2 API to
>> migrate to a similar RT-Video interface. Anyway, as I've already said, I
>> don't think some users would do any mmap during runtime, but maybe for
>> some reconfiguration for some reason and they would like to make this in
>> a RT-context. I can't really imagine a practical situation from the
>> moment, but I think it is still possible to happen...
>>     
>
> Ok, but then you can still offer mmap via secondary mode even to RT
> tasks.
But I would lose the determinism...
> It's a corner case, and mmap will never have a deterministic
> execution time without changing the vmm rather fundamentally, so the
> user can't expect such behaviour. If (s)he does so, the application
> design is broken anyway.
>   
I agree. That is why I'm trying to provide an alternative solution. It 
is not quite a mmap, but it is similar...

>>> ...  
>>>       
>> That is something I could change in my driver... Making the mmap on the
>> VIDIOC_REQBUFS ioctl request. But, as a driver could return a different
>> number of buffers than the requested, the user could not be satisfied
>> with the returned buffers and the mmap would have been useless... I
>> still don't know how will the final design be like, but I'm fine with
>> your already provided rtdm_mmap_to_user solution. But I still want to
>> keep the API as closer as possible to V4L2 for facilitating the users to
>> migrate to real-time while taking advantage of the already available
>> V4L2 documentation and examples all over the web and just doing the
>> minimal needed modifications.
>>     
>
> Ok, I see the idea behind it, and under those constraints it does make
> sense to provide some wrapper for mmap over the RT capturing device.
>
> ...
> I think I now got your goals completely:
>
>  1. keep the interface of V4L2
>   
... as closer as possible.
>  2. completely provide it a deterministic way
>   
I'm not really worried about that, but if I could do it in some not very 
sofisticated way, I would like to provide such behaviour. But I 
recognize that for must situations the user won't need deterministic mmap.
> I can understand the first goal. Keeping the V4L2 interface for a
> potential RTDM frame grabbing device profile can make sense if it
> doesn't complicate the rt-driver internals too much or stresses it
> rt-guarantees.
>
> But I still have some doubts that aiming for 2. regarding mmap is worth
> the effort. The problem is that you cannot predict how many buffers have
> to be pre-mapped in order to provide them with bounded delay via some
> rt-mmap. I wouldn't spent time on this.
>   
This could be another module parameter. If the user is not satisfied 
with the default limits, (s)he could override them. But I really don't 
pretend to spent more time on this... I'm very worried about my 
deadline... :( I still have too much to do in 4 months... :((
> Ok, but even if you decide to let rt-mmap be non-deterministic, you
> still need some means to prevent the scenario you described above.
> Actually, all you need is some callback when the mapped memory block was
> actually released (munmap/application exit). Such a callback can be
> registered inside the rtdm_mmap handler as a vma_fileop.
I have never worked with vma_fileop... I would need to learn it first.
>  It will run in
> non-RT, and could be used to mark the related hardware buffer as finally
> free for re-allocation.
Now, I did realize that there is one more problem on my current design. 
If the user application exits or is terminated, I'm not sure if the 
close handler is called if the user forgot/was not able to. If it is 
not, the buffer would be marked as used until I reloaded the driver... 
Is the close handler invocated on application termination?
> I will draft some extension of the current
> rtdm_mmap_to_user function, but likely not before tomorrow evening or so.
>   
Thank you.

Rodrigo.


	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Jan Kiszka]

[-- Attachment #1.1: Type: text/plain, Size: 1926 bytes --]

Rodrigo Rosenfeld Rosas wrote:
> Jan Kiszka escreveu:
>> Ok, but even if you decide to let rt-mmap be non-deterministic, you
>> still need some means to prevent the scenario you described above.
>> Actually, all you need is some callback when the mapped memory block was
>> actually released (munmap/application exit). Such a callback can be
>> registered inside the rtdm_mmap handler as a vma_fileop.
> I have never worked with vma_fileop... I would need to learn it first.

Here is the patch to offer you access to those ops. Revert the previous
version, then apply this one. It still needs some final documentation
notes and a test on kernel 2.4. But is should already work on 2.6.

I also attached a demo for the handler usage based on my previous test
framework. Just grab the pattern and put some useful code in the close
handler...

>>  It will run in
>> non-RT, and could be used to mark the related hardware buffer as finally
>> free for re-allocation.
> Now, I did realize that there is one more problem on my current design.
> If the user application exits or is terminated, I'm not sure if the
> close handler is called if the user forgot/was not able to. If it is
> not, the buffer would be marked as used until I reloaded the driver...
> Is the close handler invocated on application termination?

Yep, this is a general issue you cannot avoid: all skin objects besides
task are only released when the user-space application cleans it up as
it's ought to. There is no tracking of used resources, no auto-cleanup.
If your application fails to close a device or socket, you will get a
stalled handle which can be found in /proc/xenomai/rtdm/open_files.
Writing the file descriptor number to this particular proc-file (e.g.
"echo 3 > /proc/xeno...") will trigger an enforced close and will
release the file descriptor again. Useful when debugging such broken
applications.

Jan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: rtdm_mmap-v3.patch --]
[-- Type: text/x-patch; name="rtdm_mmap-v3.patch", Size: 6356 bytes --]

Index: include/rtdm/rtdm_driver.h
===================================================================
--- include/rtdm/rtdm_driver.h	(Revision 564)
+++ include/rtdm/rtdm_driver.h	(Arbeitskopie)
@@ -995,6 +995,12 @@
     xnfree(ptr);
 }
 
+int rtdm_mmap_to_user(rtdm_user_info_t *user_info, void *src_addr, size_t len,
+                      int prot, void **pptr,
+                      struct vm_operations_struct *vm_ops,
+                      void *vm_private_data);
+int rtdm_munmap(rtdm_user_info_t *user_info, void *ptr, size_t len);
+
 static inline int rtdm_read_user_ok(rtdm_user_info_t *user_info,
                                     const void __user *ptr, size_t size)
 {
Index: ksrc/skins/rtdm/drvlib.c
===================================================================
--- ksrc/skins/rtdm/drvlib.c	(Revision 564)
+++ ksrc/skins/rtdm/drvlib.c	(Arbeitskopie)
@@ -31,6 +31,7 @@
 
 
 #include <linux/delay.h>
+#include <linux/mman.h>
 
 #include <rtdm/rtdm_driver.h>
 
@@ -1286,7 +1287,7 @@
  * Rescheduling: never.
  */
 int rtdm_irq_disable(rtdm_irq_t *irq_handle);
-/** @} */
+/** @} Interrupt Management Services */
 
 
 /*!
@@ -1358,16 +1359,158 @@
  * environments.
  */
 void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig);
-/** @} */
+/** @} Non-Real-Time Signalling Services */
 
+#endif /* DOXYGEN_CPP */
 
+
 /*!
  * @ingroup driverapi
  * @defgroup util Utility Services
  * @{
  */
 
+struct rtdm_mmap_data {
+    void *src_addr;
+    struct vm_operations_struct *vm_ops;
+    void *vm_private_data;
+};
+
+static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct *vma)
+{
+    struct rtdm_mmap_data *mmap_data = filp->private_data;
+
+    vma->vm_ops = mmap_data->vm_ops;
+    vma->vm_private_data = mmap_data->vm_private_data;
+
+    return xnarch_remap_page_range(vma, vma->vm_start,
+                                   virt_to_phys(mmap_data->src_addr),
+                                   vma->vm_end - vma->vm_start, PAGE_SHARED);
+}
+
+static struct file_operations rtdm_mmap_fops = {
+    .mmap = rtdm_mmap_buffer,
+};
+
 /**
+ * Map a kernel memory range into the address space of the user.
+ *
+ * @param[in] user_info User information pointer as passed to the invoked
+ * device operation handler
+ * @param[in] src_addr Kernel address to be mapped
+ * @param[in] len Length of the memory range
+ * @param[in] prot Protection flags for the user's memory range, typically
+ * either PROT_READ or PROT_READ|PROT_WRITE
+ * @param[in,out] pptr Address of a pointer containing the desired user
+ * address or NULL on entry and the finally assigned address on return
+ * @param[in] vm_ops vm_operations to be executed on the vma_area of the
+ * user memory range or NULL
+ * @param[in] vm_private_data Private data to be stored in the vma_area,
+ * primarily useful for vm_operation handlers
+ *
+ * @return 0 on success, otherwise:
+ *
+ * - -EXXX is returned if .
+ *
+ * @note RTDM supports two models for unmapping the user memory range again.
+ * One is explicite unmapping via rtdm_munmap(), either performed when the
+ * user requests it via an IOCTL etc. or when the related device is closed.
+ * The other is automatic unmapping, triggered by the user invoking standard
+ * munmap() or by the termination of the related process. To track release of
+ * the mapping and therefore relinquishment of the referenced physical memory,
+ * the caller of rtdm_mmap_to_user() can pass a vm_operations_struct on
+ * invocation, defining a close handler for the vm_area. See Linux
+ * documentaion (e.g. Linux Device Drivers book) on virtual memory management
+ * for details.
+ *
+ * Environments:
+ *
+ * This service can be called from:
+ *
+ * - Kernel module initialization/cleanup code
+ * - User-space task (non-RT)
+ *
+ * Rescheduling: possible.
+ */
+int rtdm_mmap_to_user(rtdm_user_info_t *user_info, void *src_addr, size_t len,
+                      int prot, void **pptr,
+                      struct vm_operations_struct *vm_ops,
+                      void *vm_private_data)
+{
+    struct rtdm_mmap_data   mmap_data = {src_addr, vm_ops, vm_private_data};
+    struct file             *filp;
+    struct file_operations  *old_fops;
+    void                    *old_priv_data;
+    void                    *user_ptr;
+
+    filp = filp_open("/dev/zero", O_RDWR, 0);
+    if (IS_ERR(filp))
+        return PTR_ERR(filp);
+
+    old_fops = filp->f_op;
+    filp->f_op = &rtdm_mmap_fops;
+
+    old_priv_data = filp->private_data;
+    filp->private_data = &mmap_data;
+
+    down_write(&user_info->mm->mmap_sem);
+    user_ptr = (void *)do_mmap(filp, (unsigned long)*pptr, len, prot,
+                               MAP_SHARED, 0);
+    up_write(&user_info->mm->mmap_sem);
+
+    filp->f_op = old_fops;
+    filp->private_data = old_priv_data;
+
+    filp_close(filp, user_info->files);
+
+    if (IS_ERR(user_ptr))
+        return PTR_ERR(user_ptr);
+
+    *pptr = user_ptr;
+    return 0;
+}
+
+EXPORT_SYMBOL(rtdm_mmap_to_user);
+
+
+/**
+ * Unmap a user memory range.
+ *
+ * @param[in] user_info User information pointer as passed to
+ * rtdm_mmap_to_user() when requesting to map the memory range
+ * @param[in] ptr User address or the memory range
+ * @param[in] len Length of the memory range
+ *
+ * @return 0 on success, otherwise:
+ *
+ * - -EXXX is returned if .
+ *
+ * Environments:
+ *
+ * This service can be called from:
+ *
+ * - Kernel module initialization/cleanup code
+ * - User-space task (non-RT)
+ *
+ * Rescheduling: possible.
+ */
+int rtdm_munmap(rtdm_user_info_t *user_info, void *ptr, size_t len)
+{
+    int err;
+
+    down_write(&user_info->mm->mmap_sem);
+    err = do_munmap(user_info->mm, (unsigned long)ptr, len);
+    up_write(&user_info->mm->mmap_sem);
+
+    return err;
+}
+
+EXPORT_SYMBOL(rtdm_munmap);
+
+
+#ifdef DOXYGEN_CPP /* Only used for doxygen doc generation */
+
+/**
  * Real-time safe message printing on kernel console
  *
  * @param[in] format Format string (conforming standard @c printf())
@@ -1583,6 +1726,6 @@
  */
 int rtdm_in_rt_context(void);
 
-/** @} */
+#endif /* DOXYGEN_CPP */
 
-#endif /* DOXYGEN_CPP */
+/** @} Utility Services */

[-- Attachment #1.3: rtmmap_drv.c --]
[-- Type: text/plain, Size: 3271 bytes --]

#include <linux/mman.h>

#include <rtdm/rtdm_driver.h>


#define BUFFER_SIZE     100000


struct demodrv_context {
    void *buf;
};


static void demo_vm_close(struct vm_area_struct *vma)
{
    printk("releasing %p, data = %p\n", vma, vma->vm_private_data);
}


static struct vm_operations_struct mmap_ops = {
    .close = demo_vm_close,
};


int demo_open_rt(struct rtdm_dev_context    *context,
                 rtdm_user_info_t           *user_info,
                 int                        oflags)
{
    struct demodrv_context  *my_context;
    unsigned long vaddr;


    my_context = (struct demodrv_context *)context->dev_private;

    my_context->buf = kmalloc(BUFFER_SIZE, 0);
    /* mark pages reserved so that remap_pfn_range works */
    for (vaddr = (unsigned long)my_context->buf;
         vaddr < (unsigned long)my_context->buf + BUFFER_SIZE;
         vaddr += PAGE_SIZE)
        SetPageReserved(virt_to_page(vaddr));
    *(int *)my_context->buf = 1234;

    return 0;
}


int demo_close_rt(struct rtdm_dev_context   *context,
                  rtdm_user_info_t          *user_info)
{
    struct demodrv_context  *my_context;


    my_context = (struct demodrv_context *)context->dev_private;

    printk("%d\n", *((int *)my_context->buf + 1000));

    kfree(my_context->buf);

    return 0;
}


int demo_ioctl_rt(struct rtdm_dev_context   *context,
                  rtdm_user_info_t          *user_info,
                  int                       request,
                  void                      *arg)
{
    struct demodrv_context  *my_context;
    int err;


    my_context = (struct demodrv_context *)context->dev_private;

    printk("buf = %p:%x\n", my_context->buf, *(int *)my_context->buf);

    err = rtdm_mmap_to_user(user_info, my_context->buf, BUFFER_SIZE,
                            PROT_READ|PROT_WRITE, (void **)arg, &mmap_ops,
                            0x12345678);
    printk("rtdm_mmap = %p %d\n", *(void **)arg, err);

    return 0;
}


static struct rtdm_device demo_device = {
    struct_version:     RTDM_DEVICE_STRUCT_VER,

    device_flags:       RTDM_NAMED_DEVICE,
    context_size:       sizeof(struct demodrv_context),
    device_name:        "demodev0",

    open_rt:            NULL,
    open_nrt:           demo_open_rt,

    ops: {
        close_rt:       NULL,
        close_nrt:      demo_close_rt,

        ioctl_rt:       NULL,
        ioctl_nrt:      demo_ioctl_rt,

        read_rt:        NULL,
        read_nrt:       NULL,

        write_rt:       NULL,
        write_nrt:      NULL,

        recvmsg_rt:     NULL,
        recvmsg_nrt:    NULL,

        sendmsg_rt:     NULL,
        sendmsg_nrt:    NULL,
    },

    device_class:       RTDM_CLASS_EXPERIMENTAL,
    device_sub_class:   222,
    driver_name:        "demodrv",
    peripheral_name:    "demodev",
    provider_name:      "-",
    proc_name:          demo_device.device_name,
};

int init_module(void)
{
    int ret;


    ret = rtdm_dev_register(&demo_device);
    printk("rtdm_dev_register = %d\n", ret);

    return ret;
}


void cleanup_module(void)
{
    rtdm_dev_unregister(&demo_device, 1000);
}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Rodrigo Rosenfeld Rosas]

Jan Kiszka escreveu:

>Rodrigo Rosenfeld Rosas wrote:
>  
>
>>Jan Kiszka escreveu:
>>    
>>
>>>Ok, but even if you decide to let rt-mmap be non-deterministic, you
>>>still need some means to prevent the scenario you described above.
>>>Actually, all you need is some callback when the mapped memory block was
>>>actually released (munmap/application exit). Such a callback can be
>>>registered inside the rtdm_mmap handler as a vma_fileop.
>>>      
>>>
>>I have never worked with vma_fileop... I would need to learn it first.
>>    
>>
>
>Here is the patch to offer you access to those ops. Revert the previous
>version, then apply this one.
>
Actually I would have to revert the modifications I had to do for the 
patch to apply (some rejected chunks). But I think I'll update to the 
last SVN xenomai. BTW, is this patch for the SVN or 2.1 or 2.0.2 
xenomai? Or it would apply for all of them?

> It still needs some final documentation
>notes and a test on kernel 2.4. But is should already work on 2.6.
>  
>
I forgot to mention, I have one more problem. Since I call mmap on 
driver initialization (thus before any rtdm_dev_open), I do not have any 
rtdm_user_info_t, so I need to use current instead, but I'm not sure if 
this will work. Maybe mmap needs the 'current' struct of the user 
program... I don't know this very well... If that is true, so I'll have 
to do the maps in a non-rt context anyway...

>I also attached a demo for the handler usage based on my previous test
>framework. Just grab the pattern and put some useful code in the close
>handler...
>
>  
>
>>> It will run in
>>>non-RT, and could be used to mark the related hardware buffer as finally
>>>free for re-allocation.
>>>      
>>>
>>Now, I did realize that there is one more problem on my current design.
>>If the user application exits or is terminated, I'm not sure if the
>>close handler is called if the user forgot/was not able to. If it is
>>not, the buffer would be marked as used until I reloaded the driver...
>>Is the close handler invocated on application termination?
>>    
>>
>
>Yep, this is a general issue you cannot avoid: all skin objects besides
>task are only released when the user-space application cleans it up as
>it's ought to. There is no tracking of used resources, no auto-cleanup.
>If your application fails to close a device or socket, you will get a
>stalled handle which can be found in /proc/xenomai/rtdm/open_files.
>Writing the file descriptor number to this particular proc-file (e.g.
>"echo 3 > /proc/xeno...") will trigger an enforced close and will
>release the file descriptor again. Useful when debugging such broken
>applications.
>  
>
Yes, sorry... I forgot I've already read this... :)

Rodrigo.


	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3462 bytes --]

Rodrigo Rosenfeld Rosas wrote:
> Jan Kiszka escreveu:
> 
>> Rodrigo Rosenfeld Rosas wrote:
>>  
>>
>>> Jan Kiszka escreveu:
>>>   
>>>> Ok, but even if you decide to let rt-mmap be non-deterministic, you
>>>> still need some means to prevent the scenario you described above.
>>>> Actually, all you need is some callback when the mapped memory block
>>>> was
>>>> actually released (munmap/application exit). Such a callback can be
>>>> registered inside the rtdm_mmap handler as a vma_fileop.
>>>>     
>>> I have never worked with vma_fileop... I would need to learn it first.
>>>   
>>
>> Here is the patch to offer you access to those ops. Revert the previous
>> version, then apply this one.
>>
> Actually I would have to revert the modifications I had to do for the
> patch to apply (some rejected chunks). But I think I'll update to the
> last SVN xenomai. BTW, is this patch for the SVN or 2.1 or 2.0.2
> xenomai? Or it would apply for all of them?

Developed and tested against 2.1. The current patch will not cleanly
apply against 2.0.

> 
>> It still needs some final documentation
>> notes and a test on kernel 2.4. But is should already work on 2.6.
>>  
>>
> I forgot to mention, I have one more problem. Since I call mmap on
> driver initialization (thus before any rtdm_dev_open), I do not have any
> rtdm_user_info_t, so I need to use current instead, but I'm not sure if
> this will work. Maybe mmap needs the 'current' struct of the user
> program... I don't know this very well... If that is true, so I'll have
> to do the maps in a non-rt context anyway...

You cannot mmap before you know precisely for which user this should
take place. During init, it's the insmod/modprobe process - likely not
the one you are interested in. So the earliest point for mmap is device
open. If this is too late for you, then now finally forget about this
pre-mmapping and turn it into a normal function for secondary mode. It
will be hard anyway to find a user who will notice the difference.

> 
>> I also attached a demo for the handler usage based on my previous test
>> framework. Just grab the pattern and put some useful code in the close
>> handler...
>>
>>  
>>
>>>> It will run in
>>>> non-RT, and could be used to mark the related hardware buffer as
>>>> finally
>>>> free for re-allocation.
>>>>     
>>> Now, I did realize that there is one more problem on my current design.
>>> If the user application exits or is terminated, I'm not sure if the
>>> close handler is called if the user forgot/was not able to. If it is
>>> not, the buffer would be marked as used until I reloaded the driver...
>>> Is the close handler invocated on application termination?
>>>   
>>
>> Yep, this is a general issue you cannot avoid: all skin objects besides
>> task are only released when the user-space application cleans it up as
>> it's ought to. There is no tracking of used resources, no auto-cleanup.
>> If your application fails to close a device or socket, you will get a
>> stalled handle which can be found in /proc/xenomai/rtdm/open_files.
>> Writing the file descriptor number to this particular proc-file (e.g.
>> "echo 3 > /proc/xeno...") will trigger an enforced close and will
>> release the file descriptor again. Useful when debugging such broken
>> applications.
>>  
>>
> Yes, sorry... I forgot I've already read this... :)
> 
> Rodrigo.
> 
> 

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Rodrigo Rosenfeld Rosas]

Em Ter=E7a 14 Fevereiro 2006 05:55, voc=EA escreveu:
>Rodrigo Rosenfeld Rosas wrote:
>> Jan Kiszka escreveu:
>>> Rodrigo Rosenfeld Rosas wrote:
>>>> Jan Kiszka escreveu:
>>>>> Ok, but even if you decide to let rt-mmap be non-deterministic, you
>>>>> still need some means to prevent the scenario you described above.
>>>>> Actually, all you need is some callback when the mapped memory block
>>>>> was
>>>>> actually released (munmap/application exit). Such a callback can be
>>>>> registered inside the rtdm_mmap handler as a vma_fileop.
>>>>
>>>> I have never worked with vma_fileop... I would need to learn it first.
>>>
>>> Here is the patch to offer you access to those ops. Revert the previous
>>> version, then apply this one.
>>
>> Actually I would have to revert the modifications I had to do for the
>> patch to apply (some rejected chunks). But I think I'll update to the
>> last SVN xenomai. BTW, is this patch for the SVN or 2.1 or 2.0.2
>> xenomai? Or it would apply for all of them?
>
>Developed and tested against 2.1. The current patch will not cleanly
>apply against 2.0.

Ok, it already applied cleanly on last svn version. I'll reboot my computer
and test it. That is something I didn't like in 2.1 series... I always have
to recompile the kernel and to reboot when a new xenomai release is availab=
le
(unless I'm missing something)... On the previous series I just compiled it
as modules and it was only necessary to recompile the kernel when a new ade=
os
(ipipe) version was available...

>>> It still needs some final documentation
>>> notes and a test on kernel 2.4. But is should already work on 2.6.
>>
>> I forgot to mention, I have one more problem. Since I call mmap on
>> driver initialization (thus before any rtdm_dev_open), I do not have any
>> rtdm_user_info_t, so I need to use current instead, but I'm not sure if
>> this will work. Maybe mmap needs the 'current' struct of the user
>> program... I don't know this very well... If that is true, so I'll have
>> to do the maps in a non-rt context anyway...
>
>You cannot mmap before you know precisely for which user this should
>take place.

Do you mean that if I use the 'current' and current->mm struct of the drive=
r,
when mmaping, the user won't be able to use the returned pointer?

>During init, it's the insmod/modprobe process - likely not
>the one you are interested in.

Actually, that is the way I was planning for making the maping in a
deterministic way...

>So the earliest point for mmap is device
>open. If this is too late for you, then now finally forget about this
>pre-mmapping and turn it into a normal function for secondary mode. It
>will be hard anyway to find a user who will notice the difference.

That is not a question of noting any difference or not... An application can
works great most of the time but it can fail under some not common
circunstances. The user will need to know, at least, that he will can not
rely on rt-capabilities when doing that and will be forced to do that only =
on
initialization. But that is ok for most cases. I think I'll do that (I do n=
ot
have other options at all :) ).

Thanks,

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Philippe Gerum]

Rodrigo Rosenfeld Rosas wrote:
> Em Terça 14 Fevereiro 2006 05:55, você escreveu:
> 
>>Rodrigo Rosenfeld Rosas wrote:
>>
>>>Jan Kiszka escreveu:
>>>
>>>>Rodrigo Rosenfeld Rosas wrote:
>>>>
>>>>>Jan Kiszka escreveu:
>>>>>
>>>>>>Ok, but even if you decide to let rt-mmap be non-deterministic, you
>>>>>>still need some means to prevent the scenario you described above.
>>>>>>Actually, all you need is some callback when the mapped memory block
>>>>>>was
>>>>>>actually released (munmap/application exit). Such a callback can be
>>>>>>registered inside the rtdm_mmap handler as a vma_fileop.
>>>>>
>>>>>I have never worked with vma_fileop... I would need to learn it first.
>>>>
>>>>Here is the patch to offer you access to those ops. Revert the previous
>>>>version, then apply this one.
>>>
>>>Actually I would have to revert the modifications I had to do for the
>>>patch to apply (some rejected chunks). But I think I'll update to the
>>>last SVN xenomai. BTW, is this patch for the SVN or 2.1 or 2.0.2
>>>xenomai? Or it would apply for all of them?
>>
>>Developed and tested against 2.1. The current patch will not cleanly
>>apply against 2.0.
> 
> 
> Ok, it already applied cleanly on last svn version. I'll reboot my computer
> and test it. That is something I didn't like in 2.1 series... I always have
> to recompile the kernel and to reboot when a new xenomai release is available
> (unless I'm missing something)... On the previous series I just compiled it
> as modules and it was only necessary to recompile the kernel when a new adeos
> (ipipe) version was available...

What about building the Xenomai support as modules instead of statically into the 
kernel?

> 
> 
>>>>It still needs some final documentation
>>>>notes and a test on kernel 2.4. But is should already work on 2.6.
>>>
>>>I forgot to mention, I have one more problem. Since I call mmap on
>>>driver initialization (thus before any rtdm_dev_open), I do not have any
>>>rtdm_user_info_t, so I need to use current instead, but I'm not sure if
>>>this will work. Maybe mmap needs the 'current' struct of the user
>>>program... I don't know this very well... If that is true, so I'll have
>>>to do the maps in a non-rt context anyway...
>>
>>You cannot mmap before you know precisely for which user this should
>>take place.
> 
> 
> Do you mean that if I use the 'current' and current->mm struct of the driver,
> when mmaping, the user won't be able to use the returned pointer?
> 
> 
>>During init, it's the insmod/modprobe process - likely not
>>the one you are interested in.
> 
> 
> Actually, that is the way I was planning for making the maping in a
> deterministic way...
> 
> 
>>So the earliest point for mmap is device
>>open. If this is too late for you, then now finally forget about this
>>pre-mmapping and turn it into a normal function for secondary mode. It
>>will be hard anyway to find a user who will notice the difference.
> 
> 
> That is not a question of noting any difference or not... An application can
> works great most of the time but it can fail under some not common
> circunstances. The user will need to know, at least, that he will can not
> rely on rt-capabilities when doing that and will be forced to do that only on
> initialization. But that is ok for most cases. I think I'll do that (I do not
> have other options at all :) ).
> 
> Thanks,
> 
> Rodrigo.
> 
> 		
> _______________________________________________________
> Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
> http://br.acesso.yahoo.com
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 

Philippe.

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]

Rodrigo Rosenfeld Rosas wrote:
> Em Terça 14 Fevereiro 2006 05:55, você escreveu:
>> Rodrigo Rosenfeld Rosas wrote:
>>> I forgot to mention, I have one more problem. Since I call mmap on
>>> driver initialization (thus before any rtdm_dev_open), I do not have any
>>> rtdm_user_info_t, so I need to use current instead, but I'm not sure if
>>> this will work. Maybe mmap needs the 'current' struct of the user
>>> program... I don't know this very well... If that is true, so I'll have
>>> to do the maps in a non-rt context anyway...
>> You cannot mmap before you know precisely for which user this should
>> take place.
> 
> Do you mean that if I use the 'current' and current->mm struct of the driver,
> when mmaping, the user won't be able to use the returned pointer?

To mmap you need to know the target process, more precisely its mm. This
is typically derived from the invocation context of the service call
("current" is a pointer to the current process). But init_module runs in
the context of modprobe. Even worse, the process later opening and
mapping some buffer may not even exist at that time!

> 
>> During init, it's the insmod/modprobe process - likely not
>> the one you are interested in.
> 
> Actually, that is the way I was planning for making the maping in a
> deterministic way...
> 
>> So the earliest point for mmap is device
>> open. If this is too late for you, then now finally forget about this
>> pre-mmapping and turn it into a normal function for secondary mode. It
>> will be hard anyway to find a user who will notice the difference.
> 
> That is not a question of noting any difference or not... An application can
> works great most of the time but it can fail under some not common
> circunstances. The user will need to know, at least, that he will can not
> rely on rt-capabilities when doing that and will be forced to do that only on
> initialization. But that is ok for most cases. I think I'll do that (I do not
> have other options at all :) ).

Just place enough warning signs in your documentation around the
mmap-wrapper you provide, saying that no one should expect bounded
delays from this service.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Rodrigo Rosenfeld Rosas]

Em Ter=E7a 14 Fevereiro 2006 22:30, Jan Kiszka escreveu:

>...
>>> You cannot mmap before you know precisely for which user this should
>>> take place.
>>
>> Do you mean that if I use the 'current' and current->mm struct of the
>> driver, when mmaping, the user won't be able to use the returned pointer?
>
>To mmap you need to know the target process, more precisely its mm. This
>is typically derived from the invocation context of the service call
>("current" is a pointer to the current process). But init_module runs in
>the context of modprobe. Even worse, the process later opening and
>mapping some buffer may not even exist at that time!

Right, I've already verified this on practice... I'm mmaping on open handle=
r=20
for now just for testing the mmap, but I'll change it to the ioctl mmap=20
handler.

It seems to work. I mapped high_memory and could read and modify it from us=
er=20
space. The memory values mantained betweens the many open calls. I read,=20
printed the values and increment them by one. On next time, the value shown=
=20
was incremented... All seems perfect but I still didn't test with real=20
acquire code... When I do so, I'll let you know.

I still need to test the vmaops. I think I'll test them tomorrow. I need to=
=20
begin writing an article that my advisor asked me to. I need to finish it=20
until march, 10.

Best Regards,

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Rodrigo Rosenfeld Rosas]

Em Quarta 15 Fevereiro 2006 12:53, Rodrigo Rosenfeld Rosas escreveu:

>Em Ter=E7a 14 Fevereiro 2006 22:30, Jan Kiszka escreveu:
>>...
>>
>>>> You cannot mmap before you know precisely for which user this should
>>>> take place.
>>>
>>> Do you mean that if I use the 'current' and current->mm struct of the
>>> driver, when mmaping, the user won't be able to use the returned pointe=
r?
>>
>>To mmap you need to know the target process, more precisely its mm. This
>>is typically derived from the invocation context of the service call
>>("current" is a pointer to the current process). But init_module runs in
>>the context of modprobe. Even worse, the process later opening and
>>mapping some buffer may not even exist at that time!
>
>Right, I've already verified this on practice... I'm mmaping on open handl=
er
>for now just for testing the mmap, but I'll change it to the ioctl mmap
>handler.
>
>It seems to work. I mapped high_memory and could read and modify it from
> user space. The memory values mantained betweens the many open calls. I
> read, printed the values and increment them by one. On next time, the val=
ue
> shown was incremented... All seems perfect but I still didn't test with
> real acquire code... When I do so, I'll let you know.
>
>I still need to test the vmaops. I think I'll test them tomorrow. I need to
>begin writing an article that my advisor asked me to. I need to finish it
>until march, 10.

Ok, I tested the vmaops too and it also worked as expected. I think you cou=
ld=20
merge rtdm_mmap and related stuff to mainline RTDM. Thank you for your=20
precious work. Unfortunately you'll need to wait a while until I test them =
on=20
the real video driver. I had to stop working on it for writing the article.=
=20
When I finish the article I'll test them on real hardware but I see no=20
reasons for not working...

Best Regards,

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com