On Mon, 1 Oct 2001, Iwo Mergler wrote: > 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. > > In a SMP system, as a general rule, it's useless. > > > > 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. :) > > > > > Sorry for intruding in this discussion, but I would like > to lobby in favour of the fifo_size function. :^) > > I have a real-world example here which requires a way to > read the fill level of a fifo. I solved it by adding the > function (macro) myself, but I would feel more comfortable > to use the official release. >
As would I. :) I am going to work on this patch today and hopefully submit it today as well. It's always nice to have your code built on legitimate features of the underlying software... > My hardware is capable of changing the data transfer rate on > request, but there is a long latency involved in this. At > the time the fifo write fails, it is too late. In my case, > I use the fifo fill level to smoothly change the rate of > the data transfer, allowing enough time for the hardware > to adjust. > > Another, less serious benefit of fifo_size is the coolness > factor of having /proc/mydriver return "FIFO 34% full". :^) Yes! I agree! :) I also think it's cool to be able to generate statistics on fifo fills and even do cool things like make a little GUI representation of your fifo as a big blue water-tower as it fills with azure-colored 'data'.. :) Iwo, thank you so much for lobbying this cause, -Calin > > Thanks, > > Iwo > -- [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/
