> That's not true, otherwise noone would use agile software development
> with OOP. You have a very rigid, almost V-model way to think about this.
Yes, Maybe It's not necessary an exhaustive analysis. But, anyway, It's necessary to define what is our objective, define an ideal architecture (drawing if necessary), although this could change during the development. This can help us to set a roadmap to this objective, instead repeat the refactor many times until agree the result.
> Also you're focusing on OOP, while to me, it's only one of the elements
> required for such a project. And all these requirements are driven by a
> single motivation : to reduce maintenance costs. The Hurd is developped
> by a very small group of people, very sporadically, but has virtually
> no deadline constraints. Event the GSoC deadline doesn't matter that
> much since, in the end, mentors are the ones who evaluate your work, and
> it can easily be decided that the result is a success even if it didn't
> meet all the initial conditions. As a result, it's even more important
> than in other projects that original code be as good as it can get.
Ok, I agree with this.
> Mach code is in essence OOP, something you're throwing out the window
> for no good reason.
I tried to add my code in the current Mach structure.
I wasn't clear about how to architecture the code, so I find a simple implementation with functions (but dirty, in fact)
> Mach is in essence portable, something you also
> decided to forego without much thought.
I was afraid about add new structure which could broken the code, so I simply tried to fit the new data in the Mach structures.
> Yes, Mach code has some extern
>variables, but these concern a handful of global objects only, like
> the kernel task, map and pmap, and that's code from the 80s and there's
> no reason to continue that trend.
Yes, I agree, and even this is not the only bad practice. I see many #define macros replacing C functions, which difficults the debugging of the code. Some of these #define could be replaced by inline functions.
There are also many very long functions, sometimes with a dirty logic (check thread_setrun() in kern/sched_prim.c), which could be a good candidate to refactor.
> And without reducing the individual complexity of the functional
> modules involved, you won't be able to master what you're doing.
> And my requirements to work on this project have everything to do with
> reducing that complexity. It's also important to make it easy for
> other people to work on that code.
Ok, It's a good idea.
I like your ideas, now I want to define a more specific objective, and a little roadmap.