Re: [RFC] Platform information services

["Javier Martín" <lordhabbit@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2990 bytes --]

El jue, 14-08-2008 a las 20:00 +0200, Robert Millan escribió:
> On Thu, Aug 14, 2008 at 06:38:41PM +0200, Javier Martín wrote:
> > Yes, but this is a "kernel" design decision that is specified nowhere
> > to the modules writers. Thus, this could change tomorrow and the
> > scheme would break down.
> 
> GRUB is being developed as a whole, which includes kernel and modules.  If
> we modify the kernel in a way that could break modules, it's part of the
> procedure to check modules and make sure they don't break because of this
> (although, of course, we could always make mistakes).
> 

That is a very sane policy, but in this case I'm arguing that an
improvement could be made so that such process would not be necessary,
or would be much lighter, regarding a particular section of the kernel
because modules would not rely on certain assumptions about the internal
implementation of GRUB: separation of interface and implementation.
However, there is not a consistent, fully-documented kernel-module
interface, and module developers usually do not know what invariants
hold in their environment - they find it by trial and error. This needs
to change eventually, particularly in the documentation part (please
avoid GRUB ending like ALSA): the GRUBInternals page in the wiki should
be filled up and updated a bit more often.

WRT "kernel and modules going hand by hand", think about external
modules: if the drivemap module is finally rejected for introduction in
GRUB, I will not scrap it, but keep it as a module external to the
official GNU sources and possibly offer it in a web in the form of
patches to the official GRUB2. In this case, changes made to the kernel
would not take into account that module, which would break if I weren't
monitoring this list daily.

Additionally, the cost of this function in platforms which don't have
any structs registered yet, as the function could be a stub like this:

void* grub_machine_get_platform_structure (int stidx)
{
  grub_error (GRUB_ERR_BAD_ARGUMENT, "Struct %d not supported", stidx);
  return 0;
}

The kernel space taken would most likely be less than 50 bytes. For
i386-pc, it could be like this (also lightweight) function:

void* grub_machine_get_platform_structure (int stidx)
{
  grub_errno = GRUB_ERR_NONE;

  switch (stidx)
  {
  case GRUB_MACHINE_I386_IVT:
    return /* Call to asm function that runs SIDT in real mode */ ;
  case GRUB_MACHINE_I386_BDA:
    return (void*)0x400;
  default:
    grub_error (GRUB_ERR_BAD_ARGUMENT, "Struct %d not supported",
                stidx);
    return 0;
  }
}

BTW, I've noticed that when using the function, if the result is stored
in "void* p", then the success check cannot only rely on "if (p)",
because 0 is also a legal address (i.e. for the IVT). Thus, the checks
should be like "if (p || grub_errno == GRUB_ERR_NONE)" with the
implementation ensuring that errno is correctly set on success.

-Habbit

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]