[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Platform information services
From: |
Javier Martín |
Subject: |
Re: [RFC] Platform information services |
Date: |
Thu, 14 Aug 2008 23:29:22 +0200 |
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
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
- [RFC] Platform information services, Javier Martín, 2008/08/13
- Re: [RFC] Platform information services, Vesa Jääskeläinen, 2008/08/14
- Re: [RFC] Platform information services, Javier Martín, 2008/08/14
- Re: [RFC] Platform information services, Robert Millan, 2008/08/14
- Re: [RFC] Platform information services,
Javier Martín <=
- Re: [RFC] Platform information services, Vesa Jääskeläinen, 2008/08/15
- Re: [RFC] Platform information services, Javier Martín, 2008/08/15
- Re: [RFC] Platform information services, Vesa Jääskeläinen, 2008/08/15
- Re: [RFC] Platform information services, Javier Martín, 2008/08/15
- Re: [RFC] Platform information services, Vesa Jääskeläinen, 2008/08/15
- Re: [RFC] Platform information services, Javier Martín, 2008/08/15
- Re: [RFC] Platform information services, Vesa Jääskeläinen, 2008/08/15
- Re: [RFC] Platform information services, Javier Martín, 2008/08/15
- Re: [RFC] Platform information services, Vesa Jääskeläinen, 2008/08/15
- Re: [RFC] Platform information services, Isaac Dupree, 2008/08/15