linux-kernel - Re: [v4l-dvb-maintainer] [PATCH] cafe_ccic: default to allocating DMA buffers at probe time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 19 Sep 2007 18:43:38 -0400
From:	Andres Salomon <dilinger@...ued.net>
To:	Trent Piepho <xyzzy@...akeasy.org>
Cc:	Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
	v4l-dvb-maintainer@...uxtv.org, video4linux-list@...hat.com,
	akpm@...ux-foundation.org, mchehab@...radead.org
Subject: Re: [v4l-dvb-maintainer] [PATCH] cafe_ccic: default to allocating
 DMA buffers at probe time

On Wed, 19 Sep 2007 15:34:42 -0700 (PDT)
Trent Piepho <xyzzy@...akeasy.org> wrote:

> On Wed, 19 Sep 2007, Jonathan Corbet wrote:
> > Andres Salomon <dilinger@...ued.net> wrote:
> > > This patch makes DMA buffer allocation happen during device probe by
> > > default, and changes the parameter to 'alloc_bufs_at_read'.  The
> > > camera hardware is there, if the cafe_ccic driver is enabled/loaded it
> > > should do its best to ensure that the camera is actually usable;
> > > delaying DMA buffer allocation saves an insignicant amount of memory,
> > > and causes the driver to be much less useful.
> >
> > The amount of memory isn't quite "insignificant" (three 640x480x2
> > buffers), but the OLPC people clearly need things to work this way.
> > There are, as far as I know, no other systems out there using the CAFE
> > controller.  Making things work by default for the one user (with a fair
> > number of deployed systems!) makes sense to me.  So...
> >
> >   Acked-by: Jonathan Corbet <corbet@....net>
> >
> > That said, I do prefer the original name for the parameter.
> 
> Changing the parameter name will break the configuration of anyone who was
> using the existing parameter.  It also means everyone who has multiple

We (OLPC) are the only ones using this driver, as we are the only ones with
this hardware.  Marvell designed the cafe for us, and it is not available
on the market yet.  Backwards compatibility at this point is not a concern.

> kernels installed and uses this parameter will need to have one
> configuration for old kernels and a different configuration for new
> kernels.
> 
> In the default really needs to be changed (what's so hard about setting
> alloc_bufs_at_load in /etc/modprobe{.d,.config}?) then just change the
> default of the existing parameter.  That avoids the whole problem with
> different configration files for different module versions.

We're building the driver in statically; there's no point for us to make
it a module.  We could add a kernel argument, yes, but that quickly
becomes unwieldy as we require more and more.  We've actually been trying
to cut down the number of kernel args we use.


That said, I'm not opposed to keeping the parameter name the same while
making the default 1; I just thought that the name 'alloc_bufs_at_read' was
clearer.  Another option is to change it to 'no_alloc_bufs_at_load'.  Jon,
any preference there?


-- 
Andres Salomon <dilinger@...ued.net>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/