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 > Grub-devel@gnu.org > 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
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
