[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r46gywul.fsf@rustcorp.com.au>
Date: Thu, 06 Mar 2014 11:19:54 +1030
From: Rusty Russell <rusty@...tcorp.com.au>
To: Daniel Vetter <daniel.vetter@...ll.ch>,
Intel Graphics Development <intel-gfx@...ts.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@...ll.ch>,
Jean Delvare <khali@...ux-fr.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Li Zhong <zhong@...ux.vnet.ibm.com>,
Jon Mason <jon.mason@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RFC] Taint the kernel for unsafe module options
Daniel Vetter <daniel.vetter@...ll.ch> writes:
> Users just love to set random piles of options since surely enabling
> all the experimental stuff helps. Later on we get bug reports because
> it all fell apart.
>
> Even more fun when it's labelled a regression when some change only
> just made the feature possible (e.g. stolen memory fixes suddenly
> making fbc possible).
>
> Make it clear that users are playing with fire here. In drm/i915 all
> these options follow the same pattern of using -1 as the per-machine
> default, and any other value being used for force the parameter.
>
> Adding a pile of cc's to solicit input and figure out whether this
> would be generally useful - this quick rfc is just for drm/i915.
If this is a good idea, you can write a macro module_param_unsafe_named
which is a general wrapper.
> -module_param_named(modeset, i915.modeset, int, 0400);
Wait, WTF? Why do you prefix i915 here manually? That means that
the commandline parameter would be "i915.i915.modeset=" and the
module parameter would be "i915.modeset="...
Confused,
Rusty.
--
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