[ros-dev] Bye bye
James Tabor
jimtabor at adsl-64-217-116-74.dsl.hstntx.swbell.net
Fri Jan 20 01:12:51 CET 2006
Hi!
Alex Ionescu wrote:
> Hi,
>
> I'm going to answer generically, not point-by-point, since I don't have
> much time, but I hope I can cover everything:
>
> 1) Those magic sizes were calculated in my head and I didn't have time
> to make them into constants as I did many of them.
> 0x29C is the pre-defined value of NPX_FRAME_LENGTH + KTRAP_FRAME_LENGTH.
> 0x48 is the differerence in the KTRAP_FRAME between the registers that
> we will skip. I could've done (KTRAP_FRAME_XXX - KTRAP_FRAME_YYY).
>
> 2) This is not a matter of driver compatibility. The fast system call
> stub is a mostly hardware-defined entrypoint, handled by low-level
> software logic. In implementing it, there are only 3 available sources
> of information: Whatever minimal info the Intel manual gives, the Linux
> sources, the Windows kernel binary. It is almost simply impossible to
> "guess" how the stub should work. Filip tried to make it work more then
> a year ago, and even he gave up (the AMD version), beacuse it is simply
> too hard and confusing unless you have some available code to look at.
> As such, my first and foremost source was the Linux source code. It
> helped me understand how to setup the LSTAR MSR register, as well as the
> other register values. Then, through several mailing list posts, I was
> able to understand some bugs in the way ReactOS had its segments set up,
> which caused problems in the code. Then, to understand the way Windows
> chose between INT2E and SYSENTER, I found a document online written by a
> person called Elicz, which described the stub and what it should do,
> much in the same way people argued "clean-room reverse engineering" is
> done. With this information, I was able to write more then 85% of the
> stub. My next, and final remaining possible step, was to use IDA to look
> at the Windows code. I used it as a learning tool, not as a copying
> tool. It is hard to argue that what I did was "Reverse-engineering",
> which, to my knowledge, implies taking something apart to re-create it,
> since this usually implies converting the assembly code to functional C
> code or otherwise. But I don't view as looking at assembly in order to
> understand a low-level hardware interface as "reverse engineering". And
> yes, as described above, it -was- my last choice. Additionally, the
> parts which were supposedly "copied" are NOT part of the functional part
> of the code. They are debug helpers, offering nothing else but
> assertions in case of problems.
>
> 3) I find the idea of removing code that "Violates policy" ludicrous. No
> one has the right to dermine if some piece of code violates policy or
> not, especially if the author writing it denies it. Only a judge or
> lawyer should be able to make that decision. Additionally, in this
> specific case, what could be done? The code is in SVN and even if
> rewritten it will 1) look the same, excpt "edx" would become "esi" and
> vice-versa 2) a judge would still argue that "hey, you had the previous
> code in SVN for over a year, you've all been tainted and could've just
> as easily looked at it". Furthermore, such attitude might start
> devolving into a dangerous witchhunt. Don't like someone's code? Report
> them and have it removed! This communist-era and fascist-era behaviour
> deeply scares me and reminds me of a country and regime which I fled. I
> do not want to see it happen, because it would slowly kill and rip apart
> this project.
>
I hear a duck, Does anyone else hear a duck. Wow I do!
> These monthly Alex-bashings are starting to tire me very much and maybe
> it's time I took an offensive position instead of a defensive one. I do
> not want to start naming names, but many of our developers have already
> violated our policy in different ways. If you actively start enforcing
> it, then it will be my duty as an active developer to enforce it as
> well, meaning that hiding any information I have concerning other
> developers' violations would be considered as complicity, so I would be
> legally bound to report them. In other words, this would mean that the
> project would lose half of its developers.
>
I can start a formal investigation if you want?
> I am sick of being treated as the black sheep and the "example". This
> stops here. I have always been put in the spotlight for almost any
> action I took, and I've always taken steps to repair it. But these
> public trials of guilt have passed a limit. Either start questionning
> everyone and treating every developer the same, or stop using me as a tool.
>
> Best regards,
> Alex Ionescu
>
I would recommend everyone take a step back and think about this.
Please let us not wakeup that giant! (Not M$)
James
More information about the Ros-dev
mailing list