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

[Thierry Laronde]

Okuji,

On Sat, May 04, 2002 at 09:38:57AM +0900, Yoshinori K. Okuji wrote:
> 
> 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. 

I know this and one purpose of the "arch-i386" was for me to show that
almost all the GRUB code is ia32 specific. Indeed, I first move start.S
and so on to stage1 renamed arch-i386 etc. So the arch-i386
creation is not a claim that GRUB could be in a foreseeable futur a
"general" bootloader. I use this, as already mentionned, to clearly
organised the headers, segregating local and general variables.

Please note that at the moment changing, in the "include/" and in the
include directives, "arch-i386/" to "" don't cause any problem ;)

But I think that the misunderstanding is caused by implicite (unsaid)
ideas about what GRUB is or could be. For me, GRUB, with its features is
almost a "mini" kernel. Most of the gzip code, of the shell-like
features and so on could be arch independant. Thinking about this arch
independence could help us, in the future, to include GPLed code coming
from major kernels almost as is, or at least, without major changes. So
I claim that tagging explicitely ia32 specific part of the code will
help programmers to better organize the code and will allow us to more
easily import chunk or modules coming from alien sources.

> 
> That means that it is nonsense to just move some macros to headers for 
> i386-pc only.

As I have already said, at the moment this is only this, because I have
only rewritten stage1. But, one day or another, me or other will I hope
touch the next parts of the code, applying this very same method
(beginning by loading the gunzip routines --- arch-independent for the
most part --- for unzipping GRUB).

> 
> 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.).

The big picture: a bootloader, even a "mini" OS will ever have a huge
part of arch-dependent code, and a small set of arch-independent stuff
(user level stuff more or less). But it could be a great thing to code
_as if_, to make _as if_ GRUB could be a common booting interface shared
by different machines. 

> 
> 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.

About the "halves" I have already answered --- that's because the major
rewrite is about stage1. But for me like for a majority of us the
problem is that we have only access to "old" ia32 machines... But
perhaps could we imagine to support two architectures: ia32 and... mmix,
Donald E. Knuth RISC "virtual" machine. The problem being that there is
no firmware defined for mmix to my present knowledge.
But I think that the inclusion in "general" files like shared.h,
builtins.c of the <arch-i386/*> and so on clearly show what you say: the 
code is ia32 specific.

I don't object about removing the arch-i386 directory and flatten the
directory tree. But I don't see neither where are the problems: I see
only the advantages, even if GRUB for some... years stays ia32 specific.
But the advantage of libre software for me is not only to have access to
working known code: it is also a matter of "continuing formation"; a
place to try and to test what has not been tried. A place to dream a
little if this dream is also a working reality...

Regards,
-- 
Thierry Laronde (Alceste) <address@hidden>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C