"Premi, Sanjeev" <premi@xxxxxx> writes: [...] >> > [sp] I don't like #ifdefs either but each time we cannot create >> > Â Â a new file changes like this. >> > >> > Â Â The current code is a mess with debugfs used too frequently. >> > Â Â And - all of it is not for debug. The location of ifdefs in >> > Â Â in the patch illustrates it quite well. >> > >> > Â Â BTW, this isn't the only use of ifdefs in a C file in Linux. >> in reality the only reason you've had to do this patch was because we >> had a wicked handling of debugfs entries in voltage layer - with >> voltdm_c these are all gone. further any entries remaining (e.g. SR) >> are: >> dentry for debugfs file -> just a minor overhead not >> deserving a #ifdef >> all other functions of debugfs (as per include/linux/debugfs.h) when >> debugfs is disabled in .config will be static inlined and we will not >> need any #ifdefs at all >> >> The real pending question is about functional SR debugfs entries that >> need to loose it's critical functionality. > > [sp] good argument for future not the present and past. Fact is that > "wicked handling of debugfs entries" made their way. Correct. As maintainers, we do not always catch every problem. Also, we have not been as strict about some things in the past as we are now. However, the fact that bad coding style exists in the kernel already is not a good argument for accepting more. > I am not worried about the patch in or out - few folks who were > stuck on the issue would have used it anyway. But, whether each > fix for today can be postponed for future restructuring. > > #ifdefs were just easy target for the postponement. Nothing has to be postponed for future restructuring. The reason $SUBJECT patch was not merged, was because the approach was not correct. If you submit an acceptable fix to this problem, I'll merge it today even if I'm in the process of removing those features in parallel restructuring work, because I don't know when my removal work will be ready. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
