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