Re: stage 1

[aeriksson]

"Wolf Lammen" <address@hidden> wrote:
<snip>
> D. Software Design
> Some of the complexity of stage 1 could be put down to the fact that it is
> designed as an allrounder. Whether you use it on a hard disk or on a floppy
> disk does not matter at all. This was convenient at times when there were only
> two media types bootable. You simply copy the boot track from a floppy
> disk to a hard disk, and all works fine.
> But this concept is broken for quite some time already. First, you see
> plenty of other bootable media such as a CD-ROM. Second, because of BIOS bugs,
> GRUB already patches stage 1 when it loads it onto a hard drive, so simple
> copying won't work any more already.

If it counts for anything , I'd say it seems like a sensible way
forward. Anything which makes things cleaner is a Good Thing, imo.
Given the relatively small number of active hackers I've seen on this
list I'd be inclined to say that a cleaner architecture from a SW
Design point of view is desirable and might lead to more people being
able to successfully contribute, fix bugs etc.

While at it, I'd like to take the opportunity to ask you and the rest
of the list what the current thinking is for the build system. I've
spent quite some time trying to figure out what piece of code is
responsible for what, when it's called, and how it's built, and I'm
still not sure of the details. 

For example, there is a currticks() thing in stage2/asm.S which is
apparently called from c since it has an ENTRY() clause. Users of this
function are (I guess) expected to include shared.h. So far so good.
Looking around a bit further I notice that two users are netboot/
cs89x0.c (which I use) and netboot/fsys_tftp.c. Hmmm, alright, but
what about the currticks() in  netboot/timer.c ?? That one seems to be
wrapped by a #if defined(CONFIG_TSC_CURRTICKS) which is never defined
anywhere. Add the currticks() I just found in grub/asmstub.c and the
confusion gets quite big. Adding automake and autoconf on top of that
just adds to the confusion since the resulting Makefiles becomes
unwieldly.

What are the underlying principles by which the code is organized? It
seems the code has committed all the 'smarts' about choosing backends
for various things (such as the currticks() call which I understand
need to be different for unix application from a stageX bootloader) to
automake/autoconf, rather than using e.g. the filesystem (many apps
have os/unix/linux/, os/unix/netbsd, os/win32/ type directories for
pluggable support for different environments), or elaborate defines in
the include files as the linux kernel has.

I'm planning a patch to add a --disable-floppy and a --disble-harddisk
option. I suppose I have to learn about the philosophy around the code
organization before I can get that straight. All help would be
appreciated...

Cheers!

/Anders