Casper Hornstrup wrote:
Will you ever knowledge that rewriting large parts of ReactOS in your working copy causes all sorts of problems, and start getting the changes into the repository in smaller chunks or will you ignore these problems and continue to do this in the future?
Casper
Hi,
I am currently entering the last 5 weeks of school of my last year, so I'm going to be focusing on that instead of ReactOS. Lately, I've tried to work on both, but this has delayed my code as well as hurt my grades. I intend to be back around the week of May 10th.
In the meanwhile, I would kindly like to ask developers to e-mail me if they have any plans to touch the following:
- Kernel Scheduler, Thread Creation, Context Switching, System
Initialization. I have re-written everything for a faster and more complete system based on NT semantics. Includes everything from realtime support, proper dynamic and static priorities, real system thread support, much faster scheduling, pre-emption, removal of the PEB/TEB 64K block hack and ros-only members, better organized code and Mm routines for manipulating kernel stack/teb/peb, etc...
Impossible to split into small parts. They are completely interlinked. This is a feature patch and will be in its own branch, like it was decided that we're supposed to do. Just like Hartmut's Cc rewrite.
- Pushlocks. I have almost all the necessary support code written and
I'm only missing one function.
Not a rewrite, a one file implementation. Less then 1000 lines.
- IRQL management in HAL and Spinlocks. I have highly modified the IRQL
routines for a large increase in speed, as well as made spinlocks faster on UP and non-debug builds. I have also corrected some IRQL routines to use the proper KPCR members for the IRR and others.
Split as two patches, one for IRQL and one for Spinlocks. Spinlock one will probably be < 200 lines, IRQL one will be the size of a file, and most certaintly ~500 lines.
- Object Manager. I have a complete re-write in progress which uses
public NT structures instead of our internal ones, adds more security, and corrects some missing features and adds some. Majorly changes some aspects of the Ob (for example regarding on the status of handle/pointer count after creating an object, and the work of ObCreate/ObInsertObject, which is totally different in ROS vs NT. See blog article for more info). However, any bugs that are easy to fix should still be fixed in the current Ob. The new one is months away.
Once again, a self-contained feature branch will be done for this.
- Queued Spin Locks, KGATES, Guarded Mutex. I already know Filip is
working on this and I was planning on collaborating with him. Unlike the previous things, I haven't actually *coded* anything regarding these, but I have the design in my head and would like to work on it, so I would love to share what I know if anyone is actively interested in working on it.
Not a rewrite, a three file implementation. Will be split in three patches, all which will be < 1000 lines. Then QSL will be implementted step by step in parts of the kernel.
I don't see the problem with... 6 small patches, one for each new implemented feature, and 2 branches for specific large rewrites. I'm starting to think you just had to say somethign mean before I left.
Oh well.
Best regards, Alex Ionescu