Re: [RFC] Platform information services

[Javier Martín]

El vie, 15-08-2008 a las 18:38 -0400, Isaac Dupree escribió:
> my view of the "interface breakage" problem in this project:
> 
> Either the property of the kernel you're relying on is going 
> to change, or it isn't; it doesn't/shouldn't have stable 
> APIs, and it will change only if there's a reason for it to 
> change.  So I think the best we can do is to document what 
> code relies on what properties of the kernel.  Wherever's 
> appropriate and will likely be noticed and kept up-to-date. 
> for example:
> 
> if you rely on a property of the kernel, you should document 
> it somewhere in the kernel, and document everyone 
> (hopefully) who relies on that property; or the users could 
> have some symbol in the source that you can search for.  It 
> doesn't have to be a function that takes up any actual 
> kernel disk-space.
> 
> a bit at a distance,
> -Isaac
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel

The problem is exactly that: for the sake of modularity we are writing
module code that requires the manipulation of firmware-provided
structures, but we are relying on kernel implementation details that are
nowhere specified in the kernel-module interfaces like "the GRUB kernel
will not activate any kind of paging and in any event the 0-1M+64K
memory region will always be identity-mapped". Even when some parts
_might_ be documented in the wiki (like the MemoryMap page), other parts
of the wiki are so outdated and wrong that one cannot trust the good
pages! Besides, does the info in MemoryMap describe the layout of the
physical address space or the linear address space that modules see? etc

Thus, either we create interfaces in the kernel to deal with the
possible breakage of these assumptions (i.e. the platform info
function<s> we've been discussing in this thread would take care of
translating addresses across any memory mappings) or we set those
assumptions in stone and turn them into part of the kernel-module
interface, _documenting them_. Seriously, InteralsIntro et al. need a
lot more love...

-Habbit

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