bug-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

short summary of my future plans


From: OKUJI Yoshinori
Subject: short summary of my future plans
Date: Fri, 20 Oct 2000 21:07:03 +0900

  Usually, I don't like to discuss distant future plans, as that tends
to ending up with only an empty theory. But I write the short summary
of my future plans, because Gordon is enthusiastically working on
Figure. So this is mostly for Gordon.

  My plans include both user-visible and user-invisible features. So
some are just to ease the development of GRUB, and the others are both
for developers and end-users.

(1) Memory management

Lacking memory management is the big fault of the current
GRUB. Because of this, we cannot easily extend GRUB, when features we
want to implement would require variable or large chunks of memory,
and the memory usage is poor, since we need to allocate memory
statically, even if some chunks are not always necessary.

(2) Multiple files

Because the current implementation permits to open only one file at a
time, it is difficult or impossible to read multiple files
recursively. Therefore, the ability of the scripting language is quite
poor. This is heavily related to (1).

(3) Plug-ins

GRUB isn't necessarily flexible, because some features must be
selected at build time. And the size of Stage 2 is unreasonably large,
since all the code must be loaded statically, even if some of the
features are not actually used. So GRUB should be splitted into
plug-ins (or "modules"), so that the core image can be lean.

(4) Internationalization

Frankly speaking, I myself don't need internationalized GRUB, as I
read English without effort. However, if we want to make GRUB
user-friendly, I18N is very important. This will be quite hard,
because we must implement everything ourselves, as GRUB runs with no
operating system. I18N consists of mainly four parts: input, output,
internal handling, and translation.

(5) Graphics

You may think, "Why should GRUB have graphics support?" There are two
reasons: a negative one and a positive one. The negative reason is
to suppress local patches. Since many Linux distributors made local
patches to display pics, there are already some incompatibility in
their own GRUB's. I feel that this is unfortunate. IMO, local patches
are generally Bad Things.

The positive reason is related to (4), that is, to show multiple-byte
characters on the screen. Because CJK have more than 10000 characters,
the VGA font memory is too small. So, if we would support I18N really,
graphics support is required.

(6) Multiple architectures

One of the obstacles when you develop an operating system is that
every architecture has a different booting method, so the effort to
port your OS to another architecture could be critical. I think we can
ease the effort by porting GRUB and the Multiboot Specification to
other architectures. But it would be hard to investigate how to share
code among various architectures. I don't have any good idea at the
moment.

(7) Scripting language

I haven't considered much about this yet.


  I hope that this short overview could be helpful for Gordon and
other people who are interested in GRUB's future. If you have any
requests, feel free to post them to this list.

Okuji



reply via email to

[Prev in Thread] Current Thread [Next in Thread]