[LinuxBIOS] LInuxBIOSv3 - Reset and CAR code

[Stefan Reinauer]

* Juergen Beisert <juergen127 at kreuzholzen.de> [070519 12:00]:
> > Exactly. And code quality does not gain from splitting a single small
> > task into 5 different files. We had that in v2, and nobody would
> > understand it. stage0_xxx.S is something that never ever gets touched
> > once it is written for a new CPU.
> 
> And if you try to support a new CPU? Where to start? Copying one of the 
> existing stage0_xxx.S and modifying until it works? ("Debug into existence")
 
take an existing one, remove the CAR code and add new CAR code. Nothing
too wild. 


> > How does code quality improve when you 
> > make three files out of it?
> 
> Assembler is always very specific. So one file for one dedicated
> function. The buildsystem is responsible to select and combine the
> right ones.
 
I think a single assembler file and no other need for assembler is
pretty elegant. If there is a problem in the assembler code, you have
exactly one location to check.

Doing the complexity in the build system instead of the single assembler
file is possible. But where is the win?

One file for one dedicated function. Thats what stage0.S does. "get the
machine to the state where you can execute gcc compiled code". Ie. this
is the "extended arm" of the silicon.

I am absolutely on your side, but I ran out of reasons, so I am curious
about what you think. I sat on the other side of the table and I am
playing advocatus diaboli now.

> > Well yes and no. It works because then we have three code lines that
> > noone ever touches can be made to look like sugar.
> 
> No! We will win reproducibility and reliability!
 
How is the current code not reproducable?
How is the current code not reliable?

I had the code implemented that you suggest. It was teared out because 
the tenor is it looks nice but it is not reliable enough.

> The question is: Will this increase or decrease user's problems to work with 
> LinuxBIOS? 

The code up to "enable CAR" is basically 3 assembler files and three
linker scripts in LinuxBIOS v2. They got never changed since they were
written. Can you make an example of your theoretically correct
request for modularity and a more generic framework actually solves
a problem that any developer (not even user) of LinuxBIOS will ever have?

> So can we have the focus on real hardware issues or have to waste 
> time to worry about broken toolchains? Yes, the preparation needs more time, 
> but after it we could start with the real job.

We can do the real job, and we don't look at that one assembler file
except when we port to a completely new CPU. Not a big deal. That
problem is solved and we dont force any toolchain.

>  - reference toolchain(s)
>  - documentation, the fragile a part is the more documentation it needs
> 
> I offer to work on both.

Great. This would end the discussion. If it improves the situation we
will of course be more than happy to use it!

Thanks for doing this.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/