Hi, On Fri, Jan 29, 2021 at 2:54 AM Grygorii Strashko <grygorii.stras...@ti.com> wrote: > I've being thinking - shouldn't be implemented as new api, like > port_pr_xx(port, ...)? > (similar to kernel dev_xx(dev)).
The problem is: 1) There are 8 basic log level macros, and then another 8 rate-limited macros. If I implemented port_ variants, that's another 16 macros. I think there are probably too many log levels available right now, but as it is, I would be uncomfortable adding an extra multiplying layer. 2) Not all port-related log messages use the form "port 3: xxx"; there are some messages that refer to two ports or other variations. This patch doesn't require special cases for those situations. > Why in some places it's port_log_name() and in other p->log_name? This is because some places see the opaque type 'port' and some have access to its contents. This is similar to portnum() vs port_number(). We could use port_log_name(p) everywhere, though in this case it's simpler to replace all current uses with p->log_name so that I don't exceed line length limits. _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
