Re: [ros-dev] [ros-diffs] [pschweitzer] 49662: [NTOSKRNL] [HAL] Disable INIT_FUNCTION to s
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
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi
Please try the correct address: http://build.reactos.org:8010/
2010/11/20 Ros Arm ros.arm@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@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
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/inc... 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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/inc... 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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
-
Olaf Siejka -
Pierre Schweitzer -
Ros Arm -
Timo Kreuzer