bug-grub
[Top][All Lists]
Advanced

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

Re: El Torito, odd floppies 0.92 working patches...


From: Yoshinori K. Okuji
Subject: Re: El Torito, odd floppies 0.92 working patches...
Date: Sat, 04 May 2002 09:38:57 +0900
User-agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryƍmae) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI)

(I thought I should send this mail to Thierry privately, but I chose
to post it to bug-grub as well, because it might be useful to notify
other people of my opinion. In the following paragraphs, I mean
Thierry by "you".)

First of all, I'd like to say that I appreciate your work and I'm very
impressed with the new code. You have done a lot of great work beyond
my original request and vision. I think the position-independence
feature is a Good Thing to have.

Then, on the negative point: I really object to the separation of the
"arch-i386" code. The GRUB code is quite depend on i386-pc through the
whole code. For example, the purpose of images, such as stage1 and
stage2. In some architectures, it would be completely meaningless even
to have stage1. Many commands supported by stage2 assume i386-pc. What
I want to mean is not the implementation of the commands, but the
purpose of the commands. For instance, "makeactive" is nonsense on
SparcStation.

Of course, the implementation is also depend on i386-pc. The structure
has the dependency. The code has the dependency. The tricks have the
dependency. IMO, _all_ have the dependency. So, if someone says to me,
"Hey, GRUB assumes i386-pc too much. To make it portable, segregate
i386-pc-dependent parts!", then I would just do "mv stage1 stage2 lib
grub netboot util arch-i386-pc". That means that it is nonsense to
just move some macros to headers for i386-pc only.

I even doubt if GRUB could be reusable. I don't deny that a small part
of the code could be written portably (e.g. the ELF parser), but most
of the code can never be portable. Whenever I hear people talking
about GRUB on other architectures, I believe they are talking about
the look-and-feel but not the code. In fact, all multi-arch
kernels/operating systems I know have put the whole bootstrap code
into each arch-dependent place (see Linux, NetBSD, OpenBSD, OSKit,
Mach3, Plan9, etc.).

Thus, I object to any attempt to segregate arch-dependent parts from
GRUB by halves. That makes sense _only if_ you demonstrate that your
new code helps out GRUB working on both i386-pc and another
architecture. I suggest that you try to implement a GRUB-like boot
loader on any other architecture, before making GRUB portable. It is
impossible to realize how to reorganize GRUB code without such an
effort.

Thanks,
Okuji



reply via email to

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