Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 44841: NMI Support Patch 1: [HAL]: The I/O Permissions Map on a typical Privileged Mode x86 OS is all 0xFF's, so it's quite wasteful to copy-in/out the entire map each single BIOS Call. As an optimization, only save and restore non-0xFF entries. [NTOS]: Define and use constants for different IOPM values, instead of using hardcoded values.

[Alex Ionescu]

"You may relicense my code as BSD" != "You make strip away
copyright/ownership of my code".

Revert this.

On 2009-12-31, at 6:51 PM, ros-arm-bringup(a)svn.reactos.org wrote:

>   
>  - * PROGRAMMERS:     Alex Ionescu (alex.ionescu(a)reactos.org)
>  + * PROGRAMMERS:     ReactOS Portable Systems Group 
Best regards,
Alex Ionescu

[Ros Arm]

The "ownership" and "copyright" of this code is not belonging to
either you or anyone else but the original source it came from.

The PROGRAMMERS field indicates who is responsible for a piece of code in this project, is
it not? In this case, since you have quitted many years ago, it makes sense this code is
now belong to us.

It is Linux concept of "maintainer".

Thanks you,
[eVb]

>   "You may relicense my code as BSD" !=
> "You make strip away copyright/ownership of my code".
>  
>  Revert this.
>  
>  On 2009-12-31, at 6:51 PM, ros-arm-bringup(a)svn.reactos.org wrote:
>  
> >   
> >  - * PROGRAMMERS:     Alex Ionescu (alex.ionescu(a)reactos.org)
> >  + * PROGRAMMERS:     ReactOS Portable Systems Group 
>  
>  Best regards,
>  Alex Ionescu
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Dmitry Gorbachev]

What is the Original Source of it?

[James Tabor]

Hello!
I do admire the assimilation concept very much, with great respect, in
this mater you're both (or group) wrong.

No, this is not " Linux concept of "maintainer" ", we add our names
to
a list of programmers not just one. So please reapply Alex's name as
Alpha programmer with your groups name in the next patch spin cycle.
Fix it in the mix!

Thank you,
James

On Tue, Jan 5, 2010 at 6:41 PM, Ros Arm <ros.arm(a)reactos.org> wrote:
>   The "ownership" and "copyright" of
> this code is not belonging to either you or anyone else but the original source it came
> from.
>
>  The PROGRAMMERS field indicates who is responsible for a piece of code in this project,
> is it not? In this case, since you have quitted many years ago, it makes sense this code
> is now belong to us.
>
>  It is Linux concept of "maintainer".
>
>  Thanks you,
>  [eVb]
>
> > "You may relicense my code as BSD" != "You make strip away
> copyright/ownership of my code".
> >
> > Revert this.
> >
> > On 2009-12-31, at 6:51 PM, ros-arm-bringup(a)svn.reactos.org wrote:
> >
> > >
> > > - * PROGRAMMERS:     Alex Ionescu (alex.ionescu(a)reactos.org)
> > > + * PROGRAMMERS:     ReactOS Portable Systems Group
> >
> > Best regards,
> > Alex Ionescu
> >

[Matthieu Suiche]

"but the original source it came from."

Damn, yes. What do you mean ??
--
Matthieu Suiche



On Wed, Jan 6, 2010 at 4:35 AM, James Tabor <jimtabor.rosdev(a)gmail.com> wrote:
>   Hello!
>  I do admire the assimilation concept very much, with great respect, in
>  this mater you're both (or group) wrong.
>
>  No, this is not " Linux concept of "maintainer" ", we add our names
> to
>  a list of programmers not just one. So please reapply Alex's name as
>  Alpha programmer with your groups name in the next patch spin cycle.
>  Fix it in the mix!
>
>  Thank you,
>  James
>
>  On Tue, Jan 5, 2010 at 6:41 PM, Ros Arm <ros.arm(a)reactos.org> wrote:
> >   The "ownership" and
> > "copyright" of this code is not belonging to either you or anyone else but the
> > original source it came from.
> >
> >  The PROGRAMMERS field indicates who is responsible for a piece of code in this project,
> > is it not? In this case, since you have quitted many years ago, it makes sense this code
> > is now belong to us.
> >
> >  It is Linux concept of "maintainer".
> >
> >  Thanks you,
> >  [eVb]
> >
> > > "You may relicense my code as BSD" != "You make strip away
> > copyright/ownership of my code".
> > >
> > > Revert this.
> > >
> > > On 2009-12-31, at 6:51 PM, ros-arm-bringup(a)svn.reactos.org wrote:
> > >
> > > >
> > > > - * PROGRAMMERS:     Alex Ionescu (alex.ionescu(a)reactos.org)
> > > > + * PROGRAMMERS:     ReactOS Portable Systems Group
> > >
> > > Best regards,
> > > Alex Ionescu
> > > 
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Eric Kohl]

Ros Arm wrote:
>   The "ownership" and "copyright" of
> this code is not belonging to either you or anyone else but the original source it came
> from.
>  
>  The PROGRAMMERS field indicates who is responsible for a piece of code in this project,
> is it not? In this case, since you have quitted many years ago, it makes sense this code
> is now belong to us.
>  
>  It is Linux concept of "maintainer".
>  
>  Thanks you,
>  [eVb]
>   
Hi Ros Arm,

you are totally wrong here. The PROGRAMMERS field could be called 
AUTHORS or CONTRIBUTORS and lists those who claim copyright or 
authorship to a file. So removing someone from the PROGRAMMERS field is 
a very disrespectul act, is a copyright violation and must be reverted 
as soon as possible.

You can claim sole authorship to a file if you created the initial 
version of a file.

You can also claim authorship to a file if you modified it in a 
significant way. In this case you can ADD your name to the END of the 
list of programmers. So the author who wrote the first version should 
always stay on top of the list. Changing a "+" to "-" or adding
"+ 1" is 
not enough to claim authorship.

And in no case you have the right to change the license of an existing 
file without having prior permission to do so by ALL authors of that 
file. As far as I can remember, I did NOT grant permission to relicense 
my code under the BSD license. My contributions to ReactOS were, are and 
will be published under GPL or LGPL only.

Therefore I ask you to revert the following patch:
[ros-diffs] [ros-arm-bringup] 44860: NMI Support Patch 6: [HAL]: Fix NMI 
recursion issues. [HAL]: Reset the display during NMI and paint the NMI 
Screen of Death.

In case you fail to revert the patch within a week (aka 7 days) I will 
revert this patch myself and restore the previous version.

And by the way, DON'T INTRODUCE YET ANOTHER FUCKIING CODING STYLE!!!! 
Use the coding styles that are already being used!!!!

Oh, and before I'm done: I don't like to talk to meaningless nicks like 
Ros Arm, RosLeg or ROSIDONTKNOWHOWTOFUKINGCALLMYSELF. Reveal your 
identity! I don't see a reason why you have to hide behind you nick. If 
you need to hide your identity you should better leave ReactOS because 
these reasons can only endanger the project. And I will always prefer to 
throw a single contributor out of the team rather than endangering the 
whole project.

And finally, my name is Eric Kohl and I joined the ReactOS project in 
December 1998. So I guess I have the right to voice my opinion here.


Regards
Eric

[Aleksey Bragin]

On Jan 6, 2010, at 11:14 PM, Eric Kohl wrote:
>   And by the way, DON'T INTRODUCE YET ANOTHER
> FUCKIING CODING STYLE!!!!
>  Use the coding styles that are already being used!!!! 
I'd like to support this
opinion. I very much dislike
//
// Three long lined MS likes so much to use
//
comments.

/* This nice style seems to be widely used throughout the kernel */
And it's supported by our former lead kernel dev Alex Ionescu. I  
always prefer to stick to that style when working in the kernel.


WBR,
Aleksey Bragin

[Ged Murphy]

On Wed, Jan 6, 2010 at 8:14 PM, Eric Kohl <eric.kohl(a)t-online.de> wrote:

>  
>  Oh, and before I'm done: I don't like to talk to meaningless nicks like
>  Ros Arm, RosLeg or ROSIDONTKNOWHOWTOFUKINGCALLMYSELF. Reveal your
>  identity! I don't see a reason why you have to hide behind you nick.
>  

You aren't the only person pissed off with this one man decision.

I can understand the reason to want to keep your real identity a secret
(e.g. kjk, Vizzini) but to make yourself totally secret where only the the
project coordinator is allowed to know who you are is very worrying and is
not the ReactOS I originally joined.

Ged.

[Ros Arm]

Hi Eric,

We apologize for the misunderstanding. The relationship of that field was confusing, since
some files have authors that don't correlate to SVN history at all.

In relation to what eVb was saying, I have looked up the entire SVN history of the misc.c
file, which originally started out in NTOS.

Your one and only actual contribution is here:

http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/hal/x86/misc.c?re…

Revision 1026, almost 10 years ago.

In that revision, you created the file and "implemented" HalHandleNMI.

It is interesting that your implementation of HalHandleNMI happens to print out the exact
same messages that the NT4 HAL dumps on the screen.

To obtain the same messages "clean-room", you must've been able to generate
all the possible NMI traps on your machine, which is unlikely.

Also, the choices of "0x40", "0x20" and "0x61" appear to be
magic constants, instead of properly documented constants referring to the NMI status port
and the NMI status bits.

Additionally, the same "KeEnterKernelDebugger" call is present both in the NT4
HAL and your implementation of this function, even though, as of revision 1993:

http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kd/kdebug.c?revis…

That function only printed a string -- so there appears to have been little reason to make
this API call other than to duplicate the original NT HAL's behavior.

Furthermore, why even implement this function at all back in 2000? There was no NMI task
gate back then, no NMI handler, and no caller of HalHandleNMI -- therefore, this function
was impossible to test in ReactOS. It seems to have been implemented just for the sake of
implementing "an easy function", without any actual real use.

Whether this function, in 2000, was by coincidence an exact replica of the NT4 HAL
HalHandleNMI, and you happened to have experienced all possible NMI traps and their
messages on the screen, and you decided not to document the port and status bit values, or
whether it was reverse engineered does not change the fact that the code was 100%
identical. Therefore, I believe this was eVB's point that the true
"copyright" of this function belonged to nobody else but Microsoft, and so the
PROGRAMMERS field seemed logical to include the maintainer, not the "copyright"
owner.

So before lambasting about copyright ownership and licenses, perhaps you should be more
careful.

It is an entirely different argument whether or not there is any other way to do this  --
clearly, by now, it is known what NMI messages the Windows STOP screen will display, and
ReactOS must display the same NMI messages. Since both Windows NT and ReactOS use the same
routine for printing to the screen, it also makes sense that they'd both be using the
same HalDisplayString API. One could argue that since you'd probably want to debug the
NMI, it might make sense to enter the kernel debugger, which, since it is an exported
kernel function that ReactOS must implement, ends up being the same call as Windows. So
whether it was clean roomed, copied, reverse engineered, or fabricated out of thin air to
match this specification, the resulting code would look the same (however, it should be
better documented so the values don't look like magic). Of course these are all
rational arguments that can be made *after* the function has been written, the burden of
proof as to IF this is how the function was already written is what matters.

There are many questions as to whether or not those 6 lines of code are actually
copyrighted at all, whether you or anyone else has any rights to those 6 lines of code
since they are identical to Windows (by necessity), and whether or not the addition of
~460 additional lines to misc.c and improvement of the original function still enable you
to refuse a GPL->BSD license change solely based on 6, 10-year-old, lines of code that
are identical to an even older copyrighted source base.

To push this analogy further, I could decide that the following piece of code

"printf("%s\n","

is GPL, and block anyone from ever using it in a module that is BSD.

I think even GPL requires at least 10 lines of code before being able to claim the whole
module is GPLed (and it's probably more complicated than that).

So to close the topic: it is unclear if you have any ownership of those original 6 lines
of code, and it is even further unclear if 6 lines of interface code in a 466 line module
allow you the right to dictate the license of the module.

-r

>   Ros Arm wrote:
> >   The "ownership" and
> > "copyright" of this code is not belonging to either you or anyone else but the
> > original source it came from.
> >  
> >  The PROGRAMMERS field indicates who is responsible for a piece of code in this project,
> > is it not? In this case, since you have quitted many years ago, it makes sense this code
> > is now belong to us.
> >  
> >  It is Linux concept of "maintainer".
> >  
> >  Thanks you,
> >  [eVb]
> >   
>  
>  Hi Ros Arm,
>  
>  you are totally wrong here. The PROGRAMMERS field could be called 
>  AUTHORS or CONTRIBUTORS and lists those who claim copyright or 
>  authorship to a file. So removing someone from the PROGRAMMERS field is 
>  a very disrespectul act, is a copyright violation and must be reverted 
>  as soon as possible.
>  
>  You can claim sole authorship to a file if you created the initial 
>  version of a file.
>  
>  You can also claim authorship to a file if you modified it in a 
>  significant way. In this case you can ADD your name to the END of the 
>  list of programmers. So the author who wrote the first version should 
>  always stay on top of the list. Changing a "+" to "-" or adding
> "+ 1" is 
>  not enough to claim authorship.
>  
>  And in no case you have the right to change the license of an existing 
>  file without having prior permission to do so by ALL authors of that 
>  file. As far as I can remember, I did NOT grant permission to relicense 
>  my code under the BSD license. My contributions to ReactOS were, are and 
>  will be published under GPL or LGPL only.
>  
>  Therefore I ask you to revert the following patch:
>  [ros-diffs] [ros-arm-bringup] 44860: NMI Support Patch 6: [HAL]: Fix NMI 
>  recursion issues. [HAL]: Reset the display during NMI and paint the NMI 
>  Screen of Death.
>  
>  In case you fail to revert the patch within a week (aka 7 days) I will 
>  revert this patch myself and restore the previous version.
>  
>  And by the way, DON'T INTRODUCE YET ANOTHER FUCKIING CODING STYLE!!!! 
>  Use the coding styles that are already being used!!!!
>  
>  Oh, and before I'm done: I don't like to talk to meaningless nicks like 
>  Ros Arm, RosLeg or ROSIDONTKNOWHOWTOFUKINGCALLMYSELF. Reveal your 
>  identity! I don't see a reason why you have to hide behind you nick. If 
>  you need to hide your identity you should better leave ReactOS because 
>  these reasons can only endanger the project. And I will always prefer to 
>  throw a single contributor out of the team rather than endangering the 
>  whole project.
>  
>  And finally, my name is Eric Kohl and I joined the ReactOS project in 
>  December 1998. So I guess I have the right to voice my opinion here.
>  
>  
>  Regards
>  Eric
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

The output on the screen is well known and documented. And was at that
time, too, as it could be seen pretty often. There's nothing secret. and
there's only 2 cases that need to be considered by analyzing the NMI
status register, which is also well known and documented. There are
magic numbers, because documentation usually contains those magic
numbers. It's 2 damned flags.
Also the initial version contained more than 6 lines of code. And your
"460" lines of code were actually like 13 lines of code for HalFlushTlb
and additional 8 lines of code for HalHandleNMI. The rest is
reformatting and excessive commenting. And you still want to claim the
sole authorship to this file? Is that maybe the reason for 3 line
comments? To make up more lines of "code" to claim authorship?

Ros Arm schrieb:
>   Hi Eric,
>
>  We apologize for the misunderstanding. The relationship of that field was confusing,
> since some files have authors that don't correlate to SVN history at all.
>
>  In relation to what eVb was saying, I have looked up the entire SVN history of the misc.c
> file, which originally started out in NTOS.
>
>  Your one and only actual contribution is here:
>
>
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/hal/x86/misc.c?re…
>
>  Revision 1026, almost 10 years ago.
>
>  In that revision, you created the file and "implemented" HalHandleNMI.
>
>  It is interesting that your implementation of HalHandleNMI happens to print out the exact
> same messages that the NT4 HAL dumps on the screen.
>
>  To obtain the same messages "clean-room", you must've been able to generate
> all the possible NMI traps on your machine, which is unlikely.
>
>  Also, the choices of "0x40", "0x20" and "0x61" appear to be
> magic constants, instead of properly documented constants referring to the NMI status port
> and the NMI status bits.
>
>  Additionally, the same "KeEnterKernelDebugger" call is present both in the NT4
> HAL and your implementation of this function, even though, as of revision 1993:
>
>
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kd/kdebug.c?revis…
>
>  That function only printed a string -- so there appears to have been little reason to
> make this API call other than to duplicate the original NT HAL's behavior.
>
>  Furthermore, why even implement this function at all back in 2000? There was no NMI task
> gate back then, no NMI handler, and no caller of HalHandleNMI -- therefore, this function
> was impossible to test in ReactOS. It seems to have been implemented just for the sake of
> implementing "an easy function", without any actual real use.
>
>  Whether this function, in 2000, was by coincidence an exact replica of the NT4 HAL
> HalHandleNMI, and you happened to have experienced all possible NMI traps and their
> messages on the screen, and you decided not to document the port and status bit values, or
> whether it was reverse engineered does not change the fact that the code was 100%
> identical. Therefore, I believe this was eVB's point that the true
> "copyright" of this function belonged to nobody else but Microsoft, and so the
> PROGRAMMERS field seemed logical to include the maintainer, not the "copyright"
> owner.
>
>  So before lambasting about copyright ownership and licenses, perhaps you should be more
> careful.
>
>  It is an entirely different argument whether or not there is any other way to do this  --
> clearly, by now, it is known what NMI messages the Windows STOP screen will display, and
> ReactOS must display the same NMI messages. Since both Windows NT and ReactOS use the same
> routine for printing to the screen, it also makes sense that they'd both be using the
> same HalDisplayString API. One could argue that since you'd probably want to debug the
> NMI, it might make sense to enter the kernel debugger, which, since it is an exported
> kernel function that ReactOS must implement, ends up being the same call as Windows. So
> whether it was clean roomed, copied, reverse engineered, or fabricated out of thin air to
> match this specification, the resulting code would look the same (however, it should be
> better documented so the values don't look like magic). Of course these are all
> rational arguments that can be made *after* the function has been written, the burden of
> proof as to IF this is how the function was already written 
>
>  There are many questions as to whether or not those 6 lines of code are actually
> copyrighted at all, whether you or anyone else has any rights to those 6 lines of code
> since they are identical to Windows (by necessity), and whether or not the addition of
> ~460 additional lines to misc.c and improvement of the original function still enable you
> to refuse a GPL->BSD license change solely based on 6, 10-year-old, lines of code that
> are identical to an even older copyrighted source base.
>
>  To push this analogy further, I could decide that the following piece of code
>
>  "printf("%s\n","
>
>  is GPL, and block anyone from ever using it in a module that is BSD.
>
>  I think even GPL requires at least 10 lines of code before being able to claim the whole
> module is GPLed (and it's probably more complicated than that).
>
>  So to close the topic: it is unclear if you have any ownership of those original 6 lines
> of code, and it is even further unclear if 6 lines of interface code in a 466 line module
> allow you the right to dictate the license of the module.
>
>  -r
>
>    
> >   Ros Arm wrote:
> >      
> > >   The "ownership" and
> > > "copyright" of this code is not belonging to either you or anyone else but the
> > > original source it came from.
> > >
> > >  The PROGRAMMERS field indicates who is responsible for a piece of code in this project,
> > > is it not? In this case, since you have quitted many years ago, it makes sense this code
> > > is now belong to us.
> > >
> > >  It is Linux concept of "maintainer".
> > >
> > >  Thanks you,
> > >  [eVb]
> > >
> > >         
> >  Hi Ros Arm,
> >
> >  you are totally wrong here. The PROGRAMMERS field could be called 
> >  AUTHORS or CONTRIBUTORS and lists those who claim copyright or 
> >  authorship to a file. So removing someone from the PROGRAMMERS field is 
> >  a very disrespectul act, is a copyright violation and must be reverted 
> >  as soon as possible.
> >
> >  You can claim sole authorship to a file if you created the initial 
> >  version of a file.
> >
> >  You can also claim authorship to a file if you modified it in a 
> >  significant way. In this case you can ADD your name to the END of the 
> >  list of programmers. So the author who wrote the first version should 
> >  always stay on top of the list. Changing a "+" to "-" or adding
> > "+ 1" is 
> >  not enough to claim authorship.
> >
> >  And in no case you have the right to change the license of an existing 
> >  file without having prior permission to do so by ALL authors of that 
> >  file. As far as I can remember, I did NOT grant permission to relicense 
> >  my code under the BSD license. My contributions to ReactOS were, are and 
> >  will be published under GPL or LGPL only.
> >
> >  Therefore I ask you to revert the following patch:
> >  [ros-diffs] [ros-arm-bringup] 44860: NMI Support Patch 6: [HAL]: Fix NMI 
> >  recursion issues. [HAL]: Reset the display during NMI and paint the NMI 
> >  Screen of Death.
> >
> >  In case you fail to revert the patch within a week (aka 7 days) I will 
> >  revert this patch myself and restore the previous version.
> >
> >  And by the way, DON'T INTRODUCE YET ANOTHER FUCKIING CODING STYLE!!!! 
> >  Use the coding styles that are already being used!!!!
> >
> >  Oh, and before I'm done: I don't like to talk to meaningless nicks like 
> >  Ros Arm, RosLeg or ROSIDONTKNOWHOWTOFUKINGCALLMYSELF. Reveal your 
> >  identity! I don't see a reason why you have to hide behind you nick. If 
> >  you need to hide your identity you should better leave ReactOS because 
> >  these reasons can only endanger the project. And I will always prefer to 
> >  throw a single contributor out of the team rather than endangering the 
> >  whole project.
> >
> >  And finally, my name is Eric Kohl and I joined the ReactOS project in 
> >  December 1998. So I guess I have the right to voice my opinion here.
> >
> >
> >  Regards
> >  Eric
> >
> >  _______________________________________________
> >  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
>  .
>
>

[Eric Kohl]

Exactly!

I guess RosArm doesn't remember the old days when you set a few bits in 
one of the timers using GWBASIC, TurboPascal or TurboC to get some funny 
BEEPs from your machine.

Perhaps he's just too young to know.

Eric

Timo Kreuzer wrote:
>   The output on the screen is well known and documented.
> And was at that
>  time, too, as it could be seen pretty often. There's nothing secret. and
>  there's only 2 cases that need to be considered by analyzing the NMI
>  status register, which is also well known and documented. There are
>  magic numbers, because documentation usually contains those magic
>  numbers. It's 2 damned flags.
>  Also the initial version contained more than 6 lines of code. And your
>  "460" lines of code were actually like 13 lines of code for HalFlushTlb
>  and additional 8 lines of code for HalHandleNMI. The rest is
>  reformatting and excessive commenting. And you still want to claim the
>  sole authorship to this file? Is that maybe the reason for 3 line
>  comments? To make up more lines of "code" to claim authorship?
>  
>  Ros Arm schrieb:
> > Hi Eric,
> >
> > We apologize for the misunderstanding. The relationship of that field was confusing,
> since some files have authors that don't correlate to SVN history at all.
> >
> > In relation to what eVb was saying, I have looked up the entire SVN history of the
> misc.c file, which originally started out in NTOS.
> >
> > Your one and only actual contribution is here:
> >
> >
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/hal/x86/misc.c?re…
> >
> > Revision 1026, almost 10 years ago.
> >
> > In that revision, you created the file and "implemented" HalHandleNMI.
> >
> > It is interesting that your implementation of HalHandleNMI happens to print out the
> exact same messages that the NT4 HAL dumps on the screen.
> >
> > To obtain the same messages "clean-room", you must've been able to
> generate all the possible NMI traps on your machine, which is unlikely.
> >
> > Also, the choices of "0x40", "0x20" and "0x61" appear
> to be magic constants, instead of properly documented constants referring to the NMI
> status port and the NMI status bits.
> >
> > Additionally, the same "KeEnterKernelDebugger" call is present both in the
> NT4 HAL and your implementation of this function, even though, as of revision 1993:
> >
> >
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kd/kdebug.c?revis…
> >
> > That function only printed a string -- so there appears to have been little reason to
> make this API call other than to duplicate the original NT HAL's behavior.
> >
> > Furthermore, why even implement this function at all back in 2000? There was no NMI
> task gate back then, no NMI handler, and no caller of HalHandleNMI -- therefore, this
> function was impossible to test in ReactOS. It seems to have been implemented just for the
> sake of implementing "an easy function", without any actual real use.
> >
> > Whether this function, in 2000, was by coincidence an exact replica of the NT4 HAL
> HalHandleNMI, and you happened to have experienced all possible NMI traps and their
> messages on the screen, and you decided not to document the port and status bit values, or
> whether it was reverse engineered does not change the fact that the code was 100%
> identical. Therefore, I believe this was eVB's point that the true
> "copyright" of this function belonged to nobody else but Microsoft, and so the
> PROGRAMMERS field seemed logical to include the maintainer, not the "copyright"
> owner.
> >
> > So before lambasting about copyright ownership and licenses, perhaps you should be
> more careful.
> >
> > It is an entirely different argument whether or not there is any other way to do this
>  -- clearly, by now, it is known what NMI messages the Windows STOP screen will display,
> and ReactOS must display the same NMI messages. Since both Windows NT and ReactOS use the
> same routine for printing to the screen, it also makes sense that they'd both be using
> the same HalDisplayString API. One could argue that since you'd probably want to debug
> the NMI, it might make sense to enter the kernel debugger, which, since it is an exported
> kernel function that ReactOS must implement, ends up being the same call as Windows. So
> whether it was clean roomed, copied, reverse engineered, or fabricated out of thin air to
> match this specification, the resulting code would look the same (however, it should be
> better documented so the values don't look like magic). Of course these are all
> rational arguments that can be made *after* the function has been written, the burden of
> proof as to IF this is 
 how the function was already written 
> >  
> >  There are many questions as to whether or not those 6 lines of code are actually
> > copyrighted at all, whether you or anyone else has any rights to those 6 lines of code
> > since they are identical to Windows (by necessity), and whether or not the addition of
> > ~460 additional lines to misc.c and improvement of the original function still enable you
> > to refuse a GPL->BSD license change solely based on 6, 10-year-old, lines of code that
> > are identical to an even older copyrighted source base.
> >
> >  To push this analogy further, I could decide that the following piece of code
> >
> >  "printf("%s\n","
> >
> >  is GPL, and block anyone from ever using it in a module that is BSD.
> >
> >  I think even GPL requires at least 10 lines of code before being able to claim the whole
> > module is GPLed (and it's probably more complicated than that).
> >
> >  So to close the topic: it is unclear if you have any ownership of those original 6 lines
> > of code, and it is even further unclear if 6 lines of interface code in a 466 line module
> > allow you the right to dictate the license of the module.
> >
> >  -r
> >
> >    
> > >   Ros Arm wrote:
> > >      
> > > >   The "ownership" and
> > > > "copyright" of this code is not belonging to either you or anyone else but the
> > > > original source it came from.
> > > >
> > > >  The PROGRAMMERS field indicates who is responsible for a piece of code in this project,
> > > > is it not? In this case, since you have quitted many years ago, it makes sense this code
> > > > is now belong to us.
> > > >
> > > >  It is Linux concept of "maintainer".
> > > >
> > > >  Thanks you,
> > > >  [eVb]
> > > >
> > > >         
> > >  Hi Ros Arm,
> > >
> > >  you are totally wrong here. The PROGRAMMERS field could be called 
> > >  AUTHORS or CONTRIBUTORS and lists those who claim copyright or 
> > >  authorship to a file. So removing someone from the PROGRAMMERS field is 
> > >  a very disrespectul act, is a copyright violation and must be reverted 
> > >  as soon as possible.
> > >
> > >  You can claim sole authorship to a file if you created the initial 
> > >  version of a file.
> > >
> > >  You can also claim authorship to a file if you modified it in a 
> > >  significant way. In this case you can ADD your name to the END of the 
> > >  list of programmers. So the author who wrote the first version should 
> > >  always stay on top of the list. Changing a "+" to "-" or adding
> > > "+ 1" is 
> > >  not enough to claim authorship.
> > >
> > >  And in no case you have the right to change the license of an existing 
> > >  file without having prior permission to do so by ALL authors of that 
> > >  file. As far as I can remember, I did NOT grant permission to relicense 
> > >  my code under the BSD license. My contributions to ReactOS were, are and 
> > >  will be published under GPL or LGPL only.
> > >
> > >  Therefore I ask you to revert the following patch:
> > >  [ros-diffs] [ros-arm-bringup] 44860: NMI Support Patch 6: [HAL]: Fix NMI 
> > >  recursion issues. [HAL]: Reset the display during NMI and paint the NMI 
> > >  Screen of Death.
> > >
> > >  In case you fail to revert the patch within a week (aka 7 days) I will 
> > >  revert this patch myself and restore the previous version.
> > >
> > >  And by the way, DON'T INTRODUCE YET ANOTHER FUCKIING CODING STYLE!!!! 
> > >  Use the coding styles that are already being used!!!!
> > >
> > >  Oh, and before I'm done: I don't like to talk to meaningless nicks like 
> > >  Ros Arm, RosLeg or ROSIDONTKNOWHOWTOFUKINGCALLMYSELF. Reveal your 
> > >  identity! I don't see a reason why you have to hide behind you nick. If 
> > >  you need to hide your identity you should better leave ReactOS because 
> > >  these reasons can only endanger the project. And I will always prefer to 
> > >  throw a single contributor out of the team rather than endangering the 
> > >  whole project.
> > >
> > >  And finally, my name is Eric Kohl and I joined the ReactOS project in 
> > >  December 1998. So I guess I have the right to voice my opinion here.
> > >
> > >
> > >  Regards
> > >  Eric
> > >
> > >  _______________________________________________
> > >  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
> >  .
> >
> >     
>  
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Eric Kohl]

Hi Ros Arm,

you think you got a good case. No you don't.

Yes, I decided to implement an easy function. And I decided to implement 
HalHandleNMI because I had a Computer that had a broken memory module. I 
could run DOS for hours but trying to install Windows NT4 always caused 
an NMI bluescreen.

Your magic constants argument doesn't work as well as my source of 
information is a number of articles in the german computer magazine C'T 
from 1988/1989 about the hardware component of an IBM-compatible 
Personal Computer (PC/XT/AT and IBM PS/2). C'T issue 7/1988 includes an 
article 'Die PC-Bausteine'(The PC-Components) on the pages 164 to 171 
about the PIOs 8255 in the PC/XT and its successors in the AT and PS/2 
which implement the ports 0x60 to 0x64. In this article you can find a 
detailed description about masking the NMI and detecting the source of 
an NMI. This article also includes tables that describe the function of 
each bit of the PIO port. The author doesn't provide any symbolic 
constants for the bit masks so I decided to use the hex values instead.

The call to the function KeEnterKernelDebugger was added intentionally 
because if neither bit 7 nor bit 6 is set upon an NMI the 80x87 
coprocessor is the source of the NMI. In this case you might want to 
debug your application.

If you like, I can send you picture of page 166 where you will find the 
tables I mentioned above.

Now about the order of the two if-statements in HalHandleNMI. Well with 
only two of them you have a 50 percent chance choose the 'right' 
sequence. OTOH, I knew about the memory parity error first as I had seen 
it on my own machine. And I guess a friend told me about the second 
message. Perhaps he got used a text editor or the strings.exe utility 
from sysinternals.com. I don't remember that any more as this happened 
almost 10 years ago.


According to your train of thougt a 600 line file is not protected by 
copyright law if it was written by 100 programmers where each of them 
contributed exactly 6 lines of code. That might be true for your country 
but in Germany we dont have minimum number of lines. It depends on the 
context. A slogan like President Obamas "Change." can be protected by 
copyright.

To make a long story short, you can change the license of the file if 
you get permission by all authors and replace my implementation of 
HalHandleNMI by your own one.


Regards
Eric



Ros Arm wrote:
>   Hi Eric,
>  
>  We apologize for the misunderstanding. The relationship of that field was confusing,
> since some files have authors that don't correlate to SVN history at all.
>  
>  In relation to what eVb was saying, I have looked up the entire SVN history of the misc.c
> file, which originally started out in NTOS.
>  
>  Your one and only actual contribution is here:
>  
>
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/hal/x86/misc.c?re…
>  
>  Revision 1026, almost 10 years ago.
>  
>  In that revision, you created the file and "implemented" HalHandleNMI.
>  
>  It is interesting that your implementation of HalHandleNMI happens to print out the exact
> same messages that the NT4 HAL dumps on the screen.
>  
>  To obtain the same messages "clean-room", you must've been able to generate
> all the possible NMI traps on your machine, which is unlikely.
>  
>  Also, the choices of "0x40", "0x20" and "0x61" appear to be
> magic constants, instead of properly documented constants referring to the NMI status port
> and the NMI status bits.
>  
>  Additionally, the same "KeEnterKernelDebugger" call is present both in the NT4
> HAL and your implementation of this function, even though, as of revision 1993:
>  
>
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kd/kdebug.c?revis…
>  
>  That function only printed a string -- so there appears to have been little reason to
> make this API call other than to duplicate the original NT HAL's behavior.
>  
>  Furthermore, why even implement this function at all back in 2000? There was no NMI task
> gate back then, no NMI handler, and no caller of HalHandleNMI -- therefore, this function
> was impossible to test in ReactOS. It seems to have been implemented just for the sake of
> implementing "an easy function", without any actual real use.
>  
>  Whether this function, in 2000, was by coincidence an exact replica of the NT4 HAL
> HalHandleNMI, and you happened to have experienced all possible NMI traps and their
> messages on the screen, and you decided not to document the port and status bit values, or
> whether it was reverse engineered does not change the fact that the code was 100%
> identical. Therefore, I believe this was eVB's point that the true
> "copyright" of this function belonged to nobody else but Microsoft, and so the
> PROGRAMMERS field seemed logical to include the maintainer, not the "copyright"
> owner.
>  
>  So before lambasting about copyright ownership and licenses, perhaps you should be more
> careful.
>  
>  It is an entirely different argument whether or not there is any other way to do this  --
> clearly, by now, it is known what NMI messages the Windows STOP screen will display, and
> ReactOS must display the same NMI messages. Since both Windows NT and ReactOS use the same
> routine for printing to the screen, it also makes sense that they'd both be using the
> same HalDisplayString API. One could argue that since you'd probably want to debug the
> NMI, it might make sense to enter the kernel debugger, which, since it is an exported
> kernel function that ReactOS must implement, ends up being the same call as Windows. So
> whether it was clean roomed, copied, reverse engineered, or fabricated out of thin air to
> match this specification, the resulting code would look the same (however, it should be
> better documented so the values don't look like magic). Of course these are all
> rational arguments that can be made *after* the function has been written, the burden of
> proof as to IF this is  
how the function was already written is what matters.
>   
>  There are many questions as to whether or not those 6 lines of code are actually
> copyrighted at all, whether you or anyone else has any rights to those 6 lines of code
> since they are identical to Windows (by necessity), and whether or not the addition of
> ~460 additional lines to misc.c and improvement of the original function still enable you
> to refuse a GPL->BSD license change solely based on 6, 10-year-old, lines of code that
> are identical to an even older copyrighted source base.
>  
>  To push this analogy further, I could decide that the following piece of code
>  
>  "printf("%s\n","
>  
>  is GPL, and block anyone from ever using it in a module that is BSD.
>  
>  I think even GPL requires at least 10 lines of code before being able to claim the whole
> module is GPLed (and it's probably more complicated than that).
>  
>  So to close the topic: it is unclear if you have any ownership of those original 6 lines
> of code, and it is even further unclear if 6 lines of interface code in a 466 line module
> allow you the right to dictate the license of the module.
>  
>  -r
>  
> >   Ros Arm wrote:
> > >   The "ownership" and
> > > "copyright" of this code is not belonging to either you or anyone else but the
> > > original source it came from.
> > >
> > >  The PROGRAMMERS field indicates who is responsible for a piece of code in this project,
> > > is it not? In this case, since you have quitted many years ago, it makes sense this code
> > > is now belong to us.
> > >
> > >  It is Linux concept of "maintainer".
> > >
> > >  Thanks you,
> > >  [eVb]
> > >  
> >  Hi Ros Arm,
> >
> >  you are totally wrong here. The PROGRAMMERS field could be called 
> >  AUTHORS or CONTRIBUTORS and lists those who claim copyright or 
> >  authorship to a file. So removing someone from the PROGRAMMERS field is 
> >  a very disrespectul act, is a copyright violation and must be reverted 
> >  as soon as possible.
> >
> >  You can claim sole authorship to a file if you created the initial 
> >  version of a file.
> >
> >  You can also claim authorship to a file if you modified it in a 
> >  significant way. In this case you can ADD your name to the END of the 
> >  list of programmers. So the author who wrote the first version should 
> >  always stay on top of the list. Changing a "+" to "-" or adding
> > "+ 1" is 
> >  not enough to claim authorship.
> >
> >  And in no case you have the right to change the license of an existing 
> >  file without having prior permission to do so by ALL authors of that 
> >  file. As far as I can remember, I did NOT grant permission to relicense 
> >  my code under the BSD license. My contributions to ReactOS were, are and 
> >  will be published under GPL or LGPL only.
> >
> >  Therefore I ask you to revert the following patch:
> >  [ros-diffs] [ros-arm-bringup] 44860: NMI Support Patch 6: [HAL]: Fix NMI 
> >  recursion issues. [HAL]: Reset the display during NMI and paint the NMI 
> >  Screen of Death.
> >
> >  In case you fail to revert the patch within a week (aka 7 days) I will 
> >  revert this patch myself and restore the previous version.
> >
> >  And by the way, DON'T INTRODUCE YET ANOTHER FUCKIING CODING STYLE!!!! 
> >  Use the coding styles that are already being used!!!!
> >
> >  Oh, and before I'm done: I don't like to talk to meaningless nicks like 
> >  Ros Arm, RosLeg or ROSIDONTKNOWHOWTOFUKINGCALLMYSELF. Reveal your 
> >  identity! I don't see a reason why you have to hide behind you nick. If 
> >  you need to hide your identity you should better leave ReactOS because 
> >  these reasons can only endanger the project. And I will always prefer to 
> >  throw a single contributor out of the team rather than endangering the 
> >  whole project.
> >
> >  And finally, my name is Eric Kohl and I joined the ReactOS project in 
> >  December 1998. So I guess I have the right to voice my opinion here.
> >
> >
> >  Regards
> >  Eric
> >
> >  _______________________________________________
> >  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
>