[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Platform information services

From: Javier Martín
Subject: Re: [RFC] Platform information services
Date: Fri, 15 Aug 2008 22:13:01 +0200

El vie, 15-08-2008 a las 22:46 +0300, Vesa Jääskeläinen escribió:
> Javier Martín wrote:
> > I take that by "convenient to use" and your earlier "code safety"
> > reference, you imply a function that returns a typed pointer to the
> > structure, like "bda* var = grub_getbda();" in i386-pc, so that fields
> > of such struct can be directly accessed by var->free_mem_kb.
> > 
> > However, this requires that a function is created for each firmware
> > structure that is deemed interesting by GRUB developers. In this
> > proposal, only one (very lightweight) function is created and then IDs
> > are defined for the structs. WRT "code safety", malloc and friends also
> > return a void* that you have to cast, so nothing new under the sky.
> In your case there is really no change.
> You create new switch branch (which is most likely implemented by
> function somewhere).
> In order to access this void * you have to know its contents. Why not
> use structure to define its contents where viable?
True, I just wanted to avoid defining structures that would only be used
once or twice, but you're right.
> When using malloc() you know that memory returned is not formatted in
> anyway. Therefore it is safe to cast.
> You just want to make it more complex that it needs to be in my eyes.
> >> You have still not provided a single GOOD example where this would be
> >> used AND would provide some ADDED VALUE. Unless you provide a convincing
> >> one (while I pretty much doubt) I do not see this feature to be in our
> >> official tree.
> > 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".

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

> .
> _______________________________________________
> Grub-devel mailing list
> address@hidden

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]