Re: [ros-dev] [ros-diffs] [pschweitzer] 49662: [NTOSKRNL] [HAL] Disable INIT_FUNCTION to s

[Pierre Schweitzer]

Hi,

finally this commit won't be reverted (unless someone explicitly asks for it) as it
brings testman back and shows quite important bugs.
Feel free to find a nice bugfix instead.

WBR,
P. Schweitzer

[Ros Arm]

Hi,

Considering that:

- The code to throw out INIT sections isn't in trunk, so _nothing happens_ when a
function is made INIT or not.
- There were already many INIT functions in NTOSKRNL and the kernel worked fine
- 49463 only added INIT_FUNCTION to the HAL
- A later revision by Timo added INIT_FUNCTION to win32k, and that worked fine as well

Don't you think it's a bit, pardon my language, braindead, to revert INIT_FUNCTION
in NTOSKRNL, as your patch did? Wouldn't it make more sense to simply revert
INIT_FUNCTION *just* in the HAL, which is what 49463 added? Why remove it from NTOSKRNL,
where it always worked? Why _not_ remove it from Win32k, if you think INIT_FUNCTION is
what's wrong? Your "fix" makes absolutely no logical sense from _any_ point
of view (as usual).

On a more serious note, don't you think it's strange that merely placing code in a
section (which right now isn't dropped, or messed with, in any way), would cause
problems in the OS? Isn't it immediately obvious to you that this is a red herring or
that the compiler is broken? Especially since the revision only causes problems for _some_
people? For example, it works for me, and I even have a local change that _throw out_ init
code.

Please learn some basic rational logic methodologies, the scientific method, and software
engineering processes.

-r

>   Hi,
>  
>  finally this commit won't be reverted (unless someone explicitly asks for it) as it
> brings testman back and shows quite important bugs.
>  Feel free to find a nice bugfix instead.
>  
>  WBR,
>  P. Schweitzer
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Pierre Schweitzer]

Hi,

I know that r49463 only added INIT_FUNCTION to HAL, but I reverted both, just to be sure.
I can get back ntoskrnl as they don't seem to be concerned.

Now, on other remarks, considering that:
- This has never be presented as a fix (but as a test)
- Win32k INIT_FUNCTION is not defined for GCC (only for MSVC)
- Testbot is now stuck in ARM³ MM bugs
- You are away after breaking trunk (as usual)
- Said "_Some_ people" include our testbot and some of our devs
- Being mean won't fix anything

Only ntoskrnl will get its INIT_FUNCTIONS back.
If GCC is broken, then we should only use that feature on MSVC, as it's done with
win32k.
If you are unhappy with such measures, keep in mind that you have commit access also for
fixes.

Btw, www.itworksforme.com is a pretty bad reference.

Regards,
P. Schweitzer

>   Hi,
>  
>  Considering that:
>  
>  - The code to throw out INIT sections isn't in trunk, so _nothing happens_ when a
> function is made INIT or not.
>  - There were already many INIT functions in NTOSKRNL and the kernel worked fine
>  - 49463 only added INIT_FUNCTION to the HAL
>  - A later revision by Timo added INIT_FUNCTION to win32k, and that worked fine as well
>  
>  Don't you think it's a bit, pardon my language, braindead, to revert
> INIT_FUNCTION in NTOSKRNL, as your patch did? Wouldn't it make more sense to simply
> revert INIT_FUNCTION *just* in the HAL, which is what 49463 added? Why remove it from
> NTOSKRNL, where it always worked? Why _not_ remove it from Win32k, if you think
> INIT_FUNCTION is what's wrong? Your "fix" makes absolutely no logical sense
> from _any_ point of view (as usual).
>  
>  On a more serious note, don't you think it's strange that merely placing code in
> a section (which right now isn't dropped, or messed with, in any way), would cause
> problems in the OS? Isn't it immediately obvious to you that this is a red herring or
> that the compiler is broken? Especially since the revision only causes problems for _some_
> people? For example, it works for me, and I even have a local change that _throw out_ init
> code.
>  
>  Please learn some basic rational logic methodologies, the scientific method, and software
> engineering processes.
>  
>  -r
>  
>  
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Ros Arm]

Hi,

It appears your arguments are because you don't seem to understand what you have done
wrong.

Let me spell it out:

" I know that r49463 only added INIT_FUNCTION to HAL, but I reverted both, just to be
sure. I can get back ntoskrnl as they don't seem to be concerned."

ie:

"I know that my fix went beyond what was needed, but I did it anyway "just to be
sure"".

ie:

"I know that A is impossible, yet I check for A anyway" -> logical fallacy

Next:

"- This has never be presented as a fix (but as a test)"

Yet your email said "this will not be reverted". A test, by definition, should
be reverted. Again, logical failure.

Next:

>   - Win32k INIT_FUNCTION is not defined for GCC (only
> for MSVC) 
Strange, because Timo used objdump to let me know how big the .INIT section was. Maybe he
was lying, I don't have information, so I'll pass.

Next:

>   - Testbot is now stuck in ARM³ MM bugs 
I can't seem to access builds.reactos.org to check, but I think this argument really
nails it: you really don't get it (you don't get the scientific method).

You've just proven that the test samples are corrupted (ie: the compiler is broken),
and now you expect me to hunt for bugs (ie: you expect me to analyze test results on
samples that are now corrupted).

The answer is no, I will not fix "bugs" which might be due to a broken compiler.
Fix the compiler, than I'll spend time hunting bugs.

>   - You are away after breaking trunk (as usual) 
How am I away? I've been posting to this mailing list, haven't I? I've been
working on ARM porting, which, in case you don't know, is my job. I've posted
screenshots of FreeLDR booting up on a real ARM board (I don't think you understand
the complexity involved). I've almost got the keyboard working. The fringe benefits of
C changes and new memory management code, which don't seem to be appreciate, are just
bonuses out of the kindness of my heart, and they set back my port significantly. It was
booting to user-mode with the old memory manager, now much of the work had to be
restarted/refactored (obviously, it benefits the ARM port too, but I could've skipped
this and done it the easy way).

My last 20 commits or so have ALL been bug fixes, and I still have more in the pipeline.
I've fixed bugs that were more than 10 years old.

Don't ever question my commitment again.

>   - Said "_Some_ people" include our testbot
> and some of our devs 
That's _exactly the point_. You've obviously got a strange system/os/host/compiler
issue going on, which is why it works for some, but not for others. I wasn't saying
there isn't a problem, I was saying the problem is subtle and could be responsible for
other subtle "bugs" as well. You're ignoring this, and forging ahead (with
corrupted test samples). What is this, the movie Splice?

By your analysis, because GCC is broken, we should only use MSVC. I refuse to do so (and
MSVC has its share of bugs). This "feature" is called PE sections. So you are
saying GCC cannot/fails at generating PE sections. In other words, we can't use .data,
.rsrc, .idata, etc anymore. In other words, the compiler is 100% broken and cannot be
used. How do we know it's not failing because putting stuff in a different section
doesn't somehow corrupt the code? Well, that means that it's also possible for
code/data in .data, or in .idata to get corrupted in the exact same way. In other words,
the compiler is broken and WE CAN'T TRUST ANYTHING.

Finally "> - Being mean won't fix anything".

Don't be a child. I was being harsh on your premise, to, I quote "not revert the
commit", which implied that "well, the compiler is broken, but we'll just
ignore that and assume there's no other side effects". Being "mean" is
an entirely different emotion and outside the scope of the technical/professional
communication I'm attempting to have with you. I am trying to educate/teach you. Being
mean (and unprofessional) would've involved reverting your changes and calling you an
idiot (I never once attacked you personally -- I called your decision braindead, that is
different).

-r

> Hi,
> 
> I know that r49463 only added INIT_FUNCTION to HAL, but I reverted both, just to be
sure. I can get back ntoskrnl as they don't seem to be concerned.
> 
> Now, on other remarks, considering that:
> - This has never be presented as a fix (but as a test)
>   - Win32k INIT_FUNCTION is not defined for GCC (only
> for MSVC) 
>   - Testbot is now stuck in
> ARM³ MM bugs 
>   - You are away after
> breaking trunk (as usual) 
>   - Said "_Some_
> people" include our testbot and some of our devs 
> - Being mean won't
fix anything
> 
> Only ntoskrnl will get its INIT_FUNCTIONS back.
> If GCC is broken, then we should only use that feature on MSVC, as it's done with
win32k.
> If you are unhappy with such measures, keep in mind that you have commit access also
for fixes.
> 
> Btw, www.itworksforme.com is a pretty bad reference.
> 
> Regards,
> P. Schweitzer
> 
> > Hi,
> > 
> > Considering that:
> > 
> > - The code to throw out INIT sections isn't in trunk, so _nothing happens_
when a function is made INIT or not.
> > - There were already many INIT functions in NTOSKRNL and the kernel worked fine
> > - 49463 only added INIT_FUNCTION to the HAL
> > - A later revision by Timo added INIT_FUNCTION to win32k, and that worked fine
as well
> > 
> > Don't you think it's a bit, pardon my language, braindead, to revert
INIT_FUNCTION in NTOSKRNL, as your patch did? Wouldn't it make more sense to simply
revert INIT_FUNCTION *just* in the HAL, which is what 49463 added? Why remove it from
NTOSKRNL, where it always worked? Why _not_ remove it from Win32k, if you think
INIT_FUNCTION is what's wrong? Your "fix" makes absolutely no logical sense
from _any_ point of view (as usual).
> > 
> > On a more serious note, don't you think it's strange that merely placing
code in a section (which right now isn't dropped, or messed with, in any way), would
cause problems in the OS? Isn't it immediately obvious to you that this is a red
herring or that the compiler is broken? Especially since the revision only causes problems
for _some_ people? For example, it works for me, and I even have a local change that
_throw out_ init code.
> > 
> > Please learn some basic rational logic methodologies, the scientific method, and
software engineering processes.
> > 
> > -r
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev(a)reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> 
> 
> 
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

[Olaf Siejka]

Hi

Please try the correct address: http://build.reactos.org:8010/

2010/11/20 Ros Arm <ros.arm(a)reactos.org>

>   Hi,
>
>  I can't seem to access builds.reactos.org to check, but I think this
>  argument really nails it: you really don't get it (you don't get the
>  scientific method).
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Ros Arm]

Hi,

Oops! Google Chrome could not connect to build.reactos.org:8010

It was a typo in my e-mail. I've used this website fine in the past before.

-r

>   Hi
>  
>  Please try the correct address: http://build.reactos.org:8010/
>  
>  2010/11/20 Ros Arm <ros.arm(a)reactos.org>
>  
> >   Hi,
> >
> >  I can't seem to access builds.reactos.org to check, but I think this
> >  argument really nails it: you really don't get it (you don't get the
> >  scientific method).
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Olaf Siejka]

Hiya

Looks like i can confirm this issue. I`ll ask Chris to look into it. IE9
Beta is also having problems. For now you can use:
http://reactos.ath.cx:8081/waterfall
but only for  compilation issues. I still await for Aleksiej to finish up
vbox sysreg so we can duplicate winetest automation.

Regards

2010/11/20 Ros Arm <ros.arm(a)reactos.org>

>   Hi,
>
>  Oops! Google Chrome could not connect to build.reactos.org:8010
>
>  It was a typo in my e-mail. I've used this website fine in the past before.
>
>  -r
>

[Pierre Schweitzer]

Who the hell do you think you are?! The day I'll need lesson, don't worry I know
who you are and where to find you.
I won't waste my time answering. Understand whatever you want, imagine whatever you
want.
Just for your information:
http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in…
And be sure I'll question your commitment whenever it's needed.
"Discussion" is over for me.

>   Hi,
>  
>  It appears your arguments are because you don't seem to understand what you have done
> wrong.
>  
>  Let me spell it out:
>  
>  " I know that r49463 only added INIT_FUNCTION to HAL, but I reverted both, just to
> be sure. I can get back ntoskrnl as they don't seem to be concerned."
>  
>  ie:
>  
>  "I know that my fix went beyond what was needed, but I did it anyway "just to
> be sure"".
>  
>  ie:
>  
>  "I know that A is impossible, yet I check for A anyway" -> logical fallacy
>  
>  Next:
>  
>  "- This has never be presented as a fix (but as a test)"
>  
>  Yet your email said "this will not be reverted". A test, by definition, should
> be reverted. Again, logical failure.
>  
>  Next:
>  
> >   - Win32k INIT_FUNCTION is not defined for GCC
> > (only for MSVC) 
>  
>  Strange, because Timo used objdump to let me know how big the .INIT section was. Maybe he
> was lying, I don't have information, so I'll pass.
>  
>  Next:
>  
> >   - Testbot is now stuck in ARM³ MM bugs 
>  
>  I can't seem to access builds.reactos.org to check, but I think this argument really
> nails it: you really don't get it (you don't get the scientific method).
>  
>  You've just proven that the test samples are corrupted (ie: the compiler is broken),
> and now you expect me to hunt for bugs (ie: you expect me to analyze test results on
> samples that are now corrupted).
>  
>  The answer is no, I will not fix "bugs" which might be due to a broken
> compiler. Fix the compiler, than I'll spend time hunting bugs.
>  
> >   - You are away after breaking trunk (as usual)
>  
>  How am I away? I've been posting to this mailing list, haven't I? I've been
> working on ARM porting, which, in case you don't know, is my job. I've posted
> screenshots of FreeLDR booting up on a real ARM board (I don't think you understand
> the complexity involved). I've almost got the keyboard working. The fringe benefits of
> C changes and new memory management code, which don't seem to be appreciate, are just
> bonuses out of the kindness of my heart, and they set back my port significantly. It was
> booting to user-mode with the old memory manager, now much of the work had to be
> restarted/refactored (obviously, it benefits the ARM port too, but I could've skipped
> this and done it the easy way).
>  
>  My last 20 commits or so have ALL been bug fixes, and I still have more in the pipeline.
> I've fixed bugs that were more than 10 years old.
>  
>  Don't ever question my commitment again.
>  
> >   - Said "_Some_ people" include our
> > testbot and some of our devs 
>  
>  That's _exactly the point_. You've obviously got a strange
> system/os/host/compiler issue going on, which is why it works for some, but not for
> others. I wasn't saying there isn't a problem, I was saying the problem is subtle
> and could be responsible for other subtle "bugs" as well. You're ignoring
> this, and forging ahead (with corrupted test samples). What is this, the movie Splice?
>  
>  By your analysis, because GCC is broken, we should only use MSVC. I refuse to do so (and
> MSVC has its share of bugs). This "feature" is called PE sections. So you are
> saying GCC cannot/fails at generating PE sections. In other words, we can't use .data,
> .rsrc, .idata, etc anymore. In other words, the compiler is 100% broken and cannot be
> used. How do we know it's not failing because putting stuff in a different section
> doesn't somehow corrupt the code? Well, that means that it's also possible for
> code/data in .data, or in .idata to get corrupted in the exact same way. In other words,
> the compiler is broken and WE CAN'T TRUST ANYTHING.
>  
>  Finally "> - Being mean won't fix anything".
>  
>  Don't be a child. I was being harsh on your premise, to, I quote "not revert the
> commit", which implied that "well, the compiler is broken, but we'll just
> ignore that and assume there's no other side effects". Being "mean" is
> an entirely different emotion and outside the scope of the technical/professional
> communication I'm attempting to have with you. I am trying to educate/teach you. Being
> mean (and unprofessional) would've involved reverting your changes and calling you an
> idiot (I never once attacked you personally -- I called your decision braindead, that is
> different).
>  
>  -r
>  
>  
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Pierre Schweitzer]

I even misread the header. I could have reverted win32k as well.
Luckily!

>   Who the hell do you think you are?! The day I'll
> need lesson, don't worry I know who you are and where to find you.
>  I won't waste my time answering. Understand whatever you want, imagine whatever you
> want.
>  Just for your information:
> http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in…
>  And be sure I'll question your commitment whenever it's needed.
>  "Discussion" is over for me.
>  
> >   Hi,
> >  
> >  It appears your arguments are because you don't seem to understand what you have done
> > wrong.
> >  
> >  Let me spell it out:
> >  
> >  " I know that r49463 only added INIT_FUNCTION to HAL, but I reverted both, just to
> > be sure. I can get back ntoskrnl as they don't seem to be concerned."
> >  
> >  ie:
> >  
> >  "I know that my fix went beyond what was needed, but I did it anyway "just to
> > be sure"".
> >  
> >  ie:
> >  
> >  "I know that A is impossible, yet I check for A anyway" -> logical fallacy
> >  
> >  Next:
> >  
> >  "- This has never be presented as a fix (but as a test)"
> >  
> >  Yet your email said "this will not be reverted". A test, by definition, should
> > be reverted. Again, logical failure.
> >  
> >  Next:
> >  
> > >   - Win32k INIT_FUNCTION is not defined for GCC
> > > (only for MSVC) 
> >  
> >  Strange, because Timo used objdump to let me know how big the .INIT section was. Maybe he
> > was lying, I don't have information, so I'll pass.
> >  
> >  Next:
> >  
> > >   - Testbot is now stuck in ARM³ MM bugs 
> >  
> >  I can't seem to access builds.reactos.org to check, but I think this argument really
> > nails it: you really don't get it (you don't get the scientific method).
> >  
> >  You've just proven that the test samples are corrupted (ie: the compiler is broken),
> > and now you expect me to hunt for bugs (ie: you expect me to analyze test results on
> > samples that are now corrupted).
> >  
> >  The answer is no, I will not fix "bugs" which might be due to a broken
> > compiler. Fix the compiler, than I'll spend time hunting bugs.
> >  
> > >   - You are away after breaking trunk (as usual)
> >  
> >  How am I away? I've been posting to this mailing list, haven't I? I've been
> > working on ARM porting, which, in case you don't know, is my job. I've posted
> > screenshots of FreeLDR booting up on a real ARM board (I don't think you understand
> > the complexity involved). I've almost got the keyboard working. The fringe benefits of
> > C changes and new memory management code, which don't seem to be appreciate, are just
> > bonuses out of the kindness of my heart, and they set back my port significantly. It was
> > booting to user-mode with the old memory manager, now much of the work had to be
> > restarted/refactored (obviously, it benefits the ARM port too, but I could've skipped
> > this and done it the easy way).
> >  
> >  My last 20 commits or so have ALL been bug fixes, and I still have more in the pipeline.
> > I've fixed bugs that were more than 10 years old.
> >  
> >  Don't ever question my commitment again.
> >  
> > >   - Said "_Some_ people" include our
> > > testbot and some of our devs 
> >  
> >  That's _exactly the point_. You've obviously got a strange
> > system/os/host/compiler issue going on, which is why it works for some, but not for
> > others. I wasn't saying there isn't a problem, I was saying the problem is subtle
> > and could be responsible for other subtle "bugs" as well. You're ignoring
> > this, and forging ahead (with corrupted test samples). What is this, the movie Splice?
> >  
> >  By your analysis, because GCC is broken, we should only use MSVC. I refuse to do so (and
> > MSVC has its share of bugs). This "feature" is called PE sections. So you are
> > saying GCC cannot/fails at generating PE sections. In other words, we can't use .data,
> > .rsrc, .idata, etc anymore. In other words, the compiler is 100% broken and cannot be
> > used. How do we know it's not failing because putting stuff in a different section
> > doesn't somehow corrupt the code? Well, that means that it's also possible for
> > code/data in .data, or in .idata to get corrupted in the exact same way. In other words,
> > the compiler is broken and WE CAN'T TRUST ANYTHING.
> >  
> >  Finally "> - Being mean won't fix anything".
> >  
> >  Don't be a child. I was being harsh on your premise, to, I quote "not revert the
> > commit", which implied that "well, the compiler is broken, but we'll just
> > ignore that and assume there's no other side effects". Being "mean" is
> > an entirely different emotion and outside the scope of the technical/professional
> > communication I'm attempting to have with you. I am trying to educate/teach you. Being
> > mean (and unprofessional) would've involved reverting your changes and calling you an
> > idiot (I never once attacked you personally -- I called your decision braindead, that is
> > different).
> >  
> >  -r
> >  
> >  
> >  
> >  
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>  
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

Am 20.11.2010 18:13, Ros Arm wrote:
>   Hi,
>
>  It appears your arguments are because you don't seem to understand what you have done
> wrong. 
Let me add my portion here as well.

Despite the fact that the scientific method doesn't seem to apply to
reactos coding (if you have evaluated all possibilities and all of them
are impossible except one that is unlikely, then ... one of the
impossible possibilities is responsible), you would need to take
everything into account. One of these things to be taken into account is
human failability, and yes, even your own failability ;-) Even the
possibility that you didn't take everything into account. Well that
makes the task quite impossible to solve.

Another thing you have to take into account is that we have a tool
called pefixup, which messes with INIT sections. I don't know if you
were aware of that, but before blaming the compiler, I would look at
that tool.

Also following your argumentation, that it can only be a compiler bug,
as the kernel doesn't do anything with INIT sections yet, this bug would
obviously affect other modules as well, even if we didn't notice it (you
called it a subtle bug) and we might end up with having it being
triggered on the kernel by some completely unrelated commit, making it
almost impossible to find out what happened. So not reverting the kernel
(and win32k) would be ignoring this fact.

I remember spending hours, trying to find out, why merging the header
branch back to trunk caused a testbot failure. It turned out that adding
some function prototypes to ddk headers triggered the bug. It was
completely unrelated to the content, simply adding more stuff into a
header broke boot. Impossible? Still it's a fact. It's always better to
not make quick assumptions about what is possible and what not.

If you asked me, whether I would prefer reverting this commit or having
testbot being broken for even longer, I would go for reverting. Always.
Instantly. No matter who, what and where. And I'm certain that quite a
number of developers and testers would agree. Reverting something that
doesn't work, doesn't mean ignoring the problem, it only means that
developers and testers are tired of having to deal with broken shit on a
daily basis.

You seemed to have been aware that something broke for some people.
Still you switched to completely unrelated things and had other people
deal with it. I don't complain about that, but either fix it yourself,
or live with other people's "fixes".

I don't care for anyone's epeen. But I care for having a working
testbot. Pierre succeeded in bringing it back, you failed.

Finally: instead of ranting, you might as well have politely asked to
bring back the kernel's INIT_FUNCTION. Telling somebody that his
"decision is breaindead" and that he doesn't "get the scientific
method"
doesn't help anyone except maybe your ego.

I just want to teach you :-p

Regards,
Timo