Suresh Siddha wrote: > > > There is no need to go through num_var_ranges etc. > > > > Well I have to remember wich file added which MTRR entries. Because I have > > to remove them if the file is being closed. Therefore I need an array of > > size > > "num_var_ranges" (or MTRR_MAX_VAR_RANGES which is the uper bound). > > No. the private data for example can keep track of a struct containing > mtrr number and ref count etc. Exporting var_ranges and going through > var ranges elements in an array is not clean, especially when you are > populating only one element.
OK, I should have written that num_var_ranges is neccessary if I do copy a algorithm for exactly the same purpose from an other place. And I don't see anything better in having a dynamically growing list that makes the operation of incrementing MTRR entries an O(n) operation where it now is a O(1) operation. Additionally, the worst case memory requirement would be 2*sizeof(int)*num_var_ranges, where it is now 1*sizeof(int)*num_var_ranges. So for me, this would be a step back, but if you want this, you should additionally change arch/x86/kernel/cpu/mtrr/if.c from where I reused the algorithm. Regards, Thomas ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
