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: <a781481a0705100511l1bfdc7f3tc2669eb916f76594@mail.gmail.com>
Date:	Thu, 10 May 2007 17:41:21 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Roland Dreier" <rdreier@...co.com>
Cc:	"Paul Mundt" <lethal@...ux-sh.org>,
	"Roland Dreier" <rolandd@...co.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: trivial MLX4_DEBUG dependency fix.

Hi,

On 5/10/07, Roland Dreier <rdreier@...co.com> wrote:
>  > CONFIG_MLX4_DEBUG works out to a def_bool y for those that
>  > have CONFIG_EMBEDDED set. Make it depend on MLX4_CORE..
>
> Thanks, applied...  (by the way, this bug just results in an
> extraneous CONFIG variable being defined, right?  There's no further
> breakage -- or am I misunderstanding the situation?)

Yeah, it won't cause any build breakage. It doesn't cause anything to
even get _built_ actually, because of the way this config option is
used directly in the .h and .c sources in drivers/net/mlx4/ (which is
itself compiled only when MLX4_CORE=y or m), and not in a Makefile.

>  > I'll let someone else wonder why debugging output is default enabled,
>  > this seems to be a worrying trend as of late.
>
> Actually this option just controls whether to build the debugging
> output at all.  The output is controlled at runtime with a module
> parameter (which can be changed via sysfs after the module is loaded),
> and the output defaults to off.
>
> The reason why I want building the debugging stuff to default to y is
> so that distros automatically build modules with debugging enabled.
> Otherwise it's a pain to try and gather info from someone who has
> problems with a kernel they didn't build.

IMHO default configs must be aimed at production usage scenarios, so
are better off without debugging enabled by default. Except if the
driver is really new / EXPERIMENTAL where the goal is to get it tested
out by all users asap (and no production systems would be using it
anyway).

Just my 2 paise,
Satyam
-
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