12 Apr
2011
12 Apr
'11
4:49 p.m.
Please point me the same thing. Two or three
implementations.
Windows uses the screen, COM1, DBWIN_BUFFER, WMI and ETW to write trace
output during/after boot to various locations. Starting with Windows Vista,
WMI creates an active trace channel during the boot process which is allot
more effective than dmesg so I would look at evntrace.h. Only errors are
logged. Windows later writes to COM1 once the driver loads, WMI is
implemented in the kernel and (should be loaded) very early into the boot
process.
At points before these services are available (I.E. NTLDR) Windows writes
output to the console or does a KeBugCheck, then later to WMI/ETW, COM1,
then DBWIN_BUFFER in that order. I would prefer output to the screen as much
as possible until these services are up and it can write to the bootlog file
and ETW for the Event Log.
What compartability did you mean?
How do you propose someone obtain these messages during and after boot
without writing new tools? Since the goal of ROS is more or less
compatibility, not all devs coming from Windows would expect something like
that to be holding trace/debug output. I can use windbg, dbgview, event
viewer and ETW log files to view this stuff on Windows so why implement
something else completely different for ROS? The goal should be increased
compatibility with Windows, not less.
Any bugs, errors occurred during that process of
printing into that
MappedView associated with "DBWIN_BUFFER" FileMapping
are reported to kernel
with DbgPrint.
Where should these errors be stored?
DebugPrint uses OutputDebugString.
Linux in past has such shared memory object, but
practically, now, it is
overridden by the system call.
So my question remains
Subject: Advice required on User-mode to Kernel mode call for
syslog(2) analog in ROS
From user-mode to kernel, My advice would be anything
that lets me use
existing user-mode tools like Winbdg, dbgview, Event Viewer,
notepad.