Hi, I thought of an idea that enables GRUB to use a large memory area. :-) Until now, we have been thinking that the available memory size for GRUB is restricted to at most 640KB and GRUB cannot use upper memory region (>1MB) for itself. But that is a mistake! Consider why GRUB cannot use upper memory region. That is because kernels or modules that GRUB will load will occupy the region. However, if GRUB doesn't load them immediately after the `kernel' command or the `module' command and delays the loading until actual boot process, then what happens? Yeah, GRUB CAN use the region for itself. I call this methods ``lazy-loading''. If we implement lazy-loading, we may use some MB for GRUB, the exact size depends on how much memory the user has, but we may expect at least 4MB, which is the minimum size that Linux can boot. That means that it's realistic to have a real scripting language, such as Pliant that Gordon suggested. Of course, there are some limitations. In real mode, GRUB cannot access upper memory. We must take care when using BIOS calls. Futhermore, all data in the upper region will be broken when loading a kernel actually. So we must make sure that data that must not be broken during boot exists in lower region or is copied into the region before boot. However, these problems can be avoidable by using well-defined, simple memory management service. For example, the interface will be like this: /* These are used for objects that may be broken. */ void *grub_malloc (size_t size); void grub_free (void *ptr); /* These are used for objects that must not be broken. */ void *grub_malloc_critical (size_t size); void grub_free_critical (void *ptr); #define grub_malloc_for_real_mode(s) grub_malloc_critical(s) #define grub_free_for_real_mode(s) grub_free_critical(s) Thanks for reading my long message, OKUJI ---------------------------------------------------------------------- OKUJI Yoshinori <[EMAIL PROTECTED]> ^o-o^ http://duff.kuicr.kyoto-u.ac.jp/~okuji (in English) m /
