On 12/04/2012 05:03 AM, Thierry Reding wrote: [...] > > One other thing that such a design can help with is refactoring common > code or parameterizing code. Maybe newer generations are not compatible > but can easily be made to work with existing code by introducing a > variable such as register stride or something. > > What's really difficult to follow is if an ops structure is accessed via > some global macro. It also breaks encapsulation because you have a > global ops structure. That may even work fine for now, but it will break > once you have more than a single host1x in a system. I know this will > never happen, but all of a sudden it happens anyway and the code breaks. > Doing this right isn't very hard and it will lead to a better design and > is less likely to break at some point. > Sorry I forget to reply this in last mail... Agree. Even for userspace programs, we should avoid using global variables as possible as we can. So we need to think about this and try to reduce the number of global vars. Mark > Thierry > > > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
