6 Apr
2005
6 Apr
'05
2:33 p.m.
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