On 02/14/2012 03:57 PM, LK wrote:
> First, why do we need that much code?

First, are you talking about source or binary code?

If you're talking about source code, then realize this:  Not all that
source is even compiled on your system.

As to the source that *is* compiled on your system, there is:

  - A tiny boot loader (max 448 bytes of binary code), which loads
    the GRUB core.

  - The GRUB bootloader core, which is the GRUB "main" program and
    which knows how to talk to different types of modules.

  - The modules themselves.  There are modules for:

    - disk types, including PATA, SCSI, USB, Device Manager, DMRAID,
      LVM, LUKS.

    - filesystems, including ext2, btrfs, reiserfs.

    - partition types, including MBR, GPT, Apple Partition Map.

Each type of module implements exactly the same interface; the core only
needs to know how to talk to that type of module to communicate with all
modules that implement that interface.

The modular design makes it easier to (a) support new platforms, boot
protocols, bus types, partition types, and filesystems, and (b) ensure
that only code necessary for a particular type of thing is loaded.

This design is _necessary_ to deal with today's world.  Your computer is
almost certainly setup differently from mine; I require the use of a GPT
module on my system, for example.  You may not, if you still use MBR.
In fact, if you're using GRUB Legacy, then you almost certainly do not
require the GPT module on your system (at least not right now).

GRUB 1 assumed BIOS, and assumed MBR.  GRUB 2 assumes neither.  And for
that matter, supports encrypted disks and logical volume management
(both relatively common especially in servers) without third-party patches.

For the _most_ part, GRUB 2 is simply designed to handle today's world.
 It also includes features that distributions developed (independently,
and incompatibly between each other) for GRUB 1 as patches or add-on
programs.

> If we have less then we dont
> have to divide into modules.

Not true; modules are used in GRUB not because it's too big (once in
32-bit protected mode, all memory becomes available), but to help
organize the system better.  This simplifies the design.  If I want to,
I can create a new type of filesystem, and then all I have to do to make
sure that GRUB 2 supports it is to write a module that knows how to talk
to it.  Nothing changes anywhere else in GRUB.  If I create a new type
of firmware, I simply write code that knows how to talk to that type of
firmware, and I am done.  Now GRUB 2 still runs on my PC, but also runs
on my new custom computer.  And that code for my custom computer never
gets loaded on your computer, because your computer never uses it.

Modules in this case are a structural (design) thing to simplify the
design of the program, not to make it possible to fit in memory or
anything like that.

> Second, it does not translate into complex but rather into too much,
> and whenever it is too much than needed, its hard to understand
> and THUS complex. Not the other way.

Having spent the last 30 minutes looking at the GRUB 2 sources from the
bzr repo, I can tell you that it's very easy to understand; once you
understand how the FS interface works, it's very easy to learn how one
FS module reads a filesystem.  And you then gain the understanding
required to write a new, independent module.

Think of GRUB 2's modules as "subprograms" if you must, which implement
a particular (and identical) API for each instance.

If you're interested, I can detail a history for you, and explain why
GRUB 1 was discontinued and why the whole thing was restructured in
detail.  I can't right now, as I am about to get on a conference call,
but I can certainly do so later tonight or tomorrow if you want.

What it boils down to, though is that GRUB 1 made assumptions (that
every computer used BIOS, that every computer used MBR partition tables)
which no longer hold true.  Because they no longer hold true, it was
necessary to push that functionality into modules with a standardized
interface, in order to support EFI and GPT.  That also enabled GRUB 2 to
be able to run on more than one platform, since it no longer made
assumptions that were specific to consumer-class PC systems.

        --- Mike

-- 
A man who reasons deliberately, manages it better after studying Logic
than he could before, if he is sincere about it and has common sense.
                                   --- Carveth Read, “Logic”

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to