Re: [RFC] Platform information services

[Javier Martín]

El jue, 14-08-2008 a las 20:41 +0300, Vesa Jääskeläinen escribió:
> Javier Martín wrote:
> > 2008/8/14 Vesa Jääskeläinen <address@hidden>:
> >> Javier Martín wrote:
> >>> Hi there everybody,
> >>>
> >>> I'm opening the RFC because I want to add some kind of infrastructure to
> >>> retrieve the address of system/platform structures. I will explain
> >>> myself: my use case is in i386-pc and for the drivemap module, in which
> >>> a function installs a TSR int13h handler. This requires the function to
> >>> have access to two real mode structures, namely the BIOS Data Area,
> >>> which is based at 0040:0000h; and the Interrupt Vector Table, which
> >>> conventionally starts at 0 but that could have been placed elsewhere by
> >>> the use of the LIDT instruction.
> >> But it is designed to use linear address space for memory so no need to
> >> worry about it. I do not see any reason why there would be paging or
> >> non-linear memory mapping in GRUB 2 (i386-pcbios).
> > 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.
> 
> Still I do not that being changed on GRUB 2 (i386-pcbios). And basically
> generic module writers do not need to care, and if it is platform
> specific module then you can adapt to that platform if needed. Think it
> like device driver.
Device drivers are just the kind of example that I'm basing upon: the
part related to their hardware they manipulate as directly and
recklessly as the OS kernel allows them, but WRT other parts of the
system they rely on a very defined kernel-driver interface (NDIS,
anyone?) that simply is very nebulous in GRUB.

You say that paging will never be enabled in GRUB2, and it is very
likely that your assertion holds, but what if we suddenly find some kind
of benefit to enable it and some other rock to be walked around requires
that the first MB of memory not be identity mapped? Kaboom for modules
assuming it is: they were assuming things about the implementation of
the kernel that do _not_ have to hold as they are nowhere specified
> 
> >> Or did I miss something?
> >>
> >> So basically I do not see need for such services. As this does not even
> >> need to be platform independent.
> >>
> >> If you need to alter IVT you can modify it on the fly. Though you have
> >> to remember where to use only LOW mem addresses in there.
> > Not just low mem addresses, I need to compute the real mode far
> > pointer (seg:off). Besides, while the BDA always starts at 0040:0000,
> > the IVT could have been relocated by either the BIOS or GRUB itself,
> > so I need to use SIDT, which is not a privileged instruction itself
> > but requires a privileged drop to r-mode to get the IVT address
> > instead of the pmode IDT.
> 
> Last time I checked seg:off conversion was (seg << 4) | off giving
> access to 1 MiB of memory.
I meant that _if_ some kind of mapping was enabled, such conversion
would be non-trivial and possibly only known to the kernel.
> 
> BIOS will not relocate this as it is assumed in later stages to be on
> that address. And I do not see GRUB doing that as it would need to keep
> that table in same place as where BIOS has stored it.
All x86-32/64 BIOSes could perfectly relocate the IVT because they feel
like it, as the LIDT/SIDT operations were introduced with the 80286.
Most current OSes (Linux, Windows from the NT family, etc.) don't care
about the IVT just because they have no need of using it ever again,
start with a cli and jump into pmode as soon as they can. 
> 
> If you still prefer to query it on x86, then there is nothing there to
> limit you on doing that. You can always write code to low mem area to
> have a real mode call to query any addresses you wish. But I still do
> not see any reason why you would write heavy wrapper for that kind of
> information especially when those are really platform specific and are
> usually not shared between systems. Every platform should use familiar
> and convenient method do query that kind of information.
As I showed in my reply to Robert's message, the wrapper need not be
"heavy": most likely the opposite, as a "stub" implementation for
platforms not providing any structures is under 50 bytes, and the
"wrapper" for other platforms consists mainly of a switch-case.

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

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