Re: [RFC] Platform information services

[Vesa Jääskeläinen]

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.

>> 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.

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.

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.