On 09/06/20(Tue) 20:19, jo...@armadilloaerospace.com wrote: > Looking for some guidance to avoid proposing any unpopular diffs. > > Style(9) says not to use static on file-local functions in the > kernel, because it interferes with the debugger. They still show up > on some functions today; is this still an issue?
I don't know if it's an issue, but not using 'static' is still a convention. > I usually advocate for directly inlining small functions that are only > called from one place, because it removes any doubt about whether it > is or ever should be called elsewhere. For instance, these functions: > > vaddr_t > efifb_early_map(paddr_t pa) > { > return pmap_set_pml4_early(pa); > } > > void > efifb_early_cleanup(void) > { > pmap_clear_pml4_early(); > } > > Is that frowned on? I know I am on the longer-functions side of > the spectrum. It's a matter of taste/experience/amount of code read/etc. There's no better way, all have pros and cons ;) > Also, style(9) says that prototypes should not have variable names > associated with the types. I try to use good names in the headers > for documentation purposes; what is the thinking behind the rule? There's a huge amount of code written this way. Changing this requires effort and distracts from real changes. Trying to match the existing style(9) helps when dealing with huge code base. Like everywhere exceptions exist :)