Daniel Vetter <daniel.vet...@ffwll.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
