[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.
-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
- Re: [RFC] Platform information services, (continued)
- Re: [RFC] Platform information services, Javier Martín, 2008/08/14
- Re: [RFC] Platform information services, Robert Millan, 2008/08/14
- Re: [RFC] Platform information services, Javier Martín, 2008/08/14
- Re: [RFC] Platform information services, Vesa Jääskeläinen, 2008/08/15
- Re: [RFC] Platform information services, Javier Martín, 2008/08/15
- Re: [RFC] Platform information services, Vesa Jääskeläinen, 2008/08/15
- Re: [RFC] Platform information services, Javier Martín, 2008/08/15
- Re: [RFC] Platform information services, Vesa Jääskeläinen, 2008/08/15
- Re: [RFC] Platform information services, Javier Martín, 2008/08/15
- Re: [RFC] Platform information services, Vesa Jääskeläinen, 2008/08/15
- Re: [RFC] Platform information services,
Javier Martín <=
- Re: [RFC] Platform information services, Vesa Jääskeläinen, 2008/08/15
- Re: [RFC] Platform information services, Isaac Dupree, 2008/08/15
- Re: [RFC] Platform information services, Javier Martín, 2008/08/15
- Re: [RFC] Platform information services, Vesa Jääskeläinen, 2008/08/16
- Re: [RFC] Platform information services, Robert Millan, 2008/08/16