[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

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$)

More information about the Ros-dev mailing list