From: "Vesa Jääskeläinen" <chaac@nic.fi>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [RFC] Platform information services
Date: Fri, 15 Aug 2008 19:31:12 +0300 [thread overview]
Message-ID: <48A5AF50.2040906@nic.fi> (raw)
In-Reply-To: <1218749362.19647.20.camel@localhost>
Javier Martín wrote:
> WRT "kernel and modules going hand by hand", think about external
> modules: if the drivemap module is finally rejected for introduction in
> GRUB, I will not scrap it, but keep it as a module external to the
> official GNU sources and possibly offer it in a web in the form of
> patches to the official GRUB2. In this case, changes made to the kernel
> would not take into account that module, which would break if I weren't
> monitoring this list daily.
Then it is really your problem ;)
> Additionally, the cost of this function in platforms which don't have
> any structs registered yet, as the function could be a stub like this:
>
> void* grub_machine_get_platform_structure (int stidx)
> {
> grub_error (GRUB_ERR_BAD_ARGUMENT, "Struct %d not supported", stidx);
> return 0;
> }
>
> The kernel space taken would most likely be less than 50 bytes. For
> i386-pc, it could be like this (also lightweight) function:
>
> void* grub_machine_get_platform_structure (int stidx)
> {
> grub_errno = GRUB_ERR_NONE;
>
> switch (stidx)
> {
> case GRUB_MACHINE_I386_IVT:
> return /* Call to asm function that runs SIDT in real mode */ ;
> case GRUB_MACHINE_I386_BDA:
> return (void*)0x400;
> default:
> grub_error (GRUB_ERR_BAD_ARGUMENT, "Struct %d not supported",
> stidx);
> return 0;
> }
> }
And what lets assume couple of extra platforms... how about
x86-32bit-efi and ppc. What do they do?
Implement their own enum entries for those indexes and only use their
own indices...?
Where here we are sharing any code? (if we do not count the name of the
fuction.) Interface is kinda useless if there is no possibility that
no-one is sharing its functionality...
next prev parent reply other threads:[~2008-08-15 16:31 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 [this message]
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
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=48A5AF50.2040906@nic.fi \
--to=chaac@nic.fi \
--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.