On Mon, 1 Oct 2001, Norm Dresner wrote: > ----- Original Message ----- > From: Iwo Mergler <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, October 01, 2001 4:09 AM > Subject: Re: [rtl] RT-Linux patch proposal for RTF size > queryage > > > > > > 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. > > > > 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". > :^) > > > > Thanks, > > > > Iwo > > -- [rtl] --- > > First, there's no need to apologize for adding another > voice to an intellectual discussion -- the more points of > view that are represented the more likely it is that all > concerned will make the best decisions. > Second, please don't interpret what I said as meaning > that a FIFO-fullness function is worthless. I have myself > hacked up an older version of RTLinux to make certain > normally internal FIFO routine variables public so I could > in fact do just that. What I was saying was that in the > most general setting it's worthless because of the > multi-tasking (or SMP) nature of the processing. I tried
Just use spin-locks. To say its entirely worthles, might, in my opinions be a bit strongly dismissive. > to indicate that in certain controlled conditions like my > particular system I could guarantee that only two tasks > would ever use any one FIFO. The problem I see for that is > if someone else comes along to take up maintenance on my > system and doesn't fully appreciate the dangers then that > person could use the added features in an unsafe manner. What is unsafe about this feature? > For particular systems it is a very worthwhile feature > which is IMO worthless in general. But unlike Victor and > company most of us are not in the business of writing > completely general software, we're only using RTLinux to > solve particular problems, each with its own unique > architectural features. > CAVEAT EMPTOR. > > Norm > > > -- [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/
