* Juergen Beisert juergen127@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