Re: GRUB plans...

[erich]

Thierry Laronde <address@hidden> wrote:

> May I suggest to reorganise, before modifying the code, the tree and
> names of sources? When I worked on adding the CD and extended floppy
> formats I was a bit puzzled by the names (stage1 loads start.S which
> passes control to asm.S which calls common.c which transfers to main in
> stage2.c ...) and by the organization (architecture dependent code has
> to be put in a separate directory ; the GRUB versions of some of the
> functions commonly found in libc should be put in a separate directory
> too, etc...).

Some of that organization was purposeful.

Nearly every OS/low-level-hardware executing program uses "start" as
the name of the part which does startup, in part because it's VERY
different from the rest of the code.  GRUB's has stack setup, interrupt
management, and even some critical 16- & 32-bit code switch control.

"asm" is the source file for all the extra random bits of assembly.

"common" is the source file that does common C-level startup for all the
GRUB stage 1.5+/2 variants before calling what is essentially the "main"
for whichever variant is built.

"stage2" is the main stage2 source file.

I at one point thought I might have had others.  Who knows?  That still
might be the case.


As to a reorg, I was going to be discussing some of this with Okuji
in any case.

Do you have a suggestion, given the purposes mentioned above? 


> Another thing that would be great is to code with cweb [is there a web
> implementation for assembly?]. I --- badly --- mimic a web style for
> stage1.S putting lots of comments, but the interaction between the
> different pieces of code would be greatly emphasized by literate
> programming --- probably one of the best ideas of Don Knuth.

WEB (C and Pascal are the ones I am familiar with) is an interesting
idea, but I think one fundamentally flawed for the following reasons:

  --  Most people are not familiar with it.

  --  It obscures the actual code written somewhat.

  --  It doesn't exist on many platforms.


All are barriers to getting real work done.  Hence I'm not in favor of it.

I'm very much in favor of practical measures to make or encourage
progress and maintainability.  The general rule I've arrived at which
seems a bit of a sweet spot maximizing the product of progress,
understandability, and maintainability (and I won't claim to have
been consistent with my early work on GRUB 0.5, though some parts
I did a good job on ;-) is:

  --  Simple concise code as much as possible.

  --  Comments/overviews about the high-level architecture and purpose
      of code, and on parts where the purpose is not clear from what is
      written (for example, commonly in a bootloader or other hardware-
      control code, sometimes there are gyrations whose purpose is not
      clear from looking at the code...  say working around a hardware
      bug where you can't do certain things even though the interface
      would seem like you could).

  --  NO comments on code that can be understood by reading it.  They
      can (and usually do) get out of date, become more of a confusion
      than a help, and frankly, if someone can't read straight-forward
      sections of code without comments, then they shouldn't be trying
      to mess with it.


If you want to keep discussing this, we should probably have it offline
for now.  I realize it can be a religious issue and can't claim I don't
have some blinders on about it, but subjecting the list to all the
wrangling will likely be tiresome for many...


--
    Erich Stefan Boleyn     <address@hidden>     http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"