"Wolf Lammen" <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub