AIESW-28663 : Add syslog equivalent message dispatcher for Windows#9837
AIESW-28663 : Add syslog equivalent message dispatcher for Windows#9837rbramand-xilinx wants to merge 5 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds a Windows implementation for the existing runtime_log = syslog message sink so that XRT can route runtime messages to the OS-native centralized logging facility on both major platforms (POSIX syslog on Linux, Windows Application Event Log on Windows).
Changes:
- Implement Windows
syslog_dispatchusing the Windows Event Log API (sourceAMD_XRT) and enable it under the existingruntime_log = syslogsetting. - Link the required Windows system library (
Advapi32) for the new Event Log calls. - Document
runtime_logsink options and Windows Event Viewer / CLI filtering for the new behavior.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/runtime_src/doc/toc/xrt_ini.rst | Adds documentation for runtime_log sinks, including Windows Event Log usage and filtering commands. |
| src/runtime_src/core/include/xrt/experimental/xrt_message.h | Updates public API documentation to describe supported message sinks including Windows syslog behavior. |
| src/runtime_src/core/common/message.cpp | Adds a Windows syslog_dispatch implementation that writes to the Windows Application Event Log. |
| src/runtime_src/core/common/CMakeLists.txt | Adds Advapi32 link dependency on Windows for Event Log API usage. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
clang-tidy review says "All clean, LGTM! 👍" |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
src/runtime_src/doc/toc/xrt_ini.rst:55
- The
**API Support**paragraph was moved to column 0, but the following list item is still indented, which makes it render as a block-quoted/nested list in reST. Consider aligning the bullet list indentation with surrounding lists (e.g., unindent the `- ``xrt::ini::set``` line, or re-indent the paragraph) to keep formatting consistent.
**API Support**: From 2020.2 release the runtime configuration options can also be provided through Native XRT APIs.
- ``xrt::ini::set``
stsoe
left a comment
There was a problem hiding this comment.
This LGTM.
Only comment I have is that for message.cpp we could have used common/detail/linux and common/detail/windows to hide platform specific differences. We could have detail/syslog.h to include details/windows/syslog.h or detail/linux/syslog.h. All code could be inline. No need to change now, just what I think I would have done.
Hi @stsoe, Thanks for the comment. I have added separate headers for platform specific code. Please review. |
| :: Command prompt - errors and warnings (Level=2 or Level=3) | ||
| wevtutil qe Application /q:"*[System[Provider[@Name='AMD_XRT'] and (Level=2 or Level=3)]]" /f:text | ||
|
|
||
| * - ``<filename>`` |
There was a problem hiding this comment.
@rbramand-xilinx I am assuming if user has configured this option, then ASCII strings are written into this file and no other parser is required, correct?
There was a problem hiding this comment.
Hi @arpitxilinx, yes we already parse data and dump to file
That said there is also an ini option to dump bin data as well - Debug.uc_log_bin_format (this is disabled by default)
|
Created subtask AIESW-34366 for INF changes |
Thanks Arpit |
| # Advapi32 is required for Windows Event Log API used in syslog_dispatch (message.cpp) | ||
| target_link_libraries(xrt_coreutil PRIVATE Advapi32) | ||
| target_link_libraries(xrt_coreutil_static INTERFACE Advapi32) |
There was a problem hiding this comment.
Can we do #pragma comment (lib, advai32.lib) instead? I think there should be examples in other files, definitely in XRT-MCDM
There was a problem hiding this comment.
Yes Soren, this should simplify things. Made changes accordingly. Please review.
Signed-off-by: Rahul Bramandlapalli <rbramand@amd.com>
Signed-off-by: Rahul Bramandlapalli <rbramand@amd.com>
Signed-off-by: Rahul Bramandlapalli <rbramand@amd.com>
Signed-off-by: Rahul Bramandlapalli <rbramand@amd.com>
Signed-off-by: Rahul Bramandlapalli <rbramand@amd.com>
9ac31e7 to
f51a641
Compare
Problem solved by the commit
XRT's syslog message dispatcher was Linux-only — on Windows it used to throw an exception ("syslog not supported on windows").
This PR adds changes to dispatch messages to Event log on Windows using same xrt ini option runtime_log = syslog
Bug / issue (if any) fixed, which PR introduced the bug, how it was discovered
This is a new feature addition. The gap was identified when working on ticket - https://jira.xilinx.com/browse/AIESW-27330
How problem was solved, alternative solutions (if any) and why they were rejected
The syslog_dispatch class is split into two platform-specific definitions under a single #ifdef _WIN32 / #else / #endif block, both sharing the same class name and interface:
Linux: unchanged — uses POSIX openlog / syslog / closelog
Windows: new implementation using the Windows Event Log API (RegisterEventSourceA / ReportEventA / DeregisterEventSource) writing under source name AMD_XRT in the Application log
The syslog config value now works transparently on both platforms — no xrt.ini change needed when moving between Linux and Windows.
INF change dependency: The Event Viewer filter UI (Source: AMD_XRT) only works if the driver INF file is changed to add new registry key.
Note: Events are still written correctly without the INF change — only the filter dropdown is affected.
cc : @arpitxilinx , @satishra-xilinx
The following inf file changes are needed for filtering of xrt messages -
Risks (if any) associated the changes in the commit
Low
What has been tested and how, request additional testing if necessary
Documentation impact (if any)
src/runtime_src/doc/toc/xrt_ini.rst: Added a new Runtime Log Sinks section documenting all runtime_log values, their platform availability, and Windows-specific filtering commands (Event Viewer, PowerShell, wevtutil).