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]
Message-ID: <Pine.LNX.4.58.0709191703300.27377@shell4.speakeasy.net>
Date:	Wed, 19 Sep 2007 17:08:55 -0700 (PDT)
From:	Trent Piepho <xyzzy@...akeasy.org>
To:	Andres Salomon <dilinger@...ued.net>
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, Andres Salomon wrote:
> 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.
> > >
> > 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.

Ok, that seems like a good reason to change the default.
>
>
> 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?

It seems like the name 'alloc_bufs_at_read' isn't quite right, since the
buffers will be allocated when the format is set, from
cafe_vidioc_s_fmt_cap().
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ