From: "Javier Martín" <lordhabbit@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [RFC] Platform information services
Date: Fri, 15 Aug 2008 22:13:01 +0200 [thread overview]
Message-ID: <1218831181.2510.56.camel@localhost> (raw)
In-Reply-To: <48A5DD13.5050903@nic.fi>
[-- Attachment #1: Type: text/plain, Size: 2919 bytes --]
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
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
next prev parent reply other threads:[~2008-08-15 20:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-14 3:36 [RFC] Platform information services Javier Martín
2008-08-14 16:09 ` Vesa Jääskeläinen
2008-08-14 16:38 ` Javier Martín
2008-08-14 17:41 ` Vesa Jääskeläinen
2008-08-14 21:45 ` Javier Martín
2008-08-14 18:00 ` Robert Millan
2008-08-14 21:29 ` Javier Martín
2008-08-15 16:31 ` Vesa Jääskeläinen
2008-08-15 17:03 ` Javier Martín
2008-08-15 17:14 ` Vesa Jääskeläinen
2008-08-15 17:59 ` Javier Martín
2008-08-15 18:35 ` Vesa Jääskeläinen
2008-08-15 19:18 ` Javier Martín
2008-08-15 19:46 ` Vesa Jääskeläinen
2008-08-15 20:13 ` Javier Martín [this message]
2008-08-15 20:26 ` Vesa Jääskeläinen
2008-08-15 22:38 ` Isaac Dupree
2008-08-15 23:06 ` Javier Martín
2008-08-16 7:03 ` Vesa Jääskeläinen
2008-08-16 12:20 ` Robert Millan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1218831181.2510.56.camel@localhost \
--to=lordhabbit@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.