> 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. El mié., 5 feb. 2020 a las 11:49, Richard Braun (<rbr...@sceen.net>) escribió: > On Wed, Feb 05, 2020 at 10:18:35AM +0100, Almudena Garcia wrote: > > To do a "serious work" as OOP, It's necessary to think about the current > > work, separating the pieces of the project, thinking what relationship > will > > be between the pieces... Write empty code structures, without a previous > > rethinking about the final architecture and structure of this code, can > > cause even more problems than current "dirty" design. > > 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. > > 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. > > Mach code is in essence OOP, something you're throwing out the window > for no good reason. Mach is in essence portable, something you also > decided to forego without much thought. 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. > > > But these tasks are too long for a GSOC. I'm really interested in GSOC, > but > > the OOP objective is too ambitious for It. > > They're not "tasks". They're requirements for success, especially for > something as difficult as correct concurrent code with shared memory > involved. They're not work in a sequence of coding sessions, they're > part of all coding sessions. What's ambitious is the project itself, > namely SMP. Well be ambitious, or don't. > > > So, I prefer continue with my current code, doing simpler refactors to > ease > > the future redesign, but without stop the current objectives (scheduler > > synchronization, and load system with cpu 0 as bound processor). > > You'll just waste a lot of time getting there, if at all, with that > approach. Refactors are only good if applied on code that is already > fit for incremental change. Your existing SMP implementation is not. > It needs a complete rework. The fact that you were never able to > understand why it's not able to handle more than 2 CPUs is a frightnening > indicator of that state. Imagine the day you'll be facing apparently > random crashes that can occur almost right away or after hours of run > time. Without completely mastering what you're doing, it's almost > guaranteed that you won't be able to fix those, let alone identify > them. 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. > > I wouldn't be insisting so much on these points if I didn't think they > were critically important. All this is not new. You're a student, so > learn from it. > > -- > Richard Braun >
