Google
  Web www.spinics.net

Re: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Sat, 2008-10-11 at 08:53 -0300, Mauro Carvalho Chehab wrote:
> On Sat, 11 Oct 2008 12:44:26 +0200
> Janne Grunau <j@xxxxxxxxxx> wrote:
> 
> > On Saturday 11 October 2008 04:08:10 Andy Walls wrote:
> > > On Fri, 2008-10-10 at 21:32 -0300, Mauro Carvalho Chehab wrote:
> > > > Hi Andy,
> > > >
> > > > On Sat, 4 Oct 2008, Andy Walls wrote:
> > > > > cx18: Change module parameters for finer control over buffer
> > > > > allocation
> > > >
> > > > It is not a good idea to rename module parameters. Anyone with a
> > > > previous setup using the old parameters won't have the modules
> > > > loaded after the rename.
> > >
> > > A very good point.  Initially this is the way I had it.
> > >
> > > But a user pulling my change, without asking me, then had problems
> > > because there was no obvious indications that the units of the module
> > > parameter had changed from 'MB' to 'number of buffers'.  There was
> > > quite a difference for him going from '8 MB' to '8 buffers of several
> > > kB'. :) The problem was that the difference in units was silent
> > > unless he had actually run modinfo.
> > >
> > > > I suggest you to keep the old naming.
> > >
> > > I'm leary about keeping the old module parameter name with a change
> > > in units for the reason cited above.  I'm open to suggestions on how
> > > to keep an optimal user experience though.
> > 
> > The new module parameter name is fine since it means something 
> > different. The old parameter should stay for a couple of kernel release 
> > and print a warning that it is replaced by the new one.

OK.  I can certainly work something in like this.  It's better than the
kernel giving some minimal gripe about not being able to load the
module.


> OTOH you could 
> > just compute the number of from the complete buffer size in mega bytes 
> > and the individual buffer size.
> 
> That would be my suggestion ;)

Yup, I've been down that road too.

There's a hardware/firmware limit I ran across on the number of buffers:
63.  Staying within the hardware limits was the easy thing to do.  I
suppose it could be overcome with some non-trivial bookkeeping work in
the driver.

As a point of reference, in the few times I've measured, buffer
utilization for the MPEG stream never bursts past 11 buffers of 32 kB
size (352 kB) with only one ongoing capture on my system.  That burst of
11 was a singular event.  I suppose if a user has a really slow app or
really loaded system, more depth would be required.


Thanks all.  I'll try to work something out.

Regards,
Andy





_______________________________________________
v4l-dvb-maintainer mailing list
v4l-dvb-maintainer@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer

[Linux Media]     [Older V4L]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [SSH]     [Linux USB]

-->
Add to Google Powered by Linux

Google PageRank Checking tool