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) <[EMAIL PROTECTED]> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
