grub-devel
[Top][All Lists]
Advanced

[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: Fri, 15 Aug 2008 21:18:14 +0200

El vie, 15-08-2008 a las 21:35 +0300, Vesa Jääskeläinen escribió:
> Javier Martín wrote:
> >> I still do not see the need to create cross platform function that
> >> cannot be used for cross platform purposes. It is much more reasonable
> >> to write such needs as in kernel for the platform or in platform
> >> specific modules.
> >>
> >> I do not have a problem with function to retrieve pointer to some
> >> platform specific function on platfrom specific code. That is normal
> >> life of the platform.
> > Well, think of this as a platform-specific function to retrieve the
> > address of platform-specific (firmware-provided) structures. The only
> > difference is that in my proposal such a function has the same signature
> > (prototype) for every platform.
> 
> Well... THEN WHY NOT MAKE A PLATFORM SPECIFIC FUCTION THAT IS CONVENIENT
> TO USE ON PLATFORM WHERE IT IS MEANT TO BE USED FOR AND IT ACTUALLY HAVE
> A MEANING ON WHERE IT IS ACCESSIBLE.
I take that by "convenient to use" and your earlier "code safety"
reference, you imply a function that returns a typed pointer to the
structure, like "bda* var = grub_getbda();" in i386-pc, so that fields
of such struct can be directly accessed by var->free_mem_kb.

However, this requires that a function is created for each firmware
structure that is deemed interesting by GRUB developers. In this
proposal, only one (very lightweight) function is created and then IDs
are defined for the structs. WRT "code safety", malloc and friends also
return a void* that you have to cast, so nothing new under the sky.

> 
> If you want to learn something, study interfaces of disk->biosdisk->bios
> and video->vbe->video bios... There are also several other good spots on
> GRUB 2 code base that you could see...
Will do, particularly the biosdisk part (video code nearly always makes
my head spin).

> 
> You have still not provided a single GOOD example where this would be
> used AND would provide some ADDED VALUE. Unless you provide a convincing
> one (while I pretty much doubt) I do not see this feature to be in our
> official tree.
The added value (that expression reminds me of taxes) is:
 -Compared to SVN HEAD: a way to retrieve the _module-accessible_
address of firmware-provided structures. This is a protection against
future changes in the GRUB kernel (like enabling paging, changing memory
mapping schemes, etc.) that would otherwise force to inspect every
single module for accesses to such structures by their "real" addresses.
 -Compared to SVN HEAD plus the many ad-hoc functions you seem to
support: for most of the structures an asm helper is not required, thus
less kernel space overhead than with many functions. Also, "focus of
efforts" - maybe the oversight on "the" core function would add
additional bitrot protection compared to the individuals functions.

An use case would be in the proposed drivemap module, in the function
installing an interrupt handler in the real-mode IVT: instead of the
current code with magic addresses,

/* Real mode IVT slot (seg:off far pointer) for interrupt 0x13.  */
grub_uint32_t *ivtslot = (grub_uint32_t*)0x0000004c;

The module could be like this:

/* Real mode IVT slot (seg:off far pointer) for interrupt 0x13.  */
grub_uint32_t *ivtslot = 19 +
(grub_uint32_t*)grub_machine_get_fwstruct(GRUB_I386_PC_IVT);

Then, if anything of the following ever happens:

   * The real mode IVT was live-relocated, either by GRUB or by the
BIOS, by the use of LIDT
   * The real mode IVT was destroyed by GRUB, which keeps a copy at
another address and sets it up, with the rest of a 8086-compatible
environment only when it is required (memory pressure maybe?).
   * Linear addresses 0-1M do not correspond with physical addresses
0-1M because of whatever memory management the GRUB kernel is doing

The above code would continue to work, while the even-more-above code
would fail with unpredictable results.

-Habbit
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel

Attachment: signature.asc
Description: Esta parte del mensaje está firmada digitalmente


reply via email to

[Prev in Thread] Current Thread [Next in Thread]