Daniel Vetter <daniel.vetter@xxxxxxxx> 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. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
