VOTE: Switch to Wine Debug System

[Alex Ionescu]

VOTING TOPIC: Switch to Wine Debug System, a run-time configurable Debug 
System in which various debug modes can be used (TRACE, WARN, FIXME, 
ERROR, etc). It would use DbgPrintEx along with Debug Filters (just like 
on XP) which can be configured at run-time in the registry to set how 
many of the messages to show. I believe the current WINE system has the 
library doing all this checking, but it's possible they do actually use 
the NT method. DbgPrintEx and filter states are currently unimplemented 
in our ntdll/ntoskrnl, so they must be implemented. Additionally, these 
Debug Messages would only be inserted into the code for a DBG build, 
just like it is currently done now. Finally, using this system will 
allow us to better share code with WINE.

PROS:
              - Configurable debugging
              - More versatility then just "Print Always" and "Print if 
I remove NDEBUG"
              - Better code sharing with WINE
              - Will lead to the implementation of some DbgPrint 
functions which NT Drivers are bound to use.

CONS:
              - Requires developer time to switch to this system.
              - Requires implementing some Kernel Functions.

VOTING TIME: 2 weeks. Results announced Monday 23rd at 5PM EST.

VOTING CHOICES:
                                  - Yes! Get rid of DPRINT/DPRINT1 and 
implement a run-time configurable Debug System with multiple verbose 
levels, based on WINE syntax and Windows NT implementation.
                                  - No! Stick with the current static, 
compile-time DPRINT/DPRINT1 system.

VOTING OPEN TO: Due to the nature of this source-level change, voting is 
opened only to developers.

Best regards,
Alex Ionescu

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Alex Ionescu
> Sent: 8. maj 2005 20:30
> To: ReactOS Development List
> Subject: [ros-dev] VOTE: Switch to Wine Debug System
>
> VOTING CHOICES:
>                                   - Yes! Get rid of DPRINT/DPRINT1 and
> implement a run-time configurable Debug System with multiple verbose
> levels, based on WINE syntax and Windows NT implementation.

What, no checkboxes? ;-) I'm pro implementing this system. I would
also like to see the compiler evaluate any expressions in non-DBG builds.
We could put it inside an "if (0)" so the compiler will optimize it away.
A significant percentage of our build errors are due to these expressions
not being evaluated in non-DBG mode.
>                               - No! Stick with the current static,
>
> compile-time DPRINT/DPRINT1 system.
>
> VOTING OPEN TO: Due to the nature of this source-level change, voting is
> opened only to developers.

[Phillip Susi]

I agree, evaluating the debug expressions all the time would be nice.  
And being able to tune the amount of debug prints at runtime would be 
very handy as well.

Casper Hornstrup wrote:
> What, no checkboxes? ;-) I'm pro implementing this system. I would
> also like to see the compiler evaluate any expressions in non-DBG builds.
> We could put it inside an "if (0)" so the compiler will optimize it away.
> A significant percentage of our build errors are due to these expressions
> not being evaluated in non-DBG mode.

[Ge van Geldorp]

My vote: yes, switch to the Wine Debug System.

Gé van Geldorp.

[James Tabor]

Alex Ionescu wrote:
> VOTING TOPIC: Switch to Wine Debug System, a run-time configurable Debug

(snip. ...)
>                              - Yes! Get rid of DPRINT/DPRINT1 and 
>
> implement a run-time configurable Debug System with multiple verbose 
> levels, based on WINE syntax and Windows NT implementation.

YES!
>                              - No! Stick with the current static, 
>
> compile-time DPRINT/DPRINT1 system.
>
> VOTING OPEN TO: Due to the nature of this source-level change, voting is 
> opened only to developers.
>
> Best regards,
> Alex Ionescu

[Hartmut Birr]

Please split the voting for kernel mode and user mode components.

KERNEL MODE:  NO

USER MODE: YES

- Hartmut

Alex Ionescu wrote:
> VOTING TOPIC: Switch to Wine Debug System, a run-time configurable
> Debug System in which various debug modes can be used (TRACE, WARN,
> FIXME, ERROR, etc). It would use DbgPrintEx along with Debug Filters
> (just like on XP) which can be configured at run-time in the registry
> to set how many of the messages to show. I believe the current WINE
> system has the library doing all this checking, but it's possible they
> do actually use the NT method. DbgPrintEx and filter states are
> currently unimplemented in our ntdll/ntoskrnl, so they must be
> implemented. Additionally, these Debug Messages would only be inserted
> into the code for a DBG build, just like it is currently done now.
> Finally, using this system will allow us to better share code with WINE.
>
> PROS:
>              - Configurable debugging
>              - More versatility then just "Print Always" and "Print if
> I remove NDEBUG"
>              - Better code sharing with WINE
>              - Will lead to the implementation of some DbgPrint
> functions which NT Drivers are bound to use.
>
> CONS:
>              - Requires developer time to switch to this system.
>              - Requires implementing some Kernel Functions.
>
> VOTING TIME: 2 weeks. Results announced Monday 23rd at 5PM EST.
>
> VOTING CHOICES:
>                                  - Yes! Get rid of DPRINT/DPRINT1 and
> implement a run-time configurable Debug System with multiple verbose
> levels, based on WINE syntax and Windows NT implementation.
>                                  - No! Stick with the current static,
> compile-time DPRINT/DPRINT1 system.
>
> VOTING OPEN TO: Due to the nature of this source-level change, voting
> is opened only to developers.
>
> Best regards,
> Alex Ionescu

[Alex Ionescu]

Hartmut Birr wrote:
> Please split the voting for kernel mode and user mode components.
>
> KERNEL MODE:  NO

Every Microsoft (and 3rd-party driver) for the last 4 years is using 
this debug mechanism. Why should we be backwards? I don't see a reason 
to split the vote..., but if anyone else has the same objection as 
Hartmut I will do so.

Best regards,
Alex Ionescu

[Hartmut Birr]

Alex Ionescu wrote:
> Hartmut Birr wrote:
> > Please split the voting for kernel mode and user mode components.
> >
> > KERNEL MODE:  NO
>
> Every Microsoft (and 3rd-party driver) for the last 4 years is using
> this debug mechanism. Why should we be backwards? I don't see a reason
> to split the vote..., but if anyone else has the same objection as
> Hartmut I will do so.

In the boot process, up to the point when a shell is running, you have
no chance to change any settings in the registry. This means you have to
reboot a second system, change some registry settings and reboot it
again. If the affected module doesn't have the necessary debug output,
you have also to change your sources. For me it is easier to change and
rebuild the code as to fiddle with some registry settings.

- Hartmut

[Aleksey Bragin]

My vote is certainly "Yes!", and I will try to help with this as much as
possible.
The only thing I don't know yet is to how to configure those filters before
OS boots -- I think Hartmut has similar question because he advised to split
KM and UM, and not use new system in KM.
However if new system will be equally good (in fact it should be much
better), than I'm sure everyone will be glad with it.

With the best regards,
Aleksey Bragin.

----- Original Message ----- 
From: "Alex Ionescu" [e-mail]
To: "ReactOS Development List" [e-mail]
Sent: Sunday, May 08, 2005 10:29 PM
Subject: [ros-dev] VOTE: Switch to Wine Debug System
> VOTING TOPIC: Switch to Wine Debug System, a run-time configurable Debug
> System in which various debug modes can be used (TRACE, WARN, FIXME,
> ERROR, etc). It would use DbgPrintEx along with Debug Filters (just like
> on XP) which can be configured at run-time in the registry to set how
> many of the messages to show. I believe the current WINE system has the
> library doing all this checking, but it's possible they do actually use
> the NT method. DbgPrintEx and filter states are currently unimplemented
> in our ntdll/ntoskrnl, so they must be implemented. Additionally, these
> Debug Messages would only be inserted into the code for a DBG build,
> just like it is currently done now. Finally, using this system will
> allow us to better share code with WINE.
>
> PROS:
>               - Configurable debugging
>               - More versatility then just "Print Always" and "Print if
> I remove NDEBUG"
>               - Better code sharing with WINE
>               - Will lead to the implementation of some DbgPrint
> functions which NT Drivers are bound to use.
>
> CONS:
>               - Requires developer time to switch to this system.
>               - Requires implementing some Kernel Functions.
>
> VOTING TIME: 2 weeks. Results announced Monday 23rd at 5PM EST.
>
> VOTING CHOICES:
>                                   - Yes! Get rid of DPRINT/DPRINT1 and
> implement a run-time configurable Debug System with multiple verbose
> levels, based on WINE syntax and Windows NT implementation.
>                                   - No! Stick with the current static,
> compile-time DPRINT/DPRINT1 system.
>
> VOTING OPEN TO: Due to the nature of this source-level change, voting is
> opened only to developers.
>
> Best regards,
> Alex Ionescu
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[Alex Ionescu]

Aleksey Bragin wrote:
> My vote is certainly "Yes!", and I will try to help with this as much as
> possible.
> The only thing I don't know yet is to how to configure those filters before
> OS boots --

They are read from registry. So Freeldr can read the NTOSKRNL one and 
pass them to ntoskrnl through the LPB...
> I think Hartmut has similar question because he advised to split
> KM and UM, and not use new system in KM.
> However if new system will be equally good (in fact it should be much
> better), than I'm sure everyone will be glad with it.

Drivers load after the registry is setup anyways, so they'd have access 
to the proper filters.
> With the best regards,
> Aleksey Bragin.

Best regards,
Alex Ionescu

[Alex Ionescu]

Attention all ROS Developers who have not yet voted. There are 3 days 
remaining for this vote.

Best regards,
Alex Ionescu
> ----- Original Message ----- 
> From: "Alex Ionescu" [e-mail]
> To: "ReactOS Development List" [e-mail]
> Sent: Sunday, May 08, 2005 10:29 PM
> Subject: [ros-dev] VOTE: Switch to Wine Debug System
> > VOTING TOPIC: Switch to Wine Debug System, a run-time configurable Debug
> > System in which various debug modes can be used (TRACE, WARN, FIXME,
> > ERROR, etc). It would use DbgPrintEx along with Debug Filters (just like
> > on XP) which can be configured at run-time in the registry to set how
> > many of the messages to show. I believe the current WINE system has the
> > library doing all this checking, but it's possible they do actually use
> > the NT method. DbgPrintEx and filter states are currently unimplemented
> > in our ntdll/ntoskrnl, so they must be implemented. Additionally, these
> > Debug Messages would only be inserted into the code for a DBG build,
> > just like it is currently done now. Finally, using this system will
> > allow us to better share code with WINE.
> >
> > PROS:
> >              - Configurable debugging
> >              - More versatility then just "Print Always" and "Print if
> > I remove NDEBUG"
> >              - Better code sharing with WINE
> >              - Will lead to the implementation of some DbgPrint
> > functions which NT Drivers are bound to use.
> >
> > CONS:
> >              - Requires developer time to switch to this system.
> >              - Requires implementing some Kernel Functions.
> >
> > VOTING TIME: 2 weeks. Results announced Monday 23rd at 5PM EST.
> >
> > VOTING CHOICES:
> >                                  - Yes! Get rid of DPRINT/DPRINT1 and
> > implement a run-time configurable Debug System with multiple verbose
> > levels, based on WINE syntax and Windows NT implementation.
> >                                  - No! Stick with the current static,
> > compile-time DPRINT/DPRINT1 system.
> >
> > VOTING OPEN TO: Due to the nature of this source-level change, voting is
> > opened only to developers.
> >
> > Best regards,
> > Alex Ionescu
> > _______________________________________________
> > Ros-dev mailing list
> > [e-mail]
> > http://reactos.com:8080/mailman/listinfo/ros-dev

[ea]

Alex Ionescu wrote:
> Attention all ROS Developers who have not yet voted. There are 3 days 
> remaining for this vote.

Alex, sorry for the late questions, but I really need some 
clarifications to vote.
Does switching to Wine debugging kill the NT compatible debugging (or is 
it a superset)?
Will Wine debugging introduce subtle side effects in the 
kernel/executive architecture that make drivers behave differently under 
NT than under ROS?

Emanuele Aliberti

[Alex Ionescu]

ea wrote:
> Alex Ionescu wrote:
> > Attention all ROS Developers who have not yet voted. There are 3 days 
> > remaining for this vote.
>
> Alex, sorry for the late questions, but I really need some 
> clarifications to vote.
> Does switching to Wine debugging kill the NT compatible debugging (or 
> is it a superset)?

No, on the contrary, it allows us to implement it (we currently don't).
> Will Wine debugging introduce subtle side effects in the 
> kernel/executive architecture that make drivers behave differently 
> under NT than under ROS?

No, on the contrary, it will allow us to implement debugging features 
that drivers under NT use but that they cannot use under ROS.
> Emanuele Aliberti

Best regards,
Alex Ionescu

[ea]

Thank you Alex for the clarifications.
> > Does switching to Wine debugging kill the NT compatible debugging (or 
> > is it a superset)?
>
> No, on the contrary, it allows us to implement it (we currently don't).

This leads to two more questions.

1. Are we talking about
a) a way to emit string messages;
b) the kernel mode debugger;
c) the DBGSS in the SM (a neutral debug message router, subsystem 
servers are debug message filters, debugger process, debuggee etc)?

2. There will be a way to strip completely debug messages from binaries 
(this is different than silencing all messages)?

Emanuele Aliberti

[Alex Ionescu]

ea wrote:
> Thank you Alex for the clarifications.
> > > Does switching to Wine debugging kill the NT compatible debugging 
> > > (or is it a superset)?
> >
> > No, on the contrary, it allows us to implement it (we currently don't).
>
> This leads to two more questions.
> Are we talking about
>
> a) a way to emit string messages;

Yes
> b) the kernel mode debugger;

No
> c) the DBGSS in the SM (a neutral debug message router, subsystem 
> servers are debug message filters, debugger process, debuggee etc)?

No. By the way, DBGSS is pretty much deprecated and when I eventually 
work on Debugging I'll use Native Debugging Objects.
> There will be a way to strip completely debug messages from
>
> binaries (this is different than silencing all messages)?

Defintely, the macros will expand to nothing on a release build.
> Emanuele Aliberti

Best regards,
Alex Ionescu

[ea]

OK, my vote is YES.

Thank you again for your answers.

Alex Ionescu wrote:
> c) the DBGSS in the SM (a neutral debug message router, subsystem 
> servers are debug message filters, debugger process, debuggee etc)?
>
> No. By the way, DBGSS is pretty much deprecated and when I eventually 
> work on Debugging I'll use Native Debugging Objects.

I didn't know. Can you direct me to some documentation about that? I saw 
DebugObject appeared in 5.1, but know little about it. Is it subsystem 
neutral?

http://www.metasploit.com/users/opcode/syscalls.html

Emanuele Aliberti

[Alex Ionescu]

ea wrote:
> I didn't know. Can you direct me to some documentation about that? I 
> saw DebugObject appeared in 5.1, but know little about it. Is it 
> subsystem neutral?

The only documentation are some of my notes in Notepad and the 
beginnings of our implementation (which I wrote) in ntoskrnl\dbgk...and 
the headers in ntoskrnl\include\internal\dbgk.h

Yes it's subsystem independent and doesn't touch LPCs.
> http://www.metasploit.com/users/opcode/syscalls.html

^^ Great site I know...did Viz tell you about it? =)
> Emanuele Aliberti

Best regards,
Alex Ionescu

[Royce Mitchell III]

VOTE: Yes, switch to WINE Debug System

My vote yes

Quoting Royce Mitchell III [e-mail]:
> VOTE: Yes, switch to WINE Debug System
>
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[Eric Kohl]

My vote is NO!

I'd like to keep the current debugging message system for the following 
reasons:
1) Establishing a channel-based debug message system will flood the 
developers with messages they don't need.

2) I cannot enable a message in a single place without hacks, like 
turning a TRACE into a FIXME. Alternative: introduce TRACE1, FIXME1, 
etc. which are always enabled. But this looks like the current system.

3) I don't like to make changes to the registry in order to change the 
debug channel settings. How will I debug the boot process from a CD or 
floppy disk?

Regards,
Eric

[ea]

Hi Eric!
> My vote is NO!
>
> I'd like to keep the current debugging message system for the 
> following reasons:
> Establishing a channel-based debug message system will flood the
>
> developers with messages they don't need.
> I cannot enable a message in a single place without hacks, like
>
> turning a TRACE into a FIXME. Alternative: introduce TRACE1, FIXME1, 
> etc. which are always enabled. But this looks like the current system.
> I don't like to make changes to the registry in order to change the
>
> debug channel settings. How will I debug the boot process from a CD or 
> floppy disk?

Would a compromise make you happy? I mean, current debugging does not 
change and we add a channel based debugging to support Wine's. We could 
write a pipe- or LPC-based debug message collector.

Emanuele

[Eric Kohl]

ea wrote:
> Would a compromise make you happy? I mean, current debugging does not 
> change and we add a channel based debugging to support Wine's. We could 
> write a pipe- or LPC-based debug message collector.

I can agree to the Wine Debug System if new macros TRACE1, WARN1, ERR1 
and FIXME1 could be added that are always enabled, just like DPRINT1. 
This way I can still adjust the debug messages the way I need while 
keeping the configurability of the Wine Debug System.

Regards,
Eric

[Ge van Geldorp]

> From: Eric Kohl
>
> I can agree to the Wine Debug System if new macros TRACE1, 
> WARN1, ERR1 and FIXME1 could be added that are always 
> enabled, just like DPRINT1. 
> This way I can still adjust the debug messages the way I need 
> while keeping the configurability of the Wine Debug System.

I'm not sure I understand this. I would expect ERR and FIXME to be printed
by default, TRACE and WARN would not be printed by default. So instead of
DPRINT you'd use TRACE and instead of DPRINT1 you'd use ERR. What do we need
ERR1 et al for???

Gé van Geldorp.

[Eric Kohl]

Ge van Geldorp wrote:
> I'm not sure I understand this. I would expect ERR and FIXME to be printed
> by default, TRACE and WARN would not be printed by default. So instead of
> DPRINT you'd use TRACE and instead of DPRINT1 you'd use ERR. What do we need
> ERR1 et al for???

Simply because I'll switch _all_ messages off by default. So only 
TRACE1, WARN1, ERR1 and FIXME1 will be printed.

And it is easier to change a WARN1 to a WARN instead of having to 
remeber the original macros when you restore the macros before commit.

Regards,
Eric

[Alex Ionescu]

Hi Eric,

I'm taking some time to respond to your issues:

Eric Kohl wrote:
> My vote is NO!
>
> I'd like to keep the current debugging message system for the 
> following reasons:
> Establishing a channel-based debug message system will flood the
>
> developers with messages they don't need.

I don't understand? On the contrary, it allows you to choose what you 
want to see or not. Right now DPRINT1 enables messages for everyone who 
is using ROS. With runtime selection, you choose what you need or not. 
Can you please clarify on what you meant?
> I cannot enable a message in a single place without hacks, like
>
> turning a TRACE into a FIXME. Alternative: introduce TRACE1, FIXME1, 
> etc. which are always enabled. But this looks like the current system.

Sure you can, the NT Debug APIs allow you to send a universal, non 
disablable debug message (or a raw DbgPrint). This is not an issue.
And if you're worrying about having to take the time to replace a 
"FIXME" into a "TRACE" (lazy! :P), well, nothing says we can't use
DPRINT1, 2, 3, 4. DPRINT could be "Level 1 - Always Print", "Level 2 - 
Print if minimal debugging is enabled", "Level 3 - Print if general 
tracing level is enabled", "Level 4 - Print if super verbose tracing 
level is enabled".
> I don't like to make changes to the registry in order to change the
>
> debug channel settings. How will I debug the boot process from a CD or 
> floppy disk?

Now this is a good argument that you bring up...but it seems moot after 
some analysis. How can you use your computer at all if you can't make 
registry changes? I think we currently use a ram disk for the registry, 
so there's no problem in setting the channels just like you'd set any 
other registry setting.
> Regards,
> Eric

Best regards,
Alex Ionescu

hope I get the mail back from the mail-server...