Re: [ros-dev] Advice required on User-mode to Kernel mode call for syslog(2) analog in ROS

[Minas Abrahamyan]

To All:

What is needed is reverse thing for DebugService ( as described here:
http://alter.org.ua/docs/nt_kernel/kdprint/)
: KdpTrap is called to print (store?) debug message somewhere,
what is needed, is something that will extract back stored messages.
dmesg patch successfully stores debug messages
in buffer, some kernel code should give them back.

Roughly speaking needed the piece of DeviceIOControl that copies
memory from kernel mode to back to user mode.

Any help is welcomed!

***

Returning to discussion with dmex:

What I'm speaking is totally different.

>   it can write to the bootlog file and ETW for the Event
> Log.
>  user-mode tools like Winbdg, dbgview, Event Viewer, notepad. 
All these things
require stable working user-mode code, perfectly
booted up kernel, etc.

To get there is is needed to debug the kernel.
If you haven't serial cable, or have, but your machine hasn't
COM-port, as in my case,
then you have no other choice to use my dmesg command in kdbg - ROS
kernel debugger.

After corrections your machine is booted up. Now you'd just want to
look on these debug
messages stored in DmesgBuffer: to review it, to review found bugs,
quirks, at last to mail it somewhere,
say into bugzilla. Or compare working installation with not working
one - the effective way! This
trick has helped me many times.

After that it could use whatever whistles you want: Winbdg, dbgview,
Event Viewer, notepad, notepad++, notepad+=10 etc.
But! At start, working system is needed.
It could even have 'OutputDebugString' interface. I didn't ever say
this should be the only one implementation.
I just want tools to help booting up the ROS. not more. _but not less_.

But you are looking only of perspective of fully functional Windows.
That is not the case with ROS.

>   DebugPrint uses OutputDebugString. 
No, no! just
the opposite, look at calls hierarchy tables at
http://alter.org.ua/docs/nt_kernel/kdprint/

OutputDebugString is user-mode code. If you have user-mode perfectly working -
you use dbgviews and you need nothing more. All is working already at
that moment.

***

Best regards,
M.A.


On Tue, Apr 12, 2011 at 9:49 PM, dmex <dmex04(a)gmail.com> wrote:
>>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.
>