Re: [rtl] RT-Linux patch proposal for RTF size queryage

[Iwo Mergler <Iwo.Mergler@soton.sc.philips.com>]

Norm Dresner wrote:
> 
> ----- Original Message -----
> From: Calin A. Culianu <calin@ajvar.org>
> To: <rtl@fsmlabs.com>
> 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. 

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