On Tue, Jul 01, 2014 at 11:42:27AM +0200, Matthias Beyer wrote: > Hi Kevin, > > Don't know if this mail should go to the ML, too, ... if you want, you > can forward it or add the ML as recipient for your answer! > > I'm currently working on some cleanup patches for the > > drivers/staging/bcm/IPv6Protocol.c > > file. > > I want to clean up the code for the functions [0] > > MatchSrcIpv6Address() > MatchDestIpv6Address() > > as this code is literally the same. They differ just in what they > print via the BCM_DEBUG_PRINT() macro. > > Do you have an Idea how to generalize this functions? The problem I'm > facing is that the named macro wants some string literals, but when > outsourcing the code, I'm not able to generalize these. I think you can make the string literal in the BCM_DEBUG_PRINT() macro generic. Instead of specifying the source or destination IP Address; I would simply say the IP Address. I would make the 4 messages generic and remove one of these functions. Thereby reducing the lines of code, like you said. > I have some ideas how to solve this problem: > > 1) Passing Function-Ptrs as debug-print callbacks to the generalized > function. Not clean at all, as for each BCM_DEBUG_PRINT() call I would > pass one function-ptr. > > 2) A static const variable which contains the strings in a struct[], > passing the index of the appropriate struct to the generalized > function. Not very clean. > > 3) Passing a simple flag, the generalized function decides which > string to BCM_DEBUG_PRINT(). Clean, but not very readable. > > If you don't know either, I would start with the 3rd approach and look > what the maintainers say. Let's take inventory for the maintainers and see what other ideas they have. > Btw: This patch would result in 50 lines less in the file, which is > desireable, I guess. > > [0]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/bcm/IPv6Protocol.c#n291 > > -- > Mit freundlichen Grüßen, > Kind regards, > Matthias Beyer > > Proudly sent with mutt. > Happily signed with gnupg. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
