On Sun, 30 Sep 2001, Norm Dresner wrote: > ----- Original Message ----- > From: Calin A. Culianu <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, September 29, 2001 9:24 PM > Subject: Re: [rtl] RT-Linux patch proposal for RTF size > queryage > > > > > > > > On Fri, 28 Sep 2001, Victor Yodaiken wrote: > > > > > You're welcome to send a patch and your tone is fine, > but ... > > > 1. Stuart is right, it's easy, just put the function in > the rtl_fifos code > > I am not sure what you are referring to... if you are > saying that > > creating a custom function to return fifo size is easy, > then yes, I agree > > with that one.. :) > > > 2. I hate adding functions so my question is always > "why do you have to have it"? > > Well, because. :) No seriously I think it's a fair > feature of a fifo > > for one to be able to query its size and/or fill. > > In a uniprocessor situation it's only useful if you can > guarantee that no other (real-time) task or ISR will gain > control of the CPU between the query and whatever you > decide to do as a result of it; yes, there can be a > significant number of cases where this guarantee is > (almost)absolute, but as a general rule without disabling > interrupts -- which is depricated in any real-time > system -- it's not particularly useful.
Ok, you are right in pointing this out. In fact this is so strong an argument that it convinces me that maybe I am wasting my time in thinking about this feature. Esp. from userland.. such an ioctl would be pretty useless. The only time it's naturally simple and useful is when you are in your rt-task on a uniprocessor system, or a multiprocessor system but you know the other rt-task isn't touching your fifo. > In a SMP system, as a general rule, it's useless. > Well it would be useful if the rt-task were spinlocking on that information. Of course such locks can add complexity to a programmer's calculations regarding predicted run-times, but they do not necessarily lead to any loss of determinism. My question to you (since I am too impatient to read the code right now) is this: Do we or do we not allow spinlocks in SMP rt-tasks? I am having trouble thinking if there's any reason to not use them. I guess it can lead to priority inversion.. but.. well.. so can a lot of things. :) If we do allow spinlocks in SMP rt kernel threads, then I would argue that my proposed functions would still be useful, although only if the programmer were really careful to synchronize his fifo reds/writes/queries properly in an SMP situation. One can argue that the added headaches of this feature make it too awkward to use. However, the present situation, where there is zero information on how full or empty rt-fifos are, kind of prevents a certain comfortable degree of freedom (although it it's misplaced freedom, please let me know). -Calin > Norm > > >Also, I am being > > particularly anal with respect to my rt-task talking to > userland and I > > want to be absolutely sure that I don't have any failed > and/or partial > > writes.. the only way to really accomplish this is to > have the ability to > > query the fifo size/freeness. I don't *absolutely* need > this feature, but > > if would make me happy if this feature were included. :) > > > > -Calin > > > > > > > > > > > > > On Fri, Sep 28, 2001 at 04:21:45PM -0400, Calin A. > Culianu wrote: > > > > > > > > I realize the tone of my previous this email seems > impatient.. it isn't. > > > > Actually if you guys would honor me with your > approval, I can gladly > > > > submit a patch that defines an interface for my > proposed solution (a) > > > > below, or one that moves the struct definition of > struct rtl_fifo_struct > > > > over to the more public 'rtl_fifo.h' header file. > (Since the kernel symbol > > > > rtl_fifos is already exported). > > > > > > > > > > > > Please allow me to be an rt-linux developer!! :) > > > > > > > > -Calin > > > > > > > > ---------- Forwarded message ---------- > > > > Date: Fri, 28 Sep 2001 15:35:38 -0400 (EDT) > > > > From: Calin A. Culianu <[EMAIL PROTECTED]> > > > > To: [EMAIL PROTECTED] > > > > Cc: rtl <[EMAIL PROTECTED]> > > > > Subject: RE: [rtl] number of elements in a fifo > > > > > > > > Well, in kernel mode there's no way to tell how full > a fifo is (as of rtl > > > > 3.1)! > > > > > > > > Actually, that macro only occurs in rtl_fifo.c, and > furthermore, the > > > > exported kernel symbol "rtl_fifos" that the macro > really uses is of > > > > type struct rt_fifo_struct, which is a private type > inside rtl_fifo.c! > > > > > > > > Why is kernel symbol 'rtl_fifos' exported when its > type is private? > > > > It aggravates me!! > > > > > > > > Can someone on the rt-linux dev team either kindly: > > > > > > > > a) create a public interface to find out the size > and/or the bytes free in > > > > an rtf (this is trivial, just make a function that > returns > > > > rtl_fifos[minor].bufsize, rtl_fifos[minor].len etc). > > > > > > > > OR > > > > > > > > b) make struct rtl_fifo_struct a public struct???? > (since the array of > > > > fifos is exported into the kernel symbol table > anyway). > > > > > > > > -Calin > > > > > > > > On Fri, 21 Sep 2001, stuart warren wrote: > > > > > > > > > To read how full the fifo is from userspace... > > > > > > > > > > int bytes_in_fifo; > > > > > ioctl(rtfifo_fd, FIONREAD, &bytes_in_fifo); > > > > > > > > > > In the kernel you can use... > > > > > > > > > > bytes_in_fifo = RTF_LEN(fifo_number); > > > > > > > > > > Cheers, > > > > > Stuart > > > > > > > > > > -----Original Message----- > > > > > From: fred august [mailto:[EMAIL PROTECTED]] > > > > > Sent: Thursday, 20 September 2001 6:00 > > > > > To: rtl > > > > > Subject: [rtl] number of elements in a fifo > > > > > > > > > > > > > > > Hi, > > > > > is there a simple way to know how many > elements > > > > > are in a FIFO? This should be in RT, or almost, for > a > > > > > FIFO between a RT thread and a user space one. I > need > > > > > this information in order to dump some of the > elements > > > > > if the FIFO is too full. > > > > > > > > > > thanks > > > > > > > > > > f > > > > > > > > > > > ___________________________________________________________ > ___________ > > > > > Do You Yahoo!? > > > > > Il tuo indirizzo gratis e per sempre @yahoo.it su > http://mail.yahoo.it > > > > > > > > > > -- [rtl] --- > > > > > To unsubscribe: > > > > > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] > OR > > > > > echo "unsubscribe rtl <Your_email>" | mail > [EMAIL PROTECTED] > > > > > -- > > > > > For more information on Real-Time Linux see: > > > > > http://www.rtlinux.org/ > > > > > > > > > > -- [rtl] --- > > > > > To unsubscribe: > > > > > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] > OR > > > > > echo "unsubscribe rtl <Your_email>" | mail > [EMAIL PROTECTED] > > > > > -- > > > > > For more information on Real-Time Linux see: > > > > > http://www.rtlinux.org/ > > > > > > > > > > > > > > > > > -- [rtl] --- > > > > To unsubscribe: > > > > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] > OR > > > > echo "unsubscribe rtl <Your_email>" | mail > [EMAIL PROTECTED] > > > > -- > > > > For more information on Real-Time Linux see: > > > > http://www.rtlinux.org/ > > > > > > -- [rtl] --- > > > To unsubscribe: > > > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > > > echo "unsubscribe rtl <Your_email>" | mail > [EMAIL PROTECTED] > > > -- > > > For more information on Real-Time Linux see: > > > http://www.rtlinux.org/ > > > > > > > -- [rtl] --- > > To unsubscribe: > > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > > echo "unsubscribe rtl <Your_email>" | mail > [EMAIL PROTECTED] > > -- > > For more information on Real-Time Linux see: > > http://www.rtlinux.org/ > > > -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
