[Xenomai-core] Doubts about the Xenomai list
Hi, I've noted recently that my message has disappeared from the list. Is this a bug, or it was removed due the message size. If so, I'm sorry for the attachments, but I would like to be notified so that I could send another message without the attachments. I would also be thankful If someone here could host my articles for a while (a month or two), so that I could send him/her an e-mail with the articles and he/she would make them availables on the host and send me the link. When I have some time, I'll go to my college to put them on my homepage (I can't do it from home). Thank you, Rodrigo. __ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Doubts about the Xenomai list
Dmitry Adamushko escreveu: Hi, I think moderators may comment on your question. I just take an opportunity to make a minor comment on the papers' content (a part of it). Thank you for that. I read briefly only the part of your thesis regarding the Xenomai and RTAI parts (page 4). Frankly speaking (and based on my humble opinion/knowledge of Xenomai), the information is badly presented, both historically- and technically-wise, at the very least. I would really appreciate if could cite some further parts and comment on them. Starting from the very first sentence: Xenomai: Forked from RTAI As far as I know, Xenomai is the evolution of fusion, a parallel project that cooperated with RTAI. Is that wrong? Have you ever (if not publicly then privately) asked somebody from the list to read/review your papers? I guess, no. But that would definitely have been a good idea. Yes, I feel I should have done that. I have asked for enlightment in some topics, but I should really ask for someone here to read it. My mistake... Thank you for your input, Dmitry. Hope to have some feedback from other topics if you don't mind. I would put an errata in the index page that will link to the articles. Regards, Rodrigo. ___ Yahoo! Mail - Sempre a melhor opção para você! Experimente já e veja as novidades. http://br.yahoo.com/mailbeta/tudonovo/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] 2.6.17 hang on will halt now (possibly SMI related) [SOLVED]
Thank you Jan. I tested and it is working pretty fine again. My only problem is that I couldn't compile the new IRQ testsuite. I needed to disable it in order to compile the kernel. That happened both at home as at college. Thank you, once more. Best Regards, Rodrigo. Em Domingo 02 Julho 2006 10:29, Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: I began to experience a problem since 2.6.17 when shutting down my PC. I noticed the problem just after I recompiled my kernel to enable the SMI workaround. I, then rebooted the new kernel and when I tried to shutdown the system, it stopped on will halt now message or something like. The same behavior is occurring both in home (Pentium-3 550 MHz) and at college (P4-1.7GHz). In both systems, Xenomai advised me to enable SMI workaround. Actually, at home, the worst latency with the latency test was about 20us independently from enabling or not the SMI workaround. Do someone else experienced a similar problem when upgrading to 2.6.17? Yep. Should be fixed now, see latest trunk. It was a deadlock due to clumsy unregistration of the reboot notifier from its own handler. I think the locking of the kernel changed in 2.6.17 (RCU) and made this fatal. Jan PS: 20us on a P-III 550 is a bit too good. I guess some serious load is missing (cache load, IRQs, ...). ___ Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. Registre seu aparelho agora! http://br.mobile.yahoo.com/mailalertas/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Kernel becomes 2.6.17
Just informing... (in the hope of downloading a new adeos patch soon ;) ) Regards, Rodrigo. ___ Abra sua conta no Yahoo! Mail: 1GB de espaço, alertas de e-mail no celular e anti-spam realmente eficaz. http://br.info.mail.yahoo.com/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Kernel becomes 2.6.16.7
Sorry, actually, 2.6.17 is not ready yet. I've read it on hurry... it is actually a 2.6.16.7... Working perfectly fine with current patch... Sorry for the confusion, Rodrigo. Em Terça 18 Abril 2006 18:08, Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Just informing... (in the hope of downloading a new adeos patch soon ;) ) Go ahead and give it a try: my port for x86 to 2.6.16 was about fixing 4 failing hunks in the 2.6.15-patch (+ some minor namespace collision in the posix skin). Jan ___ Novo Yahoo! Messenger com voz: Instale agora e faça ligações de graça. http://br.messenger.yahoo.com/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [patch] TROUBLESHOOTING additions, README tweaks - minor correction
Em Segunda 17 Abril 2006 13:26, Jim Cromie escreveu: Q: How do I adequately stress-test ? + +A: xeno-test has a very basic workload generator, whose main virtue is +that its nearly universally available. + + dd if=/dev/zero if=/dev/null You probably meant dd if=/dev/zero of=/dev/null don't you? Rodrigo. ___ Abra sua conta no Yahoo! Mail: 1GB de espaço, alertas de e-mail no celular e anti-spam eficaz. http://br.info.mail.yahoo.com/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Fixs doxygen doc on rt_queue_read in ksrc/native/queue.c (for SVN version)
BTW, please, could someone confirm the rt_task_delete(NULL) bug in SVN? Regards, Rodrigo. Index: ksrc/skins/native/queue.c === --- ksrc/skins/native/queue.c (revisão 923) +++ ksrc/skins/native/queue.c (cópia de trabalho) @@ -885,7 +885,7 @@ } /** - * @fn ssize_t rt_queue_read(RT_QUEUE *q,void *buf,RTIME timeout) + * @fn ssize_t rt_queue_read(RT_QUEUE *q,void *buf,size_t size,RTIME timeout) * * @brief Read a message from a queue. * ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] rt_task_delete(NULL) started crashing on SVN
Hi Philippe, I'm not sure of the exact SVN revision the problem arised, but my program used to work 2 weeks ago, I guess, that was the last time I have tested it... Since some revision not before 2 weeks ago, rt_task_delete(NULL) was causing my program to crash. Please, could you see what is going on? Remember something that was changed in rt_task_delete code or some path that could affect this call in this way? Thanks in advance, Rodrigo. P.S: I tested on last SVN version today after a failure with the previous svn version I had installed. Unfortunately, I do not remember which was the previous revision, but I believe I've updated it yesterday. I think this information will not help very much, so, if you cannot reproduce the bug, I can try to write a minimal application where the bug appears. ___ 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@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] SIGXCPU snippet not working
Hi Philippe, I think I've found another bug on SVN. When trying to run the sigxcpu snippet provided with Xenomai I received only the following lines: Switched to secondary mode Switched to secondary mode Switched to secondary mode ... The backtrace was not shown. Actually warn_upon_switch wasn't been called, so I think the application was not receiving the signals correctly. This is how I compiled it: cc `xeno-config --xeno-cflags` `xeno-config --xeno-ldflags` -lnative sigxcpu.c -o sigxcpu Could you please verify this? Thanks again, Rodrigo. ___ Abra sua conta no Yahoo! Mail: 1GB de espaço, alertas de e-mail no celular e anti-spam realmente eficaz. http://br.info.mail.yahoo.com/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Mail list problem
Hi, I'm having huge delays in sending messages to these lists lately. Does anybody know what could cause such behaviour? BTW, about the message I sent yesterday (and that didn't arrive yet) about manual sti/cli doesn't need to be answered since I've already got the answer in the adeos.pdf document on adeos.org. Thanks in advance, Rodrigo. ___ Abra sua conta no Yahoo! Mail: 1GB de espaço, alertas de e-mail no celular e anti-spam realmente eficaz. http://br.info.mail.yahoo.com/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt-video interface
Em Domingo 26 Março 2006 06:49, Jan Kiszka escreveu: ... Maybe derived a subset from the full V4L2 API is the way to go. But let's wait if you discover other interface designs. Actually, my priorities changed again... I'll need to finish (start actually) an application using the camera in a hard real-time context for writing another article for RTSS (http://www.rtss.org) that will happen in Brazil this year. Hope to see some of you here if my article is approved. Then I will come back to my interface designs research... ... This method also requires poll and select to be implemented in V4L2. We should discuss how to deal with it if we stick with the V4L2 variant idea. Hmm, what file descriptors have to be monitored in parallel so that poll/select is required? I didn't really understand why should poll/select be required, but the author says it is too important to be optional... We should ask him why ;) Anyway, there are more efficient ways for monitoring a buffer state and wait for events in RTDM. I don't think we should use poll/select anyway... ... Which vision applications do you have in mind? So far only a subset of your scenario: One of my colleagues needs to synchronise frame timestamps with timestamps of other input, from range sensors e.g. The actually processing is not (yet?) hard RT, but the input synchronisation is essential. I think that the timestamp provided by the interface is enough, don't you think? Best Regards, Rodrigo. ___ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt-video interface
Em Segunda 20 Março 2006 21:24, Jan Kiszka escreveu:
...
Does your time allow to list the minimal generic services a RTDM video
capturing driver has to provide in a similar fashion like the serial or
the CAN profile? If it's mostly about copying existing Linux API specs,
feel free to just reference them. But the differences should certainly
fill up a RT-video (or so) profile, and that would be great!
If we're going to try to be as near as possible of the V4L2 API draft, the
minimal generic services is a lot to implement.
Actually, I don't know if implementing a V4L2 variant would be a good idea...
Maybe there are designs better suited to real-time applications. I need time
to investigate it more. My advisor asked me for. It's becoming really hard to
finish my master Thesis until June 15... :(
Basically I would need to have it clearer the most common use cases in real
situations... From the moment, here is my design (from a user point of view
of one kind of application): I'm using images to estimate speed of a robot
and identifying objects. I need the timestamps between both images and all
processes must be deterministic. I process the images and do the
calculations.
For avoid copying, I'm using the mmap facility. I process the image in the
same memory region when possible for avoidind the need of allocating more
memory. When using a NTSC camera, we have 60Hz frames, being 30 odds and 30
evens in a second. It means that a full frame (odd+even) would take about
33ms to complete. It is common, though, to use only half a frame in
processing not only because it is faster to acquire (17ms) but it is also
faster to process and acceptable in most cases. So, instead of 640x480 frames
we would process 640x240 frames. If the proportion is important, the user can
do something like:
for (w1=0,w=0; w1640; w1+=2, w++)
for(h=0; h240; h++)
{
process_pixel(w,h);
}
If all the processing can me made in 17ms, we could process the odd field when
acquiring the even and vice-versa. Otherwise, we could have a buffer with the
latest acquires so that we wouldn't need to wait until a frame is completed.
In summary, my control loop would be something like:
task_acquire
{
new_image=acquire_image();
speed=get_speed(new_image,old_image);
old_image = new_image;
}
task_do_pid_control
{
drive_motors(speed, desired_speed);
}
Well, that is a use case and I can get this behaviour with the V4L2 API,
although I don't know if it is the best suited API. Let me introduce the V4L2
API and then (in other messages) we can discuss others approaches.
There are some interfaces available in V4L2: capture, overlay and output. I'll
discuss only capture here that I think it is the most relevant for
rt-applications.
There are four IO modes: read/write, streaming I/O (memory mapping or user
pointer) and asyncronous I/O.
The read/write mode is the simplest but also the less efficient, since it
copies the buffer content to the user. It works like it is expected to. On
V4L2 API it requires the poll and select implementation but we could adapt
them to a simpler and more efficient way.
The user pointer approach has no sense for PCI framegrabbers on x86, since
these boards need a physical contiguous memory region for doing DMA. This
method consists on the user allocating the memory on userspace and passing
the pointers to the drivers.
The asyncronous I/O is not defined yer, so there are three and not four I/O
modes.
The third is the most useful for real-time applications and is what I'm
currently using: streaming by memory mapping.
See http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec/x3303.htm
In short, the user request a number of buffers in VIDIOC_REQBUFS ioctl and the
driver allocate or reserve them and return the number of actual allocated
buffers.
There is another ioctl (VIDIOC_QUERYBUF) for querying each buffer. Along with
other information, the user gets a memory offset to be used in a mmap call.
Then the buffers will be queued in a input buffer with the VIDIOC_QBUF ioctl.
When the VIDIOC_STREAMON ioctl is called, the board begins capturing in FIFO
order of the input buffer and as the acquires are done the buffers are moved
to an output buffer also in FIFO order. The user dequeue a buffer from the
output buffer with the VIDIOC_DQBUF ioctl. When the user has finished using
the result of that buffer (s)he will enqueues it again. When stop processing,
a VIDIOC_STREAMOFF ioctl call is made and cleans all buffers besides stopping
capture.
This method also requires poll and select to be implemented in V4L2. We should
discuss how to deal with it if we stick with the V4L2 variant idea.
I would like to understand what would be other possible usages of real-time
vision before I could propose another approach so we can discuss what would
be better for us.
Besides the API issue, we should think also on the API implementation. I think
we should create
Re: [Xenomai-core] Synchronising TSC and periodic timer
Philippe Gerum wrote: ... Given the description above, just that some skin might return either nucleus ticks or corrected timestamps to the applications, which would in turn do some arithmetics for converting values they got from the skin between both scales internally, and mistakenly use the result while assuming that both scales are always in sync. In this situation, and during a fraction of the time (i.e. the jitter), both scales might not be in sync, and the result would be unusable. But I still can't find a real situation where the user would need these values to be in sync... ... But maybe we are still discussing different issues actually, so it would be useful that the core issue that triggered the discussion about periodic mode precision be exposed again. The core issue is that: I think the driver development should be kind of independent from the user programs. That said, if the driver needs a precise timestamp, it should be able to get it, even if the user is fine with a, say, 100ms periodic tick. If the user have a loop with a deadline of 100ms, and if it takes two consecutive images for estimating speed in the same loop, the user will need to have a higher precision timestamps for the images. So, the driver will need a high precision timer reading for making possible to provide those timestamps... I hope that was what you were asking for... Regards, 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@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Synchronising TSC and periodic timer
Em Segunda 20 Março 2006 12:23, Philippe Gerum escreveu: ... It's not a matter of dealing with users always doing The Right Thing, but preferably preventing people from doing the wrong one. But we then have two problems and there are tradeoffs here. In one hand we want to avoid users from making mistakes. In the other hand we want to provide a way for solving the issue that generated this thread. A solution for the last one would be to have a function that would return a high-precision timestamp, not necessarily in sync with xenomai's timer, since it would be used for relative time calculations, but should be in sync between multiple CPUs. But this solution would rise the possibility for a user to do a wrong thing. Of course, the functions should be well documented and states the lack of sync if it is the case. So, we have to choose between turning it possible to have such design (as the example I have last message) or avoid people from doing the wrong thing. I would choose the first case, since I think all rt-programmers are smarter (or should be) then the average programmer. They must have attention when dealing with rt-programming. So, reading a documentation and understanding it should not be a hard task for them... In the other hand, if the second approach was chosen, a user wanting to use a rt-video interface will be forced to use the aperiodic timer for having reliable timestamps... 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@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Synchronising TSC and periodic timer
Em Segunda 20 Março 2006 13:51, Philippe Gerum escreveu: ... I think that you should try convincing Jan that rtdm_clock_tsc() might be a good idea to provide, instead of tweaking rtdm_clock_read() in a way which changes its underlying logic. ;o) Yes, that is exactly what I want! :) I don't see any reason for changing rtdm_timer_read() neither. I think that the most common usage of high-precision timestamps is for relative time cases. It doesn't need to be in sync with Xenomai's timer... It is best to keep things simple. What do you think Jan? P.S: Sorry for the last message, Philippe. I didn't see that one at the time. ___ 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@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] rt-video interface
Hi Jan and others interested. I've finally got my driver in a usable condition. It lacks a lot of functionalities yet, but it aplies to my needs. I would like to propose a real-time video interface for using with RTDM. For making it simple to port Linux applications to Xenomai, I tried to make it as close as possible to Video for Linux 2 API. I didn't see any serious problem regarding its use on real-time environments in the specification. So, the changes I think that would be necessary are: o Change open/fopen to rtdm_dev_open o Implement MMAP/MUNMAP as an IOCTL (while it can not be done in a rt-context in the mean time, nor should be necessary) o Implement also as IOCTLs: select and poll (I didn't implement them on my driver because I didn't need them, but it should be necessary accordling to specs) o Change all timeval structs to uint64_t or some typedef to it for making it easier to store the timestamps (we use rtdm_clock_read() instead of gettimeofday()) I can't remember of another issue now. I think these changes would be enough. Any ideas? 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@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt-video interface
Em Segunda 20 Março 2006 21:24, Jan Kiszka escreveu: ... You may want to have a look at this thread regarding poll/select and RT: http://www.mail-archive.com/rtnet-users%40lists.sourceforge.net/msg00968.htm I tried to. Not found. But I didn't give up so quicky. It was missing the final 'l': http://www.mail-archive.com/rtnet-users%40lists.sourceforge.net/msg00968.html Do video capturing applications tend to have to observe multiple channels asynchronously via a single thread? If so, my statement about how often poll/select is actually required in RT-applications may have to be reconsidered. Actually, I don't see any reasonable reason for using select/poll in rt applications. But, while trying to keep the API similar to V4L2, I would implement them by IOCTL and think it is OK, since it was already done for MMAP/MUNMAP. I don't think it worths writing the poll/select rt like functions... What could be discussed here is if it will be required or not to have those calls needed when using streaming (most designs will use streaming). I don't think it should be required as it is on V4L2, but could be implemented optionally, as IOCTL calls. But I would need to investigate more this topic. I'll do it tomorrow... I'm the last man in the lab and they are calling me out for closing the lab... ... Does your time allow to list the minimal generic services a RTDM video capturing driver has to provide in a similar fashion like the serial or the CAN profile? If it's mostly about copying existing Linux API specs, feel free to just reference them. But the differences should certainly fill up a RT-video (or so) profile, and that would be great! I'll think about it and will answer tomorrow. Regards, Rodrigo ___ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Synchronising TSC and periodic timer
Jan Kiszka escreveu: We discussed a lot about how to prevent the user shooting him/herself in the knee with inter-tick timestamps, but I still think that rtdm_clock_read_tsc() would even be worse in this regard. What do you think abou this documentation: This function is meant to be used in periodic mode for getting a high timestamp, independently from the system timer's tick. Its return values should not be used mixed with rtdm_clock_read() values because they are not syncronised. Driver authors[developers?] are advised to state this on driver documentation for the final users where returning these values to them for avoiding confusion. Note: This function is available for uniprocessor systems only in the meantime. I think it explains and will not make confusion in driver developers... If sometime someone give a good solution to the syncronisation problem between multiple processors, this can be changed... ... Rodrigo. ___ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Spreading Xenomai
Hi Jan, I liked your idea. I'm finhishing a first version (very limited while conforming to V4L2) framegrabber driver using RTDM and could write about it, but since I cannot show the Data Translation specific code, I could not publish the driver source code in any site. But I can still write an idea about the driver if it is from interest. But I think, reading the articles on LinuxDevices, that the space is very limited and, from the moment, I think it is more appropriate to speak more generally about Xenomai. Cite RTDM as an advantage and you can even say that there are some real-time drivers built into it, like serial, framegrabber, etc. Well, if you think I can contribute somehow, feel free to contact me. Rodrigo. Em Terça 14 Março 2006 07:28, Jan Kiszka escreveu: Hi, now that 2.1 is out and very likely also very stable, I feel like having to bring this topic up again: There should be more announcements of this project outside its own circle. When reading articles about proprietary real-time Linux variants now almost once a week on LinuxDevices, I always think that there should be at least once some statement about this powerful alternative. Moreover, there are certainly dozens of other forums for ringing the bells. We first need some concept what to present, then maybe a long version for forums that give us the space and a shorter one for the rest. Philippe recently posted interesting statements, comparing the Xenomai and the preemp-rt way - certainly good input. Every skin maintainer could contribute a paragraph. References to driver projects could be given. Short descriptions of ongoing projects would be nice, including commercial ones when possible. And so forth... Well, I would like to trigger this here, I may contribute a few lines from my focus, but I can't take over the overall organisation of the final writing. But I think that creating such an overview article here on this list could reduce the individual effort and would reflect best the strong community behind this project. Comments, suggestions, volunteers? Jan ___ Novo Yahoo! Messenger com voz: Instale agora e faça ligações de graça. http://br.messenger.yahoo.com/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Terça 14 Março 2006 03:44, Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Em Segunda 13 Março 2006 20:05, Jan Kiszka escreveu:
...
We would definitely need a good name for it,
rtdm_clock_read_ex(clock-id), rtdm_clock_read_tsc(),
rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read()
by adding an argument (otherwise, I would have to fix too many drivers
on my own... :-/).
That is the idea, I think. I agree that rtdm_clock_read() should be kept
as it is (the API/definition). No body is asking you to change it.
Adding rtdm_clock_read_tsc() would be sufficient in my opinion whilst it
maintain coherency with other skins.
Thinking about this more thoroughly, a few questions popped up for me:
o When we call it rtdm_clock_read_tsc(), we should actually return the
raw TSC values, shouln't we? But then we also need conversion
functions (rtdm_clock_tsc2ns, rtdm_clock_ns2tsc). Or should we always
convert to nanoseconds on return? POSIX and Native are different in
this regard.
I would prefer returning always ns, but both solutions would fit my needs,
so I'm not really worried about this topic.
o What would be the core rationale behind it, having a high-resolution
time stamp? What are the primary use cases? I'm asking for this so
that I can clearly differentiate between this new service and the
existing one in the docs. Also, giving an abstract description would
leave more options to the actual implementation on other archs or
platforms.
As I've said, I think that it is good to give some independency to the
driver, at least to the time related functions, for not depending on the
user chosen timer behaviour for some delay routines. Eg, I would like to
wait a specified amount of us before testing some register. That is a
quite normal task when
This is what rtdm_task_busy_sleep() already provides - independent of
the system timer.
I didn't know it was independent from the timer. Good to know. I think it
would worth enforce this statement on its documentation.
developing drivers. Another one is for timeouts on short delays. In those
cases, we want a good resolution, but this should be independent of the
user's timer choice IMO.
And this is something rtdm_clock_read_tsc() will obviously not be for.
Please, take a look in my case. The specification recommends wait at least Xus
before testing a bit. But the time to wait is not constant, it can vary a few
microseconds. So, I busy wait Xus and then do some code like:
rtdm_task_busy_sleep(X*1000);
start_time = rtdm_clock_read[_tsc]();
do {
condition=testbit();
} while (! condition (time_passed(start_time) TIMEOUT));
But if the user specifies a periodic timer, with tickval=1ms, then my driver
will be too slow. I could busy wait TIMEOUT before testing, and it would be
faster then the above code in this case. But I would like to go away as soon
as possible, ie, just after the bit has been set...
Again, when the user / system administrator decided to lower the timer
resolution in favour of performance, it is not possible (and doesn't
make sense) to circumvent this decision at driver level (except for busy
waiting).
But my situation is still a busy wait but written in another form.
So, I wonder what you plan to do with the return value of the
new function?
I think I've already explained myself.
Best regards,
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@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Terça 14 Março 2006 13:46, Jan Kiszka escreveu:
... Another one is for timeouts on short delays. In
those cases, we want a good resolution, but this should be independent
of the user's timer choice IMO.
And this is something rtdm_clock_read_tsc() will obviously not be for.
Please, take a look in my case. The specification recommends wait at least
Xus before testing a bit. But the time to wait is not constant, it can
vary a few microseconds. So, I busy wait Xus and then do some code like:
rtdm_task_busy_sleep(X*1000);
start_time = rtdm_clock_read[_tsc]();
do {
condition=testbit();
} while (! condition (time_passed(start_time) TIMEOUT));
But if the user specifies a periodic timer, with tickval=1ms, then my
driver will be too slow. I could busy wait TIMEOUT before testing, and it
would be faster then the above code in this case. But I would like to go
away as soon as possible, ie, just after the bit has been set...
This is how the eepr100 driver of RTnet handles it, though RTnet would
not work very well in periodic mode. Actually, this has been ported over
from Linux where you do not have a portable API for reading the TSC, I
think.
static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
{
int wait = CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;
while (inb(cmd_ioaddr) != 0) {
if (wait-- == 0)
return 1;
rtdm_task_busy_sleep(1000);
}
return 0;
}
(Hmm, BTW, de-inlining might be worth considering...)
So this works at a polling period of 1 us, but you may also reduce it,
though this would certainly degrade the accuracy further. For sure, the
accuracy is slightly worse than with your pattern. Would this matter to you?
No, in my case it doesn't matter. I'll adopt this way of doing it.
Thank you,
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@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Terça 14 Março 2006 13:59, Rodrigo Rosenfeld Rosas escreveu:
Em Terça 14 Março 2006 13:46, Jan Kiszka escreveu:
... Another one is for timeouts on short delays. In
those cases, we want a good resolution, but this should be independent
of the user's timer choice IMO.
And this is something rtdm_clock_read_tsc() will obviously not be for.
Please, take a look in my case. The specification recommends wait at
least Xus before testing a bit. But the time to wait is not constant, it
can vary a few microseconds. So, I busy wait Xus and then do some code
like:
rtdm_task_busy_sleep(X*1000);
start_time = rtdm_clock_read[_tsc]();
do {
condition=testbit();
} while (! condition (time_passed(start_time) TIMEOUT));
But if the user specifies a periodic timer, with tickval=1ms, then my
driver will be too slow. I could busy wait TIMEOUT before testing, and it
would be faster then the above code in this case. But I would like to go
away as soon as possible, ie, just after the bit has been set...
This is how the eepr100 driver of RTnet handles it, though RTnet would
not work very well in periodic mode. Actually, this has been ported over
from Linux where you do not have a portable API for reading the TSC, I
think.
static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
{
int wait = CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;
while (inb(cmd_ioaddr) != 0) {
if (wait-- == 0)
return 1;
rtdm_task_busy_sleep(1000);
}
return 0;
}
(Hmm, BTW, de-inlining might be worth considering...)
So this works at a polling period of 1 us, but you may also reduce it,
though this would certainly degrade the accuracy further. For sure, the
accuracy is slightly worse than with your pattern. Would this matter to
you?
No, in my case it doesn't matter. I'll adopt this way of doing it.
Thinking better, I would need such a function for registering the timestamp of
the captured frame on the irq handler...
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@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Terça 14 Março 2006 16:00, Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Em Terça 14 Março 2006 13:59, Rodrigo Rosenfeld Rosas escreveu:
Em Terça 14 Março 2006 13:46, Jan Kiszka escreveu:
... Another one is for timeouts on short delays. In
those cases, we want a good resolution, but this should be
independent of the user's timer choice IMO.
And this is something rtdm_clock_read_tsc() will obviously not be for.
Please, take a look in my case. The specification recommends wait at
least Xus before testing a bit. But the time to wait is not constant,
it can vary a few microseconds. So, I busy wait Xus and then do some
code like:
rtdm_task_busy_sleep(X*1000);
start_time = rtdm_clock_read[_tsc]();
do {
condition=testbit();
} while (! condition (time_passed(start_time) TIMEOUT));
But if the user specifies a periodic timer, with tickval=1ms, then my
driver will be too slow. I could busy wait TIMEOUT before testing, and
it would be faster then the above code in this case. But I would like
to go away as soon as possible, ie, just after the bit has been set...
This is how the eepr100 driver of RTnet handles it, though RTnet would
not work very well in periodic mode. Actually, this has been ported over
from Linux where you do not have a portable API for reading the TSC, I
think.
static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
{
int wait = CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;
while (inb(cmd_ioaddr) != 0) {
if (wait-- == 0)
return 1;
rtdm_task_busy_sleep(1000);
}
return 0;
}
(Hmm, BTW, de-inlining might be worth considering...)
So this works at a polling period of 1 us, but you may also reduce it,
though this would certainly degrade the accuracy further. For sure, the
accuracy is slightly worse than with your pattern. Would this matter to
you?
No, in my case it doesn't matter. I'll adopt this way of doing it.
Thinking better, I would need such a function for registering the
timestamp of the captured frame on the irq handler...
What will this timestamp be used for, relative time calculations? I just
would like to remind that the output of rtdm_clock_read_tsc() will not
be in sync with the system clock in periodic mode (one of my major
concern: that driver writers forget this fact).
But that is exactly what I need. Suppose that a robot control system uses two
images to estimate the robot speed. The application may need a control loop
of, say, 100ms, putting the periodic timer set to 1, 10 or 100ms. But,
suppose that in each loop it takes two images in a short time interval (less
then 100ms or even less then 1ms) and the real time interval is very
important. So the driver must pass the timestamp of each captured frame to
application loop. But those times shouldn't be multiple of the timer tick,
but the real time with all precision it can get.
I'm not talking especifically about this application, but giving you a general
idea of what is not possible to do currently with RTDM if the application set
the timer to periodic.
Regards,
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@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
I really tried to not answer this message and finish the endless thread you mentioned, but I couldn't resist. ;) Maybe this will be the last post from my own on this thread and will begin writing in the new thread. See below, please. Em Terça 14 Março 2006 17:29, Jan Kiszka escreveu: ... Ok, your framework is effectively aiming for relative times here, that's clear now. But your driver will deliver individual frames with absolute timestamp, right? Right. Then it's up to the user to NOT mix up these timestamps with dates obtained from the system clock. You will have to state this clearly! Sure, of course. No problem with that. Moreover, when considering the TSC as high-resolution timestamp source, this is not applicable on SMP / multicore systems. Those tend to have unsynchronised and drifting TSCs. So if the first picture was taken on one CPU and the second on some other... Unfortunately I can not arguee on that for now since I know almost nothing about SMP systems. I'll take a look on the topic and hopely soon I'll return you what I think about it. I'm not talking especifically about this application, but giving you a general idea of what is not possible to do currently with RTDM if the application set the timer to periodic. And as I have this general view in mind, I want to avoid that the TSC issue gets exported via RTDM drivers to the user. That's already problematic for the other skins, but having to write special notes all over the documentation of dozens of driver using mixed clocks would be very unhandy. I don't understand why adding a new function like this would change a lot the documentation. I really can not see your worries... If you could give me a practical example, maybe it would be easier for me... I see the need for having a high-resolution timestamp aside a low-overhead and low-resolution timer now, good, got an ally. ;) and I think we need to look for a way to avoid its negative sides. First I need to understand better what exactly are the negative sides... Not sure yet if it will be feasible, but I will come up with a new thread on this topic soon... Yes, I've seen. I'll discuss next messages there. Thank you, Rodrigo. ___ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Segunda 13 Março 2006 08:48, você escreveu: ... Do you mean that rtdm_clock_read will always read a multiple of tickval value? If so, I think it would be good to make it clear on its documentation. Get system time isn't enough for getting this information, IMHO. Please have a look at the two sentences of documentation I added to SVN (didn't make it into the release). I did. I gave your scenario a try, and I was able to verify that rtdm_task_busy_sleep works correctly under both timer modes. I cannot understand yet why it doesn't occur here, but I'll investigate if I have the time to. Indeed, the behaviour of rtdm_clock_read may have been confusing due to lacking information, but it was also correct. I liked the note, but I would include another one: When in periodic mode, the time resolution is limited to the tick set to the system timer or something like. Maybe: [If using periodic mode, note that ]The time resolution is limited by the system timer tick. Well my English is not that good, so I think you could give a better description, but I really need this note is very useful. Using something different (e.g. always TSC) would break applications specifying absolute times derived from the return values of other skins' functions. I did not understand. I'm talking about using TSC only for these two functions. I can not see why shouldn't it be possible... I mean, I think the driver should not depend on the userspace program timer for these two functions. But the worst case is that sometimes I get Should be near 84000: 0 which clearly is a incorrect result. That might be a rounding issue somewhere, as the sleep than clearly did not wait at least one tick. Will have to check this when time permits. After I run the latency program, the timer turns to be oneshot again and everything goes right. What can I do to solve this problem? Use oneshot mode in the meantime - or even longer ;). That is what I'll gonna do, but I know it is not a definite solution. Since I'm providing a framework, the user should decide which approach is better for him/her, oneshot or periodic mode. Why do you prefer periodic mode for your application? Another workaround: reduce the tick interval. I have some loops in my userspace programs that a common 100us tick would satisfy them all. I think the overhead would be lower than using the aperiodic oneshot mode... I'm not pretty sure about that. But that is not the question. My application is just an use case of my framework (actually I didn't even started building it). The final user should decide what is the best approach for him/her, not me. So, I would prefer that the driver be independent from the timer source chosen by the user program. I see your point. But when the user decides to pick a low-precision timer source to reduce overhead, (s)he has to live with the side-effect. There is no such thing like user vs. kernel timer source - it is always the same. Thus, also the precision of time stamping in drivers suffers. Ok, I'll document this on my framework. Thanks for the support, Rodrigo. ___ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Sorry Jan, I was looking at a different documentation. Now I read the right one. It is good. But I didn't understand why didn't you keep the latter note: The nucleus timer has to be started to obtain valid results. I would include it before the other note. Thank you, Rodrigo. Em Segunda 13 Março 2006 14:15, Rodrigo Rosenfeld Rosas escreveu: Em Segunda 13 Março 2006 11:54, Rodrigo Rosenfeld Rosas escreveu: I liked the note, but I would include another one: When in periodic mode, the time resolution is limited to the tick set to the system timer or something like. Maybe: [If using periodic mode, note that ]The time resolution is limited by the system timer tick. Well my English is not that good, so I think you could give a better description, but I really need this note is very useful. Actually, I would add them to rtdm_task_busy_sleep() documentation too. Rodrigo. ___ Yahoo! Acesso Grtis - Internet rpida e grtis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org 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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Actually, I noted a minor typo error in the documentation: of the this service should be of this service Best Regards, Rodrigo. Em Segunda 13 Março 2006 14:58, Rodrigo Rosenfeld Rosas escreveu: Sorry Jan, I was looking at a different documentation. Now I read the right one. It is good. But I didn't understand why didn't you keep the latter note: The nucleus timer has to be started to obtain valid results. I would include it before the other note. Thank you, Rodrigo. Em Segunda 13 Março 2006 14:15, Rodrigo Rosenfeld Rosas escreveu: Em Segunda 13 Março 2006 11:54, Rodrigo Rosenfeld Rosas escreveu: I liked the note, but I would include another one: When in periodic mode, the time resolution is limited to the tick set to the system timer or something like. Maybe: [If using periodic mode, note that ]The time resolution is limited by the system timer tick. Well my English is not that good, so I think you could give a better description, but I really need this note is very useful. Actually, I would add them to rtdm_task_busy_sleep() documentation too. Rodrigo. ___ Yahoo! Acesso Grtis - Internet rpida e grtis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Yahoo! Acesso Grtis - Internet rpida e grtis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Segunda 13 Março 2006 15:24, Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Sorry Jan, I was looking at a different documentation. Now I read the right one. It is good. But I didn't understand why didn't you keep the latter note: The nucleus timer has to be started to obtain valid results. I would include it before the other note. Well, it's no longer relevant for Xenomai: you can't load a driver without the timer being started - loading xeno_rtdm will do this. On the other hand, you are right when considering RTAI where you still face this obstacle. I will re-introduce the note below, but the strategy will remain that it's up to the user (application) to resolve this. The system timer has to be started to obtain valid results. If this happens automatically or is controlled by the application depends on the RTDM host environment, see related documentation of the real-time Linux extension. I would add a little, but significant comment with: The system timer has to be started to obtain valid results. If this happens automatically (as it does on Xenomai) or is controlled by the application depends on the RTDM host environment, see related documentation of the real-time Linux extension. Regards, 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@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Segunda 13 Março 2006 15:33, Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Em Segunda 13 Março 2006 14:25, Gilles Chanteperdrix escreveu: Jan Kiszka wrote: Sometimes the result is Should be near 84000: 10, that is kind of correct, since the tickval is 10, although I think that those functions in the RTDM driver context should be independent of the tick value set by the user program... Maybe using oneshot in the driver calls and periodic in the application... I really don't know what would be the best approach here... rtdm_clock_read always uses the nucleus clock. Using something different (e.g. always TSC) would break applications specifying absolute times derived from the return values of other skins' functions. Maybe adding a service to RTDM would allow users to measure short time intervals with RTDM using the TSC ? The native (rt_timer_tsc()) and posix (clock_gettime(CLOCK_MONOTONIC)) skins have a way to do this. This would fit great for my needs (and most developers I think)! Will think about it. Actually, I'm not a big fan of this. It creates the risk that someone feeds the output of this service into (incompatible) timed RTDM services. Sorry, I couldn't see a practical usage of this. Could you give an example? Even worse, this would work for aperiodic mode but fail for periodic. Actually it is only necessary on periodic modes as it already works for aperiodic mode. We would definitely need a good name for it, rtdm_clock_read_ex(clock-id), rtdm_clock_read_tsc(), rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read() by adding an argument (otherwise, I would have to fix too many drivers on my own... :-/). That is the idea, I think. I agree that rtdm_clock_read() should be kept as it is (the API/definition). No body is asking you to change it. Adding rtdm_clock_read_tsc() would be sufficient in my opinion whilst it maintain coherency with other skins. Thank you for considering it. 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@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Segunda 13 Março 2006 20:05, Jan Kiszka escreveu: ... We would definitely need a good name for it, rtdm_clock_read_ex(clock-id), rtdm_clock_read_tsc(), rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read() by adding an argument (otherwise, I would have to fix too many drivers on my own... :-/). That is the idea, I think. I agree that rtdm_clock_read() should be kept as it is (the API/definition). No body is asking you to change it. Adding rtdm_clock_read_tsc() would be sufficient in my opinion whilst it maintain coherency with other skins. Thinking about this more thoroughly, a few questions popped up for me: o When we call it rtdm_clock_read_tsc(), we should actually return the raw TSC values, shouln't we? But then we also need conversion functions (rtdm_clock_tsc2ns, rtdm_clock_ns2tsc). Or should we always convert to nanoseconds on return? POSIX and Native are different in this regard. I would prefer returning always ns, but both solutions would fit my needs, so I'm not really worried about this topic. o What would be the core rationale behind it, having a high-resolution time stamp? What are the primary use cases? I'm asking for this so that I can clearly differentiate between this new service and the existing one in the docs. Also, giving an abstract description would leave more options to the actual implementation on other archs or platforms. As I've said, I think that it is good to give some independency to the driver, at least to the time related functions, for not depending on the user chosen timer behaviour for some delay routines. Eg, I would like to wait a specified amount of us before testing some register. That is a quite normal task when developing drivers. Another one is for timeouts on short delays. In those cases, we want a good resolution, but this should be independent of the user's timer choice IMO. 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@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Quinta 09 Março 2006 17:33, Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Hi Jan, I'm still concerned about the future of RTDM and timer functions. I think there should be some function for starting the timer manually, since the automatic feature don't work great for RTDM drivers. It is not nice to have to run the latency (or any other) program for starting the timer before I can load my driver. And it is not suffice to run it once I booted. After I open/close my rtdm device and reload my driver the problem will occur again and I'll have to re-run the latency program. Sorry I don't see the problem here. # modprobe xeno_nucleus; cat /proc/xenomai/timer status=off:setup=1392:tickval=0:jiffies=0 # modprobe xeno_rtdm; cat /proc/xenomai/timer status=oneshot:setup=1392:tickval=1:jiffies=8113917792696 So the timer is running right since when rtdm is loaded?! Yes, here too. And that simple heartbeat rtdm example on my rt-addon homepage now cleanly runs even without any further helper to start some timer. Yes, here too. You are right, once the timer is in oneshot mode. My driver loads correctly without the helper. Then I start a user application that changes the timer to periodic mode and uses my driver. When I reload my driver, now in periodic mode, the problem raises. It seems, there is no problem when the timer is set to oneshot. But when turning it to periodic, at least one of rtdm_task_busy_sleep() or rtdm_clock_read() doesn't seem to work. See below: cat /proc/xenomai/timer status=periodic:setup=188:tickval=10:jiffies=19972453 start_time = rtdm_clock_read(); rtdm_task_busy_sleep(84000); temp_time = rtdm_clock_read(); rtdm_printk(KERN_INFO Should be near 84000: %u\n, (unsigned int) (temp_time-start_time)); Sometimes the result is Should be near 84000: 10, that is kind of correct, since the tickval is 10, although I think that those functions in the RTDM driver context should be independent of the tick value set by the user program... Maybe using oneshot in the driver calls and periodic in the application... I really don't know what would be the best approach here... But the worst case is that sometimes I get Should be near 84000: 0 which clearly is a incorrect result. After I run the latency program, the timer turns to be oneshot again and everything goes right. What can I do to solve this problem? Thanks in advance, 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@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Sexta 10 Março 2006 15:32, Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Em Quinta 09 Março 2006 17:33, Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Hi Jan, I'm still concerned about the future of RTDM and timer functions. I think there should be some function for starting the timer manually, since the automatic feature don't work great for RTDM drivers. It is not nice to have to run the latency (or any other) program for starting the timer before I can load my driver. And it is not suffice to run it once I booted. After I open/close my rtdm device and reload my driver the problem will occur again and I'll have to re-run the latency program. Sorry I don't see the problem here. # modprobe xeno_nucleus; cat /proc/xenomai/timer status=off:setup=1392:tickval=0:jiffies=0 # modprobe xeno_rtdm; cat /proc/xenomai/timer status=oneshot:setup=1392:tickval=1:jiffies=8113917792696 So the timer is running right since when rtdm is loaded?! Yes, here too. And that simple heartbeat rtdm example on my rt-addon homepage now cleanly runs even without any further helper to start some timer. Yes, here too. You are right, once the timer is in oneshot mode. My driver loads correctly without the helper. Then I start a user application that changes the timer to periodic mode and uses my driver. When I reload my driver, now in periodic mode, the problem raises. What happens if you make the periodic timer the default one in the kernel configuration? The same behaviour. It seems, there is no problem when the timer is set to oneshot. But when turning it to periodic, at least one of rtdm_task_busy_sleep() or rtdm_clock_read() doesn't seem to work. See below: cat /proc/xenomai/timer status=periodic:setup=188:tickval=10:jiffies=19972453 start_time = rtdm_clock_read(); rtdm_task_busy_sleep(84000); temp_time = rtdm_clock_read(); rtdm_printk(KERN_INFO Should be near 84000: %u\n, (unsigned int) (temp_time-start_time)); Sometimes the result is Should be near 84000: 10, that is kind of correct, since the tickval is 10, although I think that those functions in the RTDM driver context should be independent of the tick value set by the user program... Maybe using oneshot in the driver calls and periodic in the application... I really don't know what would be the best approach here... rtdm_clock_read always uses the nucleus clock. Do you mean that rtdm_clock_read will always read a multiple of tickval value? If so, I think it would be good to make it clear on its documentation. Get system time isn't enough for getting this information, IMHO. Using something different (e.g. always TSC) would break applications specifying absolute times derived from the return values of other skins' functions. I did not understand. I'm talking about using TSC only for these two functions. I can not see why shouldn't it be possible... I mean, I think the driver should not depend on the userspace program timer for these two functions. But the worst case is that sometimes I get Should be near 84000: 0 which clearly is a incorrect result. That might be a rounding issue somewhere, as the sleep than clearly did not wait at least one tick. Will have to check this when time permits. After I run the latency program, the timer turns to be oneshot again and everything goes right. What can I do to solve this problem? Use oneshot mode in the meantime - or even longer ;). That is what I'll gonna do, but I know it is not a definite solution. Since I'm providing a framework, the user should decide which approach is better for him/her, oneshot or periodic mode. Why do you prefer periodic mode for your application? Another workaround: reduce the tick interval. I have some loops in my userspace programs that a common 100us tick would satisfy them all. I think the overhead would be lower than using the aperiodic oneshot mode... I'm not pretty sure about that. But that is not the question. My application is just an use case of my framework (actually I didn't even started building it). The final user should decide what is the best approach for him/her, not me. So, I would prefer that the driver be independent from the timer source chosen by the user program. 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@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai as module changing bzImage
Thank you Jan and Philippe for pointing me that the changes is due to HAL portion. Now I know I don't need to worry about that and that I can use the new modules in a safe way without the need of rebooting the system. Jan, actually the binary output is different, at least for the HAL portion... And thank you for the fast howto on svn. I appreciate it a lot. I think it will be much simpler to be up to date with xenomai trunk. :) Thank you guys! Answering part of the Xenomai x RTLinux Jeff's question, one more reason to stay with Xenomai is the support we can get here from you. That is the best list support I've ever seen. Best Regards, Rodrigo. Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Hi Philippe, I disabled the kernel .config support, recompiled the kernel with latest ipipe patch and rebooted my system (Xenomai configured as a module). Then I downloaded last svn Xenomai. Compiled it (after correcting drvlib.c of rtdm skin) and noted that it has changed the kernel bzImage too, besides building the modules. Although I can use the new Xenomai modules without rebooting my system, I can not understand why should bzImage change. Have you any idea? Even if you turn on module support for all Xenomai components in the 2.1 series, there are still some bits (the HAL) being compiled directly into kernel. So, any modification of headers etc. may trigger a recompilation although the binary output will be the same. Jan ___ 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@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM mmap and vm_operations
Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Hi Jan, Is there a way of knowing what was the src_addr or pptr data passed to rtdm_mmap_to_user without using the vm_private_data struct? I mean, can I obtain those information directly in the vma struct passed to the close handler? If so, I could pass a more generic struct to vm_private and use those information,making my life a bit easier... :) I do not see a clean, official way right now. It would definitely be something you have to obtain via vma_area_struct or something that's contained in it. The information is likely there - somewhere. But I doubt that obtaining it would make your code very portable across different kernel versions. Ok, don't worry Jan. I was wondering if there was a portable easy way of obtaining those data, like a member of vma struct, but if not, there is no problem. I'll include these values in the private data struct. 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@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] RTDM mmap and vm_operations
Hi Jan, Is there a way of knowing what was the src_addr or pptr data passed to rtdm_mmap_to_user without using the vm_private_data struct? I mean, can I obtain those information directly in the vma struct passed to the close handler? If so, I could pass a more generic struct to vm_private and use those information,making my life a bit easier... :) Thanks in advance, 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@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap
Em Quarta 15 Fevereiro 2006 12:53, Rodrigo Rosenfeld Rosas escreveu: Em Terça 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 handler 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 value 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 could merge rtdm_mmap and related stuff to mainline RTDM. Thank you for your precious work. Unfortunately you'll need to wait a while until I test them on the real video driver. I had to stop working on it for writing the article. When I finish the article I'll test them on real hardware but I see no 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
Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap
Em Terça 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 handler 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 value 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. Best Regards, 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@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap
Em Terça 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 handler 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 value 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. 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
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... 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@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap
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... 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
Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap
... 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
Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap
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_startfriends 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
Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap
... 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
Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap
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 0030 printing eip: e0a1f2fc *pde = 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: 0030 ebx: d2e45a70 ecx: edx: 0001 esi: bfd72660 edi: 0880 ebp: c2b2 esp: c2b21f4c ds: 007b es: 007b ss: 0068 Process rmmod (pid: 4254, threadinfo=c2b2 task=d70bf550) Stack: e0bfafa0 bfd72660 e0bf7cbc d2e45a70 b7d92000 00096000 e0bfad80 c0132e0d 645f7472 35313374 c0320033 0246 c03fa4cc c013c881 0021 c0324200 0246 c2b21fbc 0021 0001 c0324200 bfd72660 00d72660 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
