On Wed, 2011-04-27 at 14:22 +0200, [email protected] wrote: > > From: [email protected] > [mailto:[email protected]] > > On Behalf Of [email protected] > > Sent: Wednesday, April 27, 2011 10:50 AM > > > > > From: [email protected] > > > On Behalf Of Philippe Gerum > > > Sent: Tuesday, April 26, 2011 10:28 PM > > > > > > ... > > > One read() per rt_pipe_write() operation, always. > > > > Thank you for your answer. Is "One readv() per rt_pipe_write() > > operation" supposed to be true also, or is there something special to > be > > taken into consideration regarding readv(2)? > > Meanwhile, I found some facts which allow me to elaborate on my > question. The rtpipe device hasn't a readv file operation implemented, > so the kernel substitutes the readv call by a series of read calls to > the device driver; due to this, under certain circumstances readv(2) > gathers more than a single rt_pipe_write() call's data. (I can provide > an example case, if desired.) Wouldn't it be desirable to implement the > readv file operation in the rtpipe driver so that the guarantee "One > read() per rt_pipe_write()" could cover readv(2) also?
No objection to merge this. Patch welcome. > (Besides, this > would make the phrase "Operates just like read" in the readv(2) man page > more correct.) Having readv() operate like read() would not give any guarantee wrt message boundaries, because it is the real-time write side which makes the decision regarding this, not the read side. So you could have readv() operate like read() and still have blurred boundaries in case rt_pipe_stream() is used instead of rt_pipe_write(). -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
