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