Re: GRUB executables
From: Erich Boleyn <[EMAIL PROTECTED]> Subject: Re: GRUB executables Date: Fri, 22 Oct 1999 14:21:15 -0700 > Personally, I like the idea of having all config files editable at > boot time as desired. Yeah. I think that is preferable, too. The flexibility is one of the features of GRUB. > I want to continue this discussion when those interested have time. I have the feeling that we may not have any choice in what encoding we will use for the external encoding, because: * If a filesystem uses, for example, UTF-8, we can't help supporting UTF-8. * If a user uses some local encoding in his country (such as EUC-JP), we should support it to read his configuration file. * and so on... Thus, the question is what encoding we should use for the internal encoding. I know there are many encodings used in the real world: Mule, Arena I18N, UTF-8, etc... (I feel that the confusion in computer science of natural languages is a nightmare, much worse than the PC BIOS.) > A simple dynamic linker isn't that hard to add (libc has an example, > if nothing else). If GRUB may support only ELF, that's not so difficult, I think. But if GRUB supports multiple formats such as COFF? That will be much work for me (perhaps because I don't know any format but ELF very well). > Q: Is there inter-dependencies between the modules that want to be > resolved? (this is probably not a good idea, IMO) This answer depends on the granularity, that is, how to break the components. So we have to know (or define) what kind of a module is necessary and what function should be made modular. An example is the netboot. We can implement it in a single module but it is also possible to break it to a device driver component, a network protocol component and a network filesystem component. I don't know which is the best, but the decision will influence the design of the module system. -- OKUJI Yoshinori <[EMAIL PROTECTED]> ^o-o^ http://duff.kuicr.kyoto-u.ac.jp/~okuji (in English) m /
Re: GRUB executables
OKUJI Yoshinori <[EMAIL PROTECTED]> wrote: > > One of them would be generated by a modified isapnp from isapnp.conf > > I don't want to embed a bison parser into GRUB. It is much easier to > > generate i386 code that just writes to the ports. > > I agree. The disadvantage to this, if I'm understanding correctly, is that you couldn't modify it at boot-time. Maybe this is considered OK. Personally, I like the idea of having all config files editable at boot time as desired. > > Another executable could load Russian (or Japanese?) font. > > It is necessary because 99.9 % video cards sold in Russia don't have > > a Russian font in BIOS and the remaining 0.01% use CP-866 that is > > incompatible with Koi8-r used on Linux and *BSD. > > Probably we should discuss how to internationalize GRUB. I talked > with Erich about it a bit, but more discussion is definitely > necessary. But I think it will need to rewrite much of the code, so > the actual implementation should be done after 0.6. Agreed. I've looked at some of the encoding standards favored by native speakers of languages such as Japanese. I think Unicode ends up being brought up because to the uninitiated it's encoding is much simpler to deal with. I want to continue this discussion when those interested have time. > > By the way, can a Multiboot kernel just "return" to the bootloader? > > This would be the simplest solution. > > I think dynamic loading would be the best solution. I and Gordon are > planning to break the Stage 2 into multiple components and strip the ... > user should be a dynamic library object, because a dynamic object can > be located at arbitrary memory space while a static object must be > located at certain memory space. This funtionality will be necessary > if we have many, many modules. > > For now, however, I'm planning to implement the netboot module as if > it is just a kernel, just because this is easy. A simple dynamic linker isn't that hard to add (libc has an example, if nothing else). But I would favor the following approach: -- Generate PIC code. -- Have some kind of formal interface with the functions exported for Multiboot. This is simpler and allows any "Multiboot"-compliant loader to work with the modules. Q: Is there inter-dependencies between the modules that want to be resolved? (this is probably not a good idea, IMO) -- Erich Stefan Boleyn \_ <[EMAIL PROTECTED]> Mad but Happy Scientist \__http://www.uruk.org/ Motto: "I'll live forever or die trying"---
Re: GRUB executables
From: Pavel Roskin <[EMAIL PROTECTED]> Subject: GRUB executables Date: Fri, 22 Oct 1999 19:53:10 +0400 (EEST) > One of them would be generated by a modified isapnp from isapnp.conf > I don't want to embed a bison parser into GRUB. It is much easier to > generate i386 code that just writes to the ports. I agree. > Another executable could load Russian (or Japanese?) font. > It is necessary because 99.9 % video cards sold in Russia don't have > a Russian font in BIOS and the remaining 0.01% use CP-866 that is > incompatible with Koi8-r used on Linux and *BSD. Probably we should discuss how to internationalize GRUB. I talked with Erich about it a bit, but more discussion is definitely necessary. But I think it will need to rewrite much of the code, so the actual implementation should be done after 0.6. > By the way, can a Multiboot kernel just "return" to the bootloader? > This would be the simplest solution. I think dynamic loading would be the best solution. I and Gordon are planning to break the Stage 2 into multiple components and strip the user interface from the core component. So I called the core "GRUB kernel" and the rest "GRUB user". At the time, I proposed that a GRUB user should be just a Multiboot kernel, but now I propose that a GRUB user should be a dynamic library object, because a dynamic object can be located at arbitrary memory space while a static object must be located at certain memory space. This funtionality will be necessary if we have many, many modules. For now, however, I'm planning to implement the netboot module as if it is just a kernel, just because this is easy. -- OKUJI Yoshinori <[EMAIL PROTECTED]> ^o-o^ http://duff.kuicr.kyoto-u.ac.jp/~okuji (in English) m /
GRUB executables
Hello, OKUJI! > But please don't modify the netboot code any more, because I'm > planning to replace it with a ``netboot external module''. Currently > HISAZUMI Kenji <[EMAIL PROTECTED]> is working on it to implement it > with the Linux network drivers. That's very interesting. I was planning to add support for "GRUB executables" One of them would be generated by a modified isapnp from isapnp.conf I don't want to embed a bison parser into GRUB. It is much easier to generate i386 code that just writes to the ports. Another executable could load Russian (or Japanese?) font. It is necessary because 99.9 % video cards sold in Russia don't have a Russian font in BIOS and the remaining 0.01% use CP-866 that is incompatible with Koi8-r used on Linux and *BSD. I think I should stop until the format for "GRUB executables" is negotiated. By the way, can a Multiboot kernel just "return" to the bootloader? This would be the simplest solution. Pavel Roskin
