bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Google Summer of Code


From: Richard Braun
Subject: Re: Google Summer of Code
Date: Wed, 5 Feb 2020 10:49:35 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]