Advice required on User-mode to Kernel mode call for syslog(2) analog in ROS

[Minas Abrahamyan]

Hi all,

I'm going to implement dmesg.exe, a ROS application to read dmesg/kmsg
buffer (debug messages in kernel buffer),
which is filled in by appropriate patch 6018
(here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW,
it's not yet reviewed and not applied!).

So I'm requesting advice on:
What would be the better way for user-mode code to get the contents of
kmsg buffer in kernel-space (kdbg)?

Shortly:
Linux has special system call "syslog" (man 2 syslog)
FreeBSD uses its special sysctl interface to kernel along with
'kern.msgbuf' parameter.

My questions:
Do we need special system call like Linux, or even more, the whole
family of them (sysctl('*')) as in BSD?
How to implement simple system call for it, now?

---
Now detailed info for unices:

Linux case:
* syslog(2) - read and/or clear kernel message ring buffer; set console_loglevel
int syslog(int type, char *bufp, int len);

* also /proc/kmsg virtual file, which when being read returns buffer contents
==excerpt from man proc ==
/proc/kmsg
              This file can be used instead of the syslog(2)  system
call  to  read  kernel  messages.   A
              process  must  have  superuser privileges to read this
file, and only one process should read
              this file.  This file should not be read if a syslog
process is running which uses  the  sys‐
              log(2) system call facility to log kernel messages.

Information in this file is retrieved with the dmesg(1) program.
==eo exerpt==

dmesg in FreeBSD:
Parameter 'kern.msgbuf' given to sysctl(3)  returns contents of kernel
message buffer.
There is also 'kern.msgbuf_clear' to clean the buffer.
---

WBR,
Minas Abrahamyan

[Samuel serapion]

Checkout
http://svn.reactos.org/svn/reactos/trunk/rosapps/applications/sysutils/utils...
for kicks
On Apr 5, 2011 8:11 PM, "Minas Abrahamyan" [e-mail] wrote:
> Hi all,
>
> I'm going to implement dmesg.exe, a ROS application to read dmesg/kmsg
> buffer (debug messages in kernel buffer),
> which is filled in by appropriate patch 6018
> (here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW,
> it's not yet reviewed and not applied!).
>
> So I'm requesting advice on:
> What would be the better way for user-mode code to get the contents of
> kmsg buffer in kernel-space (kdbg)?
>
> Shortly:
> Linux has special system call "syslog" (man 2 syslog)
> FreeBSD uses its special sysctl interface to kernel along with
> 'kern.msgbuf' parameter.
>
> My questions:
> Do we need special system call like Linux, or even more, the whole
> family of them (sysctl('*')) as in BSD?
> How to implement simple system call for it, now?
>
> Now detailed info for unices:
>
> Linux case:
> syslog(2) - read and/or clear kernel message ring buffer; set

console_loglevel
> int syslog(int type, char *bufp, int len);
> also /proc/kmsg virtual file, which when being read returns buffer

contents
> ==excerpt from man proc ==
> /proc/kmsg
>              This file can be used instead of the syslog(2)  system
> call  to  read  kernel  messages.   A
>              process  must  have  superuser privileges to read this
> file, and only one process should read
>              this file.  This file should not be read if a syslog
> process is running which uses  the  sys‐
>              log(2) system call facility to log kernel messages.
>          Information in this file is retrieved with the dmesg(1)

program.
> ==eo exerpt==
>
> dmesg in FreeBSD:
> Parameter 'kern.msgbuf' given to sysctl(3)  returns contents of kernel
> message buffer.
> There is also 'kern.msgbuf_clear' to clean the buffer.
>
> WBR,
> Minas Abrahamyan
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Sven Barth]

Am 06.04.2011 02:09, schrieb Minas Abrahamyan:
> Hi all,
>
> I'm going to implement dmesg.exe, a ROS application to read dmesg/kmsg
> buffer (debug messages in kernel buffer),
> which is filled in by appropriate patch 6018
> (here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW,
> it's not yet reviewed and not applied!).
>
> So I'm requesting advice on:
> What would be the better way for user-mode code to get the contents of
> kmsg buffer in kernel-space (kdbg)?
>
> Shortly:
> Linux has special system call "syslog" (man 2 syslog)
> FreeBSD uses its special sysctl interface to kernel along with
> 'kern.msgbuf' parameter.
>
> My questions:
> Do we need special system call like Linux, or even more, the whole
> family of them (sysctl('*')) as in BSD?
> How to implement simple system call for it, now?

I'm not one of the ReactOS devs and also I'm not writing much here, but 
what about implementing a (legacy type) device driver that provides a 
device object (e.g. \Device\kmsg) that can be read from (no writing 
though) and some code for DeviceIOControl to clear/config the buffer?

Regards,
Sven

[dmex]

What's wrong with current method of using the memory mapped 'DBWIN_BUFFER'
file for outputting kernel messages?

Two or three different kernel implementations for the same thing seems a bit
retarded and breaks compatibility with existing applications like Dbgview.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Sven Barth
Sent: Wednesday, 6 April 2011 8:54 PM
To: [e-mail]
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode call for
syslog(2) analog in ROS

Am 06.04.2011 02:09, schrieb Minas Abrahamyan:
> Hi all,
>
> I'm going to implement dmesg.exe, a ROS application to read dmesg/kmsg 
> buffer (debug messages in kernel buffer), which is filled in by 
> appropriate patch 6018
> (here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW, 
> it's not yet reviewed and not applied!).
>
> So I'm requesting advice on:
> What would be the better way for user-mode code to get the contents of 
> kmsg buffer in kernel-space (kdbg)?
>
> Shortly:
> Linux has special system call "syslog" (man 2 syslog) FreeBSD uses its 
> special sysctl interface to kernel along with 'kern.msgbuf' parameter.
>
> My questions:
> Do we need special system call like Linux, or even more, the whole 
> family of them (sysctl('*')) as in BSD?
> How to implement simple system call for it, now?

I'm not one of the ReactOS devs and also I'm not writing much here, but what
about implementing a (legacy type) device driver that provides a device
object (e.g. \Device\kmsg) that can be read from (no writing
though) and some code for DeviceIOControl to clear/config the buffer?

Regards,
Sven

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Sven Barth]

On 06.04.2011 21:26, dmex wrote:
> What's wrong with current method of using the memory mapped 'DBWIN_BUFFER'
> file for outputting kernel messages?

That I didn't know about it :P
> Two or three different kernel implementations for the same thing seems a bit
> retarded and breaks compatibility with existing applications like Dbgview.

I'm just looking at the source of ReactOS from time to time when I have 
the need to check out how a certain function behaves under the hood 
(especially while I ported the Free Pascal compiler to the Native NT 
API), but I weren't yet aware how those debug outputs work.
As Minas mentioned that he'd like to add a syscall/API function 
compareable to syslog I just thought that it would be wiser (from my 
restricted point of view) to write a driver for this that would allow to 
extend the system dynamically.

Regards,
Sven
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Sven Barth
> Sent: Wednesday, 6 April 2011 8:54 PM
> To: [e-mail]
> Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode call for
> syslog(2) analog in ROS
>
> Am 06.04.2011 02:09, schrieb Minas Abrahamyan:
> > Hi all,
> >
> > I'm going to implement dmesg.exe, a ROS application to read dmesg/kmsg
> > buffer (debug messages in kernel buffer), which is filled in by
> > appropriate patch 6018
> > (here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW,
> > it's not yet reviewed and not applied!).
> >
> > So I'm requesting advice on:
> > What would be the better way for user-mode code to get the contents of
> > kmsg buffer in kernel-space (kdbg)?
> >
> > Shortly:
> > Linux has special system call "syslog" (man 2 syslog) FreeBSD uses its
> > special sysctl interface to kernel along with 'kern.msgbuf' parameter.
> >
> > My questions:
> > Do we need special system call like Linux, or even more, the whole
> > family of them (sysctl('*')) as in BSD?
> > How to implement simple system call for it, now?
>
> I'm not one of the ReactOS devs and also I'm not writing much here, but what
> about implementing a (legacy type) device driver that provides a device
> object (e.g. \Device\kmsg) that can be read from (no writing
> though) and some code for DeviceIOControl to clear/config the buffer?
>
> Regards,
> Sven
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[dmex]

DebugPring/OutputDebugString would be a good place to start learning how
Windows outputs kernel messages ;)
http://sumeshvv.wordpress.com/2010/12/02/how-the-outputdebugstring-api-works
/

ReactOS OutputDebugString Source:
http://doxygen.reactos.org/da/def/dll_2win32_2kernel32_2debug_2output_8c_a94
90feb381d7062ca6e5a28bdeacd6d2.html

Minas's idea is terrible in my opinion, "Do we need special system call like
Linux, or even more, the whole family of them (sysctl('*')) as in BSD?" as
ReactOS is designed for binary compatibility with Windows, Not BSD or Linux
and it should stay that way.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Sven Barth
Sent: Thursday, 7 April 2011 4:05 AM
To: [e-mail]
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode call for
syslog(2) analog in ROS

On 06.04.2011 21:26, dmex wrote:
> What's wrong with current method of using the memory mapped 'DBWIN_BUFFER'
> file for outputting kernel messages?

That I didn't know about it :P
> Two or three different kernel implementations for the same thing seems 
> a bit retarded and breaks compatibility with existing applications like

Dbgview.
>

I'm just looking at the source of ReactOS from time to time when I have the
need to check out how a certain function behaves under the hood (especially
while I ported the Free Pascal compiler to the Native NT API), but I weren't
yet aware how those debug outputs work.
As Minas mentioned that he'd like to add a syscall/API function compareable
to syslog I just thought that it would be wiser (from my restricted point of
view) to write a driver for this that would allow to extend the system
dynamically.

Regards,
Sven
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Sven Barth
> Sent: Wednesday, 6 April 2011 8:54 PM
> To: [e-mail]
> Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode 
> call for
> syslog(2) analog in ROS
>
> Am 06.04.2011 02:09, schrieb Minas Abrahamyan:
> > Hi all,
> >
> > I'm going to implement dmesg.exe, a ROS application to read 
> > dmesg/kmsg buffer (debug messages in kernel buffer), which is filled 
> > in by appropriate patch 6018
> > (here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW, 
> > it's not yet reviewed and not applied!).
> >
> > So I'm requesting advice on:
> > What would be the better way for user-mode code to get the contents 
> > of kmsg buffer in kernel-space (kdbg)?
> >
> > Shortly:
> > Linux has special system call "syslog" (man 2 syslog) FreeBSD uses 
> > its special sysctl interface to kernel along with 'kern.msgbuf'

parameter.
> > My questions:
> > Do we need special system call like Linux, or even more, the whole 
> > family of them (sysctl('*')) as in BSD?
> > How to implement simple system call for it, now?
>
> I'm not one of the ReactOS devs and also I'm not writing much here, 
> but what about implementing a (legacy type) device driver that 
> provides a device object (e.g. \Device\kmsg) that can be read from (no 
> writing
> though) and some code for DeviceIOControl to clear/config the buffer?
>
> Regards,
> Sven
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Sven Barth]

On 06.04.2011 22:53, dmex wrote:
> DebugPring/OutputDebugString would be a good place to start learning how
> Windows outputs kernel messages ;)
> http://sumeshvv.wordpress.com/2010/12/02/how-the-outputdebugstring-api-works
> /
>
> ReactOS OutputDebugString Source:
> http://doxygen.reactos.org/da/def/dll_2win32_2kernel32_2debug_2output_8c_a94
> 90feb381d7062ca6e5a28bdeacd6d2.html

I'll put that on my todo list once I have a few minutes :D
> Minas's idea is terrible in my opinion, "Do we need special system call like
> Linux, or even more, the whole family of them (sysctl('*')) as in BSD?" as
> ReactOS is designed for binary compatibility with Windows, Not BSD or Linux
> and it should stay that way.

And that's why I suggested a device driver... so one can add once own 
"extensions" without sacrificing compatibility :)
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Sven Barth
> Sent: Thursday, 7 April 2011 4:05 AM
> To: [e-mail]
> Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode call for
> syslog(2) analog in ROS
>
> On 06.04.2011 21:26, dmex wrote:
> > What's wrong with current method of using the memory mapped 'DBWIN_BUFFER'
> > file for outputting kernel messages?
>
> That I didn't know about it :P
> > Two or three different kernel implementations for the same thing seems
> > a bit retarded and breaks compatibility with existing applications like
>
> Dbgview.
> >
>
> I'm just looking at the source of ReactOS from time to time when I have the
> need to check out how a certain function behaves under the hood (especially
> while I ported the Free Pascal compiler to the Native NT API), but I weren't
> yet aware how those debug outputs work.
> As Minas mentioned that he'd like to add a syscall/API function compareable
> to syslog I just thought that it would be wiser (from my restricted point of
> view) to write a driver for this that would allow to extend the system
> dynamically.
>
> Regards,
> Sven
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > On Behalf Of Sven Barth
> > Sent: Wednesday, 6 April 2011 8:54 PM
> > To: [e-mail]
> > Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode
> > call for
> > syslog(2) analog in ROS
> >
> > Am 06.04.2011 02:09, schrieb Minas Abrahamyan:
> > > Hi all,
> > >
> > > I'm going to implement dmesg.exe, a ROS application to read
> > > dmesg/kmsg buffer (debug messages in kernel buffer), which is filled
> > > in by appropriate patch 6018
> > > (here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW,
> > > it's not yet reviewed and not applied!).
> > >
> > > So I'm requesting advice on:
> > > What would be the better way for user-mode code to get the contents
> > > of kmsg buffer in kernel-space (kdbg)?
> > >
> > > Shortly:
> > > Linux has special system call "syslog" (man 2 syslog) FreeBSD uses
> > > its special sysctl interface to kernel along with 'kern.msgbuf'
>
> parameter.
> > > My questions:
> > > Do we need special system call like Linux, or even more, the whole
> > > family of them (sysctl('*')) as in BSD?
> > > How to implement simple system call for it, now?
> >
> > I'm not one of the ReactOS devs and also I'm not writing much here,
> > but what about implementing a (legacy type) device driver that
> > provides a device object (e.g. \Device\kmsg) that can be read from (no
> > writing
> > though) and some code for DeviceIOControl to clear/config the buffer?
> >
> > Regards,
> > Sven
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[dmex]

-And that's why I suggested a device driver... so one can add once own
"extensions" without sacrificing compatibility :)

That could work, It could read or write the 'DBWIN_BUFFER' file and allow a
replacement driver to support outputs using other methods.

I also apologize for my last e-mail, It was very harsh, totally unwarranted
and uncalled for.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Sven Barth
Sent: Thursday, 7 April 2011 5:10 AM
To: [e-mail]
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode call for
syslog(2) analog in ROS

On 06.04.2011 22:53, dmex wrote:
> DebugPring/OutputDebugString would be a good place to start learning 
> how Windows outputs kernel messages ;) 
> http://sumeshvv.wordpress.com/2010/12/02/how-the-outputdebugstring-api
> -works
> /
>
> ReactOS OutputDebugString Source:
> http://doxygen.reactos.org/da/def/dll_2win32_2kernel32_2debug_2output_
> 8c_a94
> 90feb381d7062ca6e5a28bdeacd6d2.html

I'll put that on my todo list once I have a few minutes :D
> Minas's idea is terrible in my opinion, "Do we need special system 
> call like Linux, or even more, the whole family of them (sysctl('*')) 
> as in BSD?" as ReactOS is designed for binary compatibility with 
> Windows, Not BSD or Linux and it should stay that way.

And that's why I suggested a device driver... so one can add once own
"extensions" without sacrificing compatibility :)
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Sven Barth
> Sent: Thursday, 7 April 2011 4:05 AM
> To: [e-mail]
> Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode 
> call for
> syslog(2) analog in ROS
>
> On 06.04.2011 21:26, dmex wrote:
> > What's wrong with current method of using the memory mapped

'DBWIN_BUFFER'
> > file for outputting kernel messages?
>
> That I didn't know about it :P
> > Two or three different kernel implementations for the same thing 
> > seems a bit retarded and breaks compatibility with existing 
> > applications like
>
> Dbgview.
> >
>
> I'm just looking at the source of ReactOS from time to time when I 
> have the need to check out how a certain function behaves under the 
> hood (especially while I ported the Free Pascal compiler to the Native 
> NT API), but I weren't yet aware how those debug outputs work.
> As Minas mentioned that he'd like to add a syscall/API function 
> compareable to syslog I just thought that it would be wiser (from my 
> restricted point of
> view) to write a driver for this that would allow to extend the system 
> dynamically.
>
> Regards,
> Sven
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]]
> > On Behalf Of Sven Barth
> > Sent: Wednesday, 6 April 2011 8:54 PM
> > To: [e-mail]
> > Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode 
> > call for
> > syslog(2) analog in ROS
> >
> > Am 06.04.2011 02:09, schrieb Minas Abrahamyan:
> > > Hi all,
> > >
> > > I'm going to implement dmesg.exe, a ROS application to read 
> > > dmesg/kmsg buffer (debug messages in kernel buffer), which is filled 
> > > in by appropriate patch 6018
> > > (here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW, 
> > > it's not yet reviewed and not applied!).
> > >
> > > So I'm requesting advice on:
> > > What would be the better way for user-mode code to get the contents 
> > > of kmsg buffer in kernel-space (kdbg)?
> > >
> > > Shortly:
> > > Linux has special system call "syslog" (man 2 syslog) FreeBSD uses 
> > > its special sysctl interface to kernel along with 'kern.msgbuf'
>
> parameter.
> > > My questions:
> > > Do we need special system call like Linux, or even more, the whole 
> > > family of them (sysctl('*')) as in BSD?
> > > How to implement simple system call for it, now?
> >
> > I'm not one of the ReactOS devs and also I'm not writing much here, 
> > but what about implementing a (legacy type) device driver that 
> > provides a device object (e.g. \Device\kmsg) that can be read from 
> > (no writing
> > though) and some code for DeviceIOControl to clear/config the buffer?
> >
> > Regards,
> > Sven
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Sven Barth]

Am 06.04.2011 23:20, schrieb dmex:
> -And that's why I suggested a device driver... so one can add once own
> "extensions" without sacrificing compatibility :)
>
> That could work, It could read or write the 'DBWIN_BUFFER' file and allow a
> replacement driver to support outputs using other methods.
>
> I also apologize for my last e-mail, It was very harsh, totally unwarranted
> and uncalled for.

Seems like your "harshness" didn't come along as you "wanted" it to... 
Or perhaps I was to tired to recognize that it was meant in a harsh 
way... ^^

Regards,
Sven
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Sven Barth
> Sent: Thursday, 7 April 2011 5:10 AM
> To: [e-mail]
> Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode call for
> syslog(2) analog in ROS
>
> On 06.04.2011 22:53, dmex wrote:
> > DebugPring/OutputDebugString would be a good place to start learning
> > how Windows outputs kernel messages ;)
> > http://sumeshvv.wordpress.com/2010/12/02/how-the-outputdebugstring-api
> > -works
> > /
> >
> > ReactOS OutputDebugString Source:
> > http://doxygen.reactos.org/da/def/dll_2win32_2kernel32_2debug_2output_
> > 8c_a94
> > 90feb381d7062ca6e5a28bdeacd6d2.html
>
> I'll put that on my todo list once I have a few minutes :D
> > Minas's idea is terrible in my opinion, "Do we need special system
> > call like Linux, or even more, the whole family of them (sysctl('*'))
> > as in BSD?" as ReactOS is designed for binary compatibility with
> > Windows, Not BSD or Linux and it should stay that way.
>
> And that's why I suggested a device driver... so one can add once own
> "extensions" without sacrificing compatibility :)
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > On Behalf Of Sven Barth
> > Sent: Thursday, 7 April 2011 4:05 AM
> > To: [e-mail]
> > Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode
> > call for
> > syslog(2) analog in ROS
> >
> > On 06.04.2011 21:26, dmex wrote:
> > > What's wrong with current method of using the memory mapped
>
> 'DBWIN_BUFFER'
> > > file for outputting kernel messages?
> >
> > That I didn't know about it :P
> > > Two or three different kernel implementations for the same thing
> > > seems a bit retarded and breaks compatibility with existing
> > > applications like
> >
> > Dbgview.
> > >
> >
> > I'm just looking at the source of ReactOS from time to time when I
> > have the need to check out how a certain function behaves under the
> > hood (especially while I ported the Free Pascal compiler to the Native
> > NT API), but I weren't yet aware how those debug outputs work.
> > As Minas mentioned that he'd like to add a syscall/API function
> > compareable to syslog I just thought that it would be wiser (from my
> > restricted point of
> > view) to write a driver for this that would allow to extend the system
> > dynamically.
> >
> > Regards,
> > Sven
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]
> > > On Behalf Of Sven Barth
> > > Sent: Wednesday, 6 April 2011 8:54 PM
> > > To: [e-mail]
> > > Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode
> > > call for
> > > syslog(2) analog in ROS
> > >
> > > Am 06.04.2011 02:09, schrieb Minas Abrahamyan:
> > > > Hi all,
> > > >
> > > > I'm going to implement dmesg.exe, a ROS application to read
> > > > dmesg/kmsg buffer (debug messages in kernel buffer), which is filled
> > > > in by appropriate patch 6018
> > > > (here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW,
> > > > it's not yet reviewed and not applied!).
> > > >
> > > > So I'm requesting advice on:
> > > > What would be the better way for user-mode code to get the contents
> > > > of kmsg buffer in kernel-space (kdbg)?
> > > >
> > > > Shortly:
> > > > Linux has special system call "syslog" (man 2 syslog) FreeBSD uses
> > > > its special sysctl interface to kernel along with 'kern.msgbuf'
> >
> > parameter.
> > > > My questions:
> > > > Do we need special system call like Linux, or even more, the whole
> > > > family of them (sysctl('*')) as in BSD?
> > > > How to implement simple system call for it, now?
> > >
> > > I'm not one of the ReactOS devs and also I'm not writing much here,
> > > but what about implementing a (legacy type) device driver that
> > > provides a device object (e.g. \Device\kmsg) that can be read from
> > > (no writing
> > > though) and some code for DeviceIOControl to clear/config the buffer?
> > >
> > > Regards,
> > > Sven
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[dmex]

It was 2am and I was being 'trolled'/abused for my lack of enthusiasm and
support for Linux, I regret it spilled over in my reply for a completely
different subject.

I'm pacifist and it was by no means supposed to be harsh and should not have
been directed at others about an unrelated subject.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Sven Barth
Sent: Thursday, 7 April 2011 3:14 PM
To: [e-mail]
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode call for
syslog(2) analog in ROS

Am 06.04.2011 23:20, schrieb dmex:
> -And that's why I suggested a device driver... so one can add once own 
> "extensions" without sacrificing compatibility :)
>
> That could work, It could read or write the 'DBWIN_BUFFER' file and 
> allow a replacement driver to support outputs using other methods.
>
> I also apologize for my last e-mail, It was very harsh, totally 
> unwarranted and uncalled for.

Seems like your "harshness" didn't come along as you "wanted" it to... 
Or perhaps I was to tired to recognize that it was meant in a harsh way...
^^

Regards,
Sven
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Sven Barth
> Sent: Thursday, 7 April 2011 5:10 AM
> To: [e-mail]
> Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode 
> call for
> syslog(2) analog in ROS
>
> On 06.04.2011 22:53, dmex wrote:
> > DebugPring/OutputDebugString would be a good place to start learning 
> > how Windows outputs kernel messages ;) 
> > http://sumeshvv.wordpress.com/2010/12/02/how-the-outputdebugstring-ap
> > i
> > -works
> > /
> >
> > ReactOS OutputDebugString Source:
> > http://doxygen.reactos.org/da/def/dll_2win32_2kernel32_2debug_2output
> > _
> > 8c_a94
> > 90feb381d7062ca6e5a28bdeacd6d2.html
>
> I'll put that on my todo list once I have a few minutes :D
> > Minas's idea is terrible in my opinion, "Do we need special system 
> > call like Linux, or even more, the whole family of them (sysctl('*')) 
> > as in BSD?" as ReactOS is designed for binary compatibility with 
> > Windows, Not BSD or Linux and it should stay that way.
>
> And that's why I suggested a device driver... so one can add once own 
> "extensions" without sacrificing compatibility :)
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]]
> > On Behalf Of Sven Barth
> > Sent: Thursday, 7 April 2011 4:05 AM
> > To: [e-mail]
> > Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode 
> > call for
> > syslog(2) analog in ROS
> >
> > On 06.04.2011 21:26, dmex wrote:
> > > What's wrong with current method of using the memory mapped
>
> 'DBWIN_BUFFER'
> > > file for outputting kernel messages?
> >
> > That I didn't know about it :P
> > > Two or three different kernel implementations for the same thing 
> > > seems a bit retarded and breaks compatibility with existing 
> > > applications like
> >
> > Dbgview.
> > >
> >
> > I'm just looking at the source of ReactOS from time to time when I 
> > have the need to check out how a certain function behaves under the 
> > hood (especially while I ported the Free Pascal compiler to the 
> > Native NT API), but I weren't yet aware how those debug outputs work.
> > As Minas mentioned that he'd like to add a syscall/API function 
> > compareable to syslog I just thought that it would be wiser (from my 
> > restricted point of
> > view) to write a driver for this that would allow to extend the 
> > system dynamically.
> >
> > Regards,
> > Sven
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]
> > > On Behalf Of Sven Barth
> > > Sent: Wednesday, 6 April 2011 8:54 PM
> > > To: [e-mail]
> > > Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode 
> > > call for
> > > syslog(2) analog in ROS
> > >
> > > Am 06.04.2011 02:09, schrieb Minas Abrahamyan:
> > > > Hi all,
> > > >
> > > > I'm going to implement dmesg.exe, a ROS application to read 
> > > > dmesg/kmsg buffer (debug messages in kernel buffer), which is 
> > > > filled in by appropriate patch 6018
> > > > (here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW, 
> > > > it's not yet reviewed and not applied!).
> > > >
> > > > So I'm requesting advice on:
> > > > What would be the better way for user-mode code to get the contents 
> > > > of kmsg buffer in kernel-space (kdbg)?
> > > >
> > > > Shortly:
> > > > Linux has special system call "syslog" (man 2 syslog) FreeBSD uses 
> > > > its special sysctl interface to kernel along with 'kern.msgbuf'
> >
> > parameter.
> > > > My questions:
> > > > Do we need special system call like Linux, or even more, the whole 
> > > > family of them (sysctl('*')) as in BSD?
> > > > How to implement simple system call for it, now?
> > >
> > > I'm not one of the ReactOS devs and also I'm not writing much here, 
> > > but what about implementing a (legacy type) device driver that 
> > > provides a device object (e.g. \Device\kmsg) that can be read from 
> > > (no writing
> > > though) and some code for DeviceIOControl to clear/config the buffer?
> > >
> > > Regards,
> > > Sven
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Sven Barth]

Am 07.04.2011 09:37, schrieb dmex:
> It was 2am and I was being 'trolled'/abused for my lack of enthusiasm and
> support for Linux, I regret it spilled over in my reply for a completely
> different subject.
>
> I'm pacifist and it was by no means supposed to be harsh and should not have
> been directed at others about an unrelated subject.

No harm was done.

As said: I didn't even notice it :P

Regards,
Sven
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Sven Barth
> Sent: Thursday, 7 April 2011 3:14 PM
> To: [e-mail]
> Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode call for
> syslog(2) analog in ROS
>
> Am 06.04.2011 23:20, schrieb dmex:
> > -And that's why I suggested a device driver... so one can add once own
> > "extensions" without sacrificing compatibility :)
> >
> > That could work, It could read or write the 'DBWIN_BUFFER' file and
> > allow a replacement driver to support outputs using other methods.
> >
> > I also apologize for my last e-mail, It was very harsh, totally
> > unwarranted and uncalled for.
>
> Seems like your "harshness" didn't come along as you "wanted" it to...
> Or perhaps I was to tired to recognize that it was meant in a harsh way...
> ^^
>
> Regards,
> Sven
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > On Behalf Of Sven Barth
> > Sent: Thursday, 7 April 2011 5:10 AM
> > To: [e-mail]
> > Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode
> > call for
> > syslog(2) analog in ROS
> >
> > On 06.04.2011 22:53, dmex wrote:
> > > DebugPring/OutputDebugString would be a good place to start learning
> > > how Windows outputs kernel messages ;)
> > > http://sumeshvv.wordpress.com/2010/12/02/how-the-outputdebugstring-ap
> > > i
> > > -works
> > > /
> > >
> > > ReactOS OutputDebugString Source:
> > > http://doxygen.reactos.org/da/def/dll_2win32_2kernel32_2debug_2output
> > > _
> > > 8c_a94
> > > 90feb381d7062ca6e5a28bdeacd6d2.html
> >
> > I'll put that on my todo list once I have a few minutes :D
> > > Minas's idea is terrible in my opinion, "Do we need special system
> > > call like Linux, or even more, the whole family of them (sysctl('*'))
> > > as in BSD?" as ReactOS is designed for binary compatibility with
> > > Windows, Not BSD or Linux and it should stay that way.
> >
> > And that's why I suggested a device driver... so one can add once own
> > "extensions" without sacrificing compatibility :)
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]
> > > On Behalf Of Sven Barth
> > > Sent: Thursday, 7 April 2011 4:05 AM
> > > To: [e-mail]
> > > Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode
> > > call for
> > > syslog(2) analog in ROS
> > >
> > > On 06.04.2011 21:26, dmex wrote:
> > > > What's wrong with current method of using the memory mapped
> >
> > 'DBWIN_BUFFER'
> > > > file for outputting kernel messages?
> > >
> > > That I didn't know about it :P
> > > > Two or three different kernel implementations for the same thing
> > > > seems a bit retarded and breaks compatibility with existing
> > > > applications like
> > >
> > > Dbgview.
> > > >
> > >
> > > I'm just looking at the source of ReactOS from time to time when I
> > > have the need to check out how a certain function behaves under the
> > > hood (especially while I ported the Free Pascal compiler to the
> > > Native NT API), but I weren't yet aware how those debug outputs work.
> > > As Minas mentioned that he'd like to add a syscall/API function
> > > compareable to syslog I just thought that it would be wiser (from my
> > > restricted point of
> > > view) to write a driver for this that would allow to extend the
> > > system dynamically.
> > >
> > > Regards,
> > > Sven
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]]
> > > > On Behalf Of Sven Barth
> > > > Sent: Wednesday, 6 April 2011 8:54 PM
> > > > To: [e-mail]
> > > > Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode
> > > > call for
> > > > syslog(2) analog in ROS
> > > >
> > > > Am 06.04.2011 02:09, schrieb Minas Abrahamyan:
> > > > > Hi all,
> > > > >
> > > > > I'm going to implement dmesg.exe, a ROS application to read
> > > > > dmesg/kmsg buffer (debug messages in kernel buffer), which is
> > > > > filled in by appropriate patch 6018
> > > > > (here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW,
> > > > > it's not yet reviewed and not applied!).
> > > > >
> > > > > So I'm requesting advice on:
> > > > > What would be the better way for user-mode code to get the contents
> > > > > of kmsg buffer in kernel-space (kdbg)?
> > > > >
> > > > > Shortly:
> > > > > Linux has special system call "syslog" (man 2 syslog) FreeBSD uses
> > > > > its special sysctl interface to kernel along with 'kern.msgbuf'
> > >
> > > parameter.
> > > > > My questions:
> > > > > Do we need special system call like Linux, or even more, the whole
> > > > > family of them (sysctl('*')) as in BSD?
> > > > > How to implement simple system call for it, now?
> > > >
> > > > I'm not one of the ReactOS devs and also I'm not writing much here,
> > > > but what about implementing a (legacy type) device driver that
> > > > provides a device object (e.g. \Device\kmsg) that can be read from
> > > > (no writing
> > > > though) and some code for DeviceIOControl to clear/config the buffer?
> > > >
> > > > Regards,
> > > > Sven
> > > >
> > > > Ros-dev mailing list
> > > > [e-mail]
> > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > > >
> > > > Ros-dev mailing list
> > > > [e-mail]
> > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Minas Abrahamyan]

On Thu, Apr 7, 2011 at 12:26 AM, dmex [e-mail] wrote:
> What's wrong with current method of using the memory mapped 'DBWIN_BUFFER'
> file for outputting kernel messages?

Nothing wrong: it just doesn't exist.
> Two or three different kernel implementations

No any implementation to store kernel debug messages, the only one I
know is the dmesg kernel patch I talked about
(issue 6018)
> for the same thing

Please point me the same thing. Two or three implementations.
> breaks compatibility with existing applications like Dbgview.

What compartability did you mean?
The *only* mention about "DBWIN_BUFFER" was in
\dll\win32\kernel32\debug\output.c:266, the line:
==
 hDBMonBuffer = OpenFileMappingW(SECTION_MAP_WRITE, FALSE, L"DBWIN_BUFFER");
==
So, as far as I see, Opening FileMapping without Creating it first,
could not work.

--
But even that is not such important. 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?

===

Why specific service is needed. Well, here:
[http://alter.org.ua/docs/nt_kernel/kdprint/  KdPrint/DbgPrint and
OutputDebugString behavior] at Alter's site,
 and here:
[http://www.codeproject.com/KB/winsdk/OutputDebugString.aspx?display=Print
Mechanism of OutputDebugString - CodeProject] the ready code sample,
they discuss internals and mechanism of OutputDebugString.  So
definitely Windows too uses system call to read data from kernel debug
buffer.
As unices do so too.
And there is no other way.

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

Regards,
M.A.

[dmex]

> 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.

[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 [e-mail] 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.