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 _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
