Re: [RFC] Platform information services

[Vesa Jääskeläinen]

Javier Martín wrote:
>>> 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);
>> The better way that complies with all your error cases provided:
>>
>> grub_ivt_entry_t *entry;
>> entry = grub_get_ivt_entry(0x13);
>> *entry = new_value;
> This was another of the solutions I was considering in this thread (the
> "many-functions approach"), I just found the single-function solution
> more elegant in the case of "large numbers" (>10) of structures becoming
> visible through this method, but your snippet looks fine and "safer".

It is only visible within platform where it is used, so that is not a
problem. "Large number" of structures are still needed for that platform
(and if they are not needed, then there is no need for the function) and
that need cannot be discarded in anyway. Unless you want to use magic
numbers to define offsets...

So I would dismiss the idea and continue to use other methods.

>> of course grub_ivt_entry_t could be renamed to be something like
>> grub_realmode_addr_t.
> grub_realmode_farptr_t would suit better IMO.

Please be free to use that.