From: "mike@trausch.us" <mike@trausch.us>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] grub vs grub 2
Date: Tue, 14 Feb 2012 18:19:55 -0500 [thread overview]
Message-ID: <4F3AEC1B.4020401@trausch.us> (raw)
In-Reply-To: <475D2105-FA04-4A95-9AEB-328512F8985E@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4589 bytes --]
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 729 bytes --]
next prev parent reply other threads:[~2012-02-14 23:21 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-14 17:36 [gentoo-user] grub vs grub 2 james
2012-02-14 17:53 ` Florian Philipp
2012-02-14 18:08 ` LK
2012-02-14 18:24 ` mike
2012-02-14 18:40 ` LK
2012-02-14 18:46 ` Alecks Gates
2012-02-14 18:52 ` mike
2012-02-14 19:04 ` Michael Mol
2012-02-14 20:35 ` mike
2012-02-14 20:45 ` Michael Mol
2012-02-14 23:47 ` Paul Hartman
2012-02-14 23:53 ` mike
2012-02-14 19:29 ` Andrea Conti
2012-02-14 19:53 ` [gentoo-user] grub vs grub2 LK
2012-02-14 19:59 ` Michael Cook
2012-02-14 20:44 ` mike
2012-02-14 20:58 ` LK
2012-02-14 21:19 ` Michael Mol
2012-02-14 20:30 ` Alex Schuster
2012-02-14 20:46 ` mike
2012-02-14 20:42 ` [gentoo-user] grub vs grub 2 mike
2012-02-14 20:57 ` LK
2012-02-14 21:44 ` Neil Bothwick
2012-02-14 23:19 ` mike [this message]
2012-02-15 12:19 ` Tanstaafl
2012-02-15 12:28 ` Neil Bothwick
2012-02-15 12:33 ` Michael Mol
2012-02-15 14:37 ` mike
2012-02-15 14:47 ` Tanstaafl
2012-02-15 15:02 ` Neil Bothwick
2012-02-14 21:46 ` Neil Bothwick
2012-02-15 15:57 ` [gentoo-user] " James
2012-02-15 16:11 ` Neil Bothwick
2012-02-15 16:28 ` Claudio Roberto França Pereira
2012-02-15 17:17 ` Paul Hartman
2012-02-15 17:33 ` Doug Hunley
2012-02-15 17:40 ` Neil Bothwick
2012-02-15 8:10 ` [gentoo-user] " ny6p01
2012-02-14 20:57 ` [gentoo-user] " James
2012-02-14 18:07 ` [gentoo-user] " Stefano Crocco
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F3AEC1B.4020401@trausch.us \
--to=mike@trausch.us \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox