> Since we're being pedantic, it also makes sense to decide now whether 'area' > refers to all [discontiguous] regions or just one of them. I'd say the former, and > use 'region' for the latter, i.e., an area may be made up of several regions, but > only one exists of each type. > > > Parameters and local variables should be named unambiguously following > > these concepts as well. There should be no opaque 'new' variables > > *especially* where the primary role of the efi_memmap_insert() API > > call is to add a new *entry* - it should be 'new_efi_map_table' (or > > 'new_table' where it's unambiguous) instead, and new entries added > > should be 'new_entry' - etc. > > > > Once this is reorganized and clarified it should be a lot more easy to > > review 'table freeing' patches. I can help out with patches if there's > > no conceptual objections. I have a question, As this table freeing patches do some cleanup of some efi functions, namely, efi_clean_memmap(), efi_fake_memmap(), efi_arch_mem_reserve(), efi_memmap_install() and __efi_enter_virtual_mode(), I am not very sure if you want to do the name changing now and later review the patches or review the patches and later do the name changing. As you pointed out that reviewing them now is pain, which I agree, but my concern is you might be looking at code and might as well change names that might eventually be gone because of these table freeing patches. Regards, Sai
