#16858: Tidy-up of TRACE Macros in Bootloader (and possibly elsewhere)?
---------------------------------+-------------------------------
Reporter: stellarpower | Owner: nobody
Type: task | Status: new
Priority: normal | Milestone: Unscheduled
Component: System/Boot Loader | Version: R1/Development
Resolution: | Keywords: Formatting, TRACE
Blocked By: | Blocking:
Platform: All |
---------------------------------+-------------------------------
Comment (by stellarpower):
I see a couple of things with that, and I think consistency would be good
from the outset if a refactor is in order:
1. functions will evaluate to an expression via the return value, except
for void, so if the macro is to look like a function invocation, that
could potentially conflict for macros that expand to a statement
2. If the semicolon is meant to be included at the call site, to mimic a
function call, then the no-op definition wouldn't be required, as an empty
semicolon would be okay for e.g. single-statement conditional bodies. I
guess it does no harm but it seems clearer to me how it's meant to be used
if it expands to nothing - void(0) seems somewhat obvious too, or I'd vote
for defining a NO_OP macro to be explicit and then anything would work
really.
Perhaps long-term, a move away from macros and more of the code towards a
logger framework, for the parts of the OS that will be up and able to
handle something like this at the time it's used, would be worth
considering. In past projects, I've used a logger with log levels and
colour-coding, and the macros as minimally as possible to get the file,
function and line, in the main logger. Any further ones on top would be
specific to the task at hand to reduce manual typing. Maybe even a logging
and debugging kit, or as part of the support kit, that user applications
could use as well as the system.
I was tidying up my VCS yesterday so will have a more detailed look at
those files above and elsewhere in the OS and knock together a first draft
to see how it sounds before pushing to Gerrit. Ideally push everything
into the one file, such that it supports all the existing usage in one way
or another, and then edit all the various sources to use this file for
their debugging. Then can review the specifics of the one file in Gerrit
or via commits later. os/support/debug.h looks a good start, so it seems
to make most sense to refactor the rest into that. Might as well include
some modularity for outputting the function, file/line, other preambles,
etc. too. I like how brief the bluetooth one is as one option.
--
Ticket URL: <https://dev.haiku-os.org/ticket/16858#comment:10>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
