On Wed, Mar 5, 2014 at 10:00 PM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > On Wed, Mar 5, 2014 at 9:32 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: >> On Wed, 5 Mar 2014 10:33:14 +0100 Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: >> >>> 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. >> >> Seems harmless and potentially useful to others so yes, I'd vote for >> putting it in core kernel. >> >> However this only handles integers. Will we end up needed great gobs >> of new code to detect unsafe setting of u8's, strings, etc? > > Well I've just done integers because hardcoding the -1 default was so > easy ... But thinking about it some more (and looking at some more mod > params in i915) passing the default to the macro and storing it in > some struct, together with the pointer for the variable sounds useful. > With that this could be easily extended to all kinds of types. > > Now would such a temporary structure to store the default be > acceptable or is there some neater trick to pull this off? s/temporary/created by the macro/ ... past beer time here already ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
