Re: vesafb terminal for testing.
On Tuesday 20 September 2005 01:11 am, Vesa Jääskeläinen wrote: Perhaps you mixed this with vbeinfo code itself? Because in grub_vbe_probe (in video/i386/pc/vbe.c) there has been grub_memcpy to copy this information from scratch to local static variable (controller_info) and then if caller provided non NULL pointer, it would also be copied to caller's variable. And as this information is now copied in static variable controller_info it can be used and cached for later usage. No. It copies only the *pointers* but not the data. That is a bit odd I might say. Do you have any more details about this problem? What exactly is wrong? Is there any way to reproduce this? I don't know. I hope he can comment on this. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: vesafb terminal for testing.
Yoshinori K. Okuji wrote: On Sunday 14 August 2005 16:48, Yoshinori K. Okuji wrote: On Sunday 14 August 2005 13:52, Vesa Jääskeläinen wrote: I have attached patch here that adds simple terminal that uses VESA BIOS Extension 2.0+ for rendering terminal. It is not meant to be included as is in GRUB 2, but I would hope that people would test it, so I could try to improve it for greater compatibility (even though I have tried to follow the standards, there might be some glitches between implementations). That's great. I will try once I finish my current task. So I tested it and fixed/modified many things. Sorry it took a bit longer to check those out, but after returning from my vacation it took some time to get back to normal day life. Most of the changes were good ones. I would like to know why did you add checking for reserved bit (D1) in grub2/commands/i386/pc/vbeinfo.c around line 88. There is some notes about this bit in standard (VBE 3.0, page 33, top of page) that tells that after VBE 1.2 this field has always contained value 1. In light of this I do not see need to verify for this? Also there was small semantic change in grub_vbe_probe, now if user provides info_block parameter, it will always call VESA BIOS to get information even though this would be cached in second run. I have no problem with this, but out of curiosity, was there some reason for this change? I changed the command names to vbeinfo and vbetest. More compatible with the traditional GRUB's naming scheme. Ok. Also, you needed to use GRUB's error handling. In GRUB 2, the error is not only a constant value, but also a message. So, whenever appropriate, you should use the function grub_error. (This is a big improvement from GRUB Legacy, really.) Thanks for informing me about that. Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: vesafb terminal for testing.
On Sunday 14 August 2005 16:48, Yoshinori K. Okuji wrote: On Sunday 14 August 2005 13:52, Vesa Jääskeläinen wrote: I have attached patch here that adds simple terminal that uses VESA BIOS Extension 2.0+ for rendering terminal. It is not meant to be included as is in GRUB 2, but I would hope that people would test it, so I could try to improve it for greater compatibility (even though I have tried to follow the standards, there might be some glitches between implementations). That's great. I will try once I finish my current task. So I tested it and fixed/modified many things. I changed the command names to vbeinfo and vbetest. More compatible with the traditional GRUB's naming scheme. There were issues about the coding style. For example, a function definition must not be like this: int foo(int x) but: int foo (int x) Note the space character. This is the same for casts. Also, you needed to use GRUB's error handling. In GRUB 2, the error is not only a constant value, but also a message. So, whenever appropriate, you should use the function grub_error. (This is a big improvement from GRUB Legacy, really.) Please compare the files after my changes with yours for more details. For now, I tested it only with qemu, and haven't tested the vesafb terminal yet. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: vesafb terminal for testing.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yoshinori K. Okuji wrote: A pluggable menu might sound good, but it's not so easy to maintain multiple menu interfaces. I think we should only maintain some kind of API interface with an example module, and let the community develop on it if it finds it interesting. like CSS in HTML. I like the CSS idea. From-menu edition of the CSS sound to me as a requirement, to avoid rebooting each time a change is made. It could be at first with read-only from device, and maybe a hard-copy print function. The HTML would be grub.cfg, but the CSS ? Another file ? In the same ? We might need to improve the grub.cfg format to handle something like css classes. Even if we don't implement class support in our graphic menu, I bet users will be happy to find it supported when writing their module. On the other hand, the worse is better rule would say that if the grub.cfg format is too bad, the users will write another that would best fit their needs. It might be good to separate menu definition from environment initialisation, in case the first gets redesigned they wouldn't have to care about the second. USB mouse support [...] Vesa On the IEEE1275 point of view, I saw framebuffer graphic primitives in the standard, so it *should* be easy too. And on my sun, there is a mouse device in the OB tree. Marco Gerards wrote: Right, but it would be the best if we think now and design the interfaces. Maybe should we design a test-case. I'm thinking of 2~3 buttons bouncing around the screen, with selection click events handled (including tab, return, space). That would test : - -drawing - -timer events (I think it's worth the implementation) and their regularity among different systems - -user interaction Vincent Pelletier -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDAYwDFEQoKRQyjtURAi83AJ99xcSmesFJL9zdC5jwiH+Pc8SiEACfeDyd 96z51HGlPugXg65G1aPhMoI= =6hcN -END PGP SIGNATURE- ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: vesafb terminal for testing.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco Gerards wrote: Perhaps we can get help and suggestions from designers instead of programmers. Perhaps we can contact Ubuntu, they have designers. Perhaps a KDE or gnome team? Gnoppix has a really nice - Grub legacy - graphic menu, so I think it is a good idea to contact Ubuntu. Vincent Pelletier -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDAY2zFEQoKRQyjtURAks9AKCShtAFEucHj+7pmRgGfWovid18DgCgojWL okb6IjD7sSMqdf2vMI5s2Rc= =13m2 -END PGP SIGNATURE- ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: vesafb terminal for testing.
Vincent Pelletier [EMAIL PROTECTED] writes: On the IEEE1275 point of view, I saw framebuffer graphic primitives in the standard, so it *should* be easy too. And on my sun, there is a mouse device in the OB tree. Right, same for EFI. Marco Gerards wrote: Right, but it would be the best if we think now and design the interfaces. Maybe should we design a test-case. I'm thinking of 2~3 buttons bouncing around the screen, with selection click events handled (including tab, return, space). That would test : -drawing -timer events (I think it's worth the implementation) and their regularity among different systems -user interaction It would be nice to have something to test the fb drivers with. Thanks, Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: vesafb terminal for testing.
Marco Gerards wrote: Just a note until admins fix those commit messages, first version of vbe terminal support is now committed. It still needs more work, but it is a starting point. Cool! If you do receive the commit messages, can you forward them so we could see them as well? I did the formatting changes and committed them. I will reformat those error messages I received and resent them to commit-grub mailing list. Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: vesafb terminal for testing.
On Monday 15 August 2005 17:52, Vesa Jääskeläinen wrote: Now only problem is what is the best location for vbe.c that would contain helper functions for modules that needs VBE. Currently I have it in term/i386/pc/vbe.c but is there better location for this? It would be better to create a new directory. video/i386/pc/vbe.c? And is GRUB_MOD_INIT and GRUB_MOD_FINI mandory as I do not have need for those in this module? Seems to work without them. No. If you don't need to use them, you do not need to define them. Is the file include/grub/i386/pc/vbe.h correct place to put function prototypes? Yes. Is directory commands/i386/pc/ correct place for commands vbe_list_modes and vbe_test? Yes. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: vesafb terminal for testing.
Yoshinori K. Okuji [EMAIL PROTECTED] writes: On Monday 15 August 2005 18:06, Vladimir Serbinenko wrote: We don't need to make the whole thing absolutely skinnable (just the basic skins) if we make like I proposed (menus like terminals, in modules) because if someone wants to change completely the look he can just write a new menu module. A pluggable menu might sound good, but it's not so easy to maintain multiple menu interfaces. Ideally, we want to have a single implementation which accepts many parameters. I think it would end up with a kind of stylesheet like CSS in HTML. It would be nice if GUI's can be distributed as plugins... Isn't XML often used to describe interfaces? Perhaps we can use a structured form of storing data like XML... But that is just a random thought. :-) -mouse handling (??) It must not be difficult: we can just port mouse.com from FreeDos or use any other mouse implementation. It is actually difficult, because USB mouse support requires interferences with other USB devices. Most modern BIOSes support USB legacy interfaces, such as USB disks and keyboards. It is not easy not to affect them. It's not easy on the PC. But AFAIK it should be easy with EFI and IEEE 1275, but I have not taken a close look yet. Now the most important questions is how to make the *general/basic* things to ensure the maximum flexibility in the future as Yoshinori K. Okuji said in about 6 months we have to block them: don't change them anymore. Don't take my argument too strictly. It can be in 6 months, in 3 months or in 12 months. In principle, I do not want to feature-freeze GRUB 2 until we are satisfied enough with the design. This opportunity -- redesigning everything -- is really hard to obtain. Note that I had to wait for 3 years to start GRUB 2. So I wouldn't stop thinking how to improve GRUB very soon. Right. Also, as long as changes do not affect compatibility, we can add more features later. Indeed, I have implemented a number of new features even in GRUB Legacy without losing any bit of compatibility (Do you know that 0.97 is completely backward-compatible with 0.4?). It was quite hard sometimes but feasible. Right, but it would be the best if we think now and design the interfaces. We don't need to implement it all and it does not have to be perfect, it is important to have a good foundation we can build on. Anyway, I expect that we will not have to wait too long to see what we want to do with a fancy menu, since Vesa is very fast to implement the code. Hopefully, we will see the first working version in this month or next month. Once it starts working, the discussion will be much easier. Agreed. Thanks, Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: vesafb terminal for testing.
On Monday 15 August 2005 19:41, Marco Gerards wrote: It would be nice if GUI's can be distributed as plugins... Maybe. This kind of change is easy to make later, so I'd like to stick to a hardcoded menu interface for now. First of all, I must make it perfectly working with internationalized text. Isn't XML often used to describe interfaces? Perhaps we can use a structured form of storing data like XML... But that is just a random thought. :-) No XML, please! XML is a holy sh*t. Do you know how many pages you must read to understand it completely? XML is widely used only because it is a standard, so many utilities are provided. XML is bloated, ugly, and space-inefficient. It would be interesting to think why CSS2 is not based on XML, even though nearly all technologies related to WWW are based on XML nowadays. The designer of CSS2 must be a sane person. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: vesafb terminal for testing.
Yoshinori K. Okuji wrote: Anyway, I expect that we will not have to wait too long to see what we want to do with a fancy menu, since Vesa is very fast to implement the code. Hopefully, we will see the first working version in this month or next month. Once it starts working, the discussion will be much easier. Actually, on beginning of the next week I am going for two week vacation so it doesn't get so quickly done, but we'll see :) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
vesafb terminal for testing.
Hi,
I have attached patch here that adds simple terminal that uses VESA BIOS
Extension 2.0+ for rendering terminal. It is not meant to be included as
is in GRUB 2, but I would hope that people would test it, so I could try
to improve it for greater compatibility (even though I have tried to
follow the standards, there might be some glitches between implementations).
This terminal driver is based on vga terminal module and contains some
common code from there, though many parts has been rewritten. When
testing this patch, make sure that you have latest CVS version of GRUB 2.
There are couple of things that I do not like in this patch.
First one is that there should be common virtual terminal for all arch's
and then separate graphics drivers that will do the actual drawing. In
this patch this is all implemented in one module and it is not as pretty
as it could be.
Second one is that this patch uses VGA BIOS fonts to draw characters and
it might cause some problems in some cards.
Third one is that there are some testing functionality (vbe_test,
vbe_list_modes) in same module, what would be best place to move those?
Now how to get started on testing:
- insmod vesafb
- Use vbe_list_modes to find mode number (eg. 0x111) that you want to use.
- set vbe_mode varible ('set vbe_mode=0x111')
To test mode:
- vbe_test
To use it in terminal:
- insmod terminal
- terminal vesafb
Thanks,
Vesa Jääskeläinen
Index: ChangeLog
===
RCS file: /cvsroot/grub/grub2/ChangeLog,v
retrieving revision 1.149
diff -u -r1.149 ChangeLog
--- ChangeLog 14 Aug 2005 11:04:12 - 1.149
+++ ChangeLog 14 Aug 2005 11:31:51 -
@@ -1,5 +1,13 @@
2005-08-14 Vesa Jaaskelainen [EMAIL PROTECTED]
+ * DISTLIST: Added term/i386/pc/vesafb.c
+ * term/i386/pc/vesafb: New file.
+ * conf/i386-pc.rmk (pkgdata_MODULES): Added vesafb.mod.
+ (vesafb_mod_SOURCES): Added.
+ (vesafb_mod_CFLAGS): Likewise.
+
+2005-08-14 Vesa Jaaskelainen [EMAIL PROTECTED]
+
* DISTLIST: Added include/grub/i386/pc/vbe.h.
2005-08-13 Yoshinori K. Okuji [EMAIL PROTECTED]
Index: DISTLIST
===
RCS file: /cvsroot/grub/grub2/DISTLIST,v
retrieving revision 1.9
diff -u -r1.9 DISTLIST
--- DISTLIST14 Aug 2005 11:04:12 - 1.9
+++ DISTLIST14 Aug 2005 11:31:51 -
@@ -163,6 +163,7 @@
partmap/pc.c
partmap/sun.c
term/i386/pc/console.c
+term/i386/pc/vesafb.c
term/i386/pc/vga.c
term/ieee1275/ofconsole.c
util/i386/pc/biosdisk.c
Index: conf/i386-pc.rmk
===
RCS file: /cvsroot/grub/grub2/conf/i386-pc.rmk,v
retrieving revision 1.39
diff -u -r1.39 i386-pc.rmk
--- conf/i386-pc.rmk12 Aug 2005 19:53:32 - 1.39
+++ conf/i386-pc.rmk14 Aug 2005 11:31:56 -
@@ -111,7 +111,7 @@
font.mod _multiboot.mod ls.mod boot.mod cmp.mod cat.mod \
terminal.mod fshelp.mod chain.mod multiboot.mod amiga.mod \
apple.mod pc.mod sun.mod loopback.mod reboot.mod halt.mod \
- help.mod default.mod timeout.mod configfile.mod
+ help.mod default.mod timeout.mod configfile.mod vesafb.mod
# For _chain.mod.
_chain_mod_SOURCES = loader/i386/pc/chainloader.c
@@ -251,3 +251,7 @@
# For configfile.mod
configfile_mod_SOURCES = commands/configfile.c
configfile_mod_CFLAGS = $(COMMON_CFLAGS)
+
+# For vesafb.mod.
+vesafb_mod_SOURCES = term/i386/pc/vesafb.c
+vesafb_mod_CFLAGS = $(COMMON_CFLAGS)
Index: term/i386/pc/vesafb.c
===
RCS file: term/i386/pc/vesafb.c
diff -N term/i386/pc/vesafb.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ term/i386/pc/vesafb.c 14 Aug 2005 11:31:56 -
@@ -0,0 +1,1169 @@
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2005 Free Software Foundation, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include grub/machine/memory.h
+#include grub/machine/vga.h
+#include grub/machine/vbe.h
+#include grub/machine/console.h
+#include grub/term.h
+#include grub/types.h
+#include grub/dl.h
+#include grub/misc.h
+#include grub/normal.h
+#include grub/font.h
+#include grub/arg.h
+#include grub/mm.h
+#include grub/env.h
Re: vesafb terminal for testing.
On Sunday 14 August 2005 13:52, Vesa Jääskeläinen wrote:
I have attached patch here that adds simple terminal that uses VESA BIOS
Extension 2.0+ for rendering terminal. It is not meant to be included as
is in GRUB 2, but I would hope that people would test it, so I could try
to improve it for greater compatibility (even though I have tried to
follow the standards, there might be some glitches between
implementations).
That's great. I will try once I finish my current task.
First one is that there should be common virtual terminal for all arch's
and then separate graphics drivers that will do the actual drawing. In
this patch this is all implemented in one module and it is not as pretty
as it could be.
Another way is to emulate VBE on other architectures... Actually, some
firmware (such as CFE) follows this way (e.g. CFE emulates PC's VGA BIOS).
Second one is that this patch uses VGA BIOS fonts to draw characters and
it might cause some problems in some cards.
You should use the font manager to render characters, like the VGA terminal.
Getting fonts from the BIOS is the last resort.
Third one is that there are some testing functionality (vbe_test,
vbe_list_modes) in same module, what would be best place to move those?
I think they should be in the directory commands. These may be useful even
when the user does not use a framebuffer terminal, because Multiboot
Specification also requires VBE support.
Now how to get started on testing:
- insmod vesafb
- Use vbe_list_modes to find mode number (eg. 0x111) that you want to use.
- set vbe_mode varible ('set vbe_mode=0x111')
To test mode:
- vbe_test
To use it in terminal:
- insmod terminal
- terminal vesafb
Thank you for your description. Can we have your code in the CVS? It's easier
to test, once it is merged, because we do not have to care about conflicts.
Okuji
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: vesafb terminal for testing.
Yoshinori K. Okuji wrote:
First one is that there should be common virtual terminal for all arch's
and then separate graphics drivers that will do the actual drawing. In
this patch this is all implemented in one module and it is not as pretty
as it could be.
Another way is to emulate VBE on other architectures... Actually, some
firmware (such as CFE) follows this way (e.g. CFE emulates PC's VGA BIOS).
I think that we still need to make modifications to interfaces, so we
have easy to use functions for visual effects, like different blitting
operators. If these interface functions are good enough, there should
not be any need to emulate anything. Of course one can use VBE video
driver as basis for other video drivers.
I can try to draft out features that I think is needed and then we can
see what is still missing and when it is good enough then implement it.
Second one is that this patch uses VGA BIOS fonts to draw characters and
it might cause some problems in some cards.
You should use the font manager to render characters, like the VGA terminal.
Getting fonts from the BIOS is the last resort.
It's identical on that aspect to VGA module. But VBE 3.0 standard allows
to have modes without text output support, so this could indicate that
font's are not available in ROM for every implementation. Even though we
are using our own drawing functions there might be some cases where that
font data is invalid.
VGA module uses Unicode values above 128 from font manager and below
that it uses BIOS fonts. If our font manager provides always USASCII
fonts, then we might drop whole VGA font support.
Third one is that there are some testing functionality (vbe_test,
vbe_list_modes) in same module, what would be best place to move those?
I think they should be in the directory commands. These may be useful even
when the user does not use a framebuffer terminal, because Multiboot
Specification also requires VBE support.
Hmm... For me this indeed looks like that there has to be different vbe
module to be loaded that provides auto probing of controller data.
Perhaps some of this should even reside in the kernel for the i386?
What do you think if I create kern/i386/pc/vbe.c that contains following
from the patch:
// functions
grub_vbe_probe
grub_vbe_set_mode
grub_vbe_get_mode
grub_vbe_get_mode_info
// global variables
struct grub_vbe_info_block grub_vbe_controller_info;
struct grub_vbe_mode_info_block grub_vbe_active_mode_info;
And perhaps some others if there is a need.
Rest of the functionality could probably should be in terminal or to
separate video driver.
Now how to get started on testing:
- insmod vesafb
- Use vbe_list_modes to find mode number (eg. 0x111) that you want to use.
- set vbe_mode varible ('set vbe_mode=0x111')
To test mode:
- vbe_test
To use it in terminal:
- insmod terminal
- terminal vesafb
Thank you for your description. Can we have your code in the CVS? It's easier
to test, once it is merged, because we do not have to care about conflicts.
Once those couple of changes are done, I can commit it to CVS.
Thanks,
Vesa Jääskeläinen
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: vesafb terminal for testing.
Vladimir Serbinenko wrote: Vesa Jääskeläinen wrote: I can try to draft out features that I think is needed and then we can see what is still missing and when it is good enough then implement it. But we need to let the room for the future growth. One of far-looking plans is eye-candy menu interface and we don't know yet what we will put there. Perhaps someone likes to have all features Okuji wrote in his message... But my idea was to make list of generic operators that will be needed on most cases. Basic operations has been quite stable for many years. Only thing new is that there are hardware acceleration for some of them. If something tradically different comes up, then we have to think again. But let's see what I come up. Then if somebody wants to implement icon-based menu (icon+label for each menu entry, choosing with mouse and so on) he should be able to do so without changing the video interface function. Perhaps we should make abstract drawing interface? If so IMHO we should take one of existing drawing interfaces like the base (but of course it's not necessary to implement all features of the base interfaces, just the basic ones) Absolutely, I was thinking about generic interface. It will make it much easier and less bug prone as everything is done using generic interface. It eases porting to other systems too. Remember that you have to separate behavior of the menu from the graphics driver. Menu can be changed anyway implementors sees best fit, but the graphics driver doesn't change that much (or at least it shouldn't). // functions grub_vbe_probe grub_vbe_set_mode grub_vbe_get_mode grub_vbe_get_mode_info // global variables struct grub_vbe_info_block grub_vbe_controller_info; struct grub_vbe_mode_info_block grub_vbe_active_mode_info; And perhaps some others if there is a need. I'm very opposite because it's not critical for booting and it will take place and place in kernel is critical (at least for i386). It could be separate modules (e.g. vesafb and vesainfo) but it must be a module. If multiboot needs it. It can just reference it like a dependency Perhaps. Currently there is some thunks that call real mode VBE functions in kernel. And those functions I listed are more easier to use interfaces for some of those functions. As far I know, GRUB 2 doesn't support dynamic loading of function entry points, instead there are only two predefined entry points that can be called from modules so there has to be some interface for those if they are not implemented in kernel level. And it would be bad to duplicate that code in several places. I see four options here: 1) design graphics drivers interface and register it when loading module. Pros is that it is easy to write new graphics drivers. Cons is that we need to have then virtual screen support (not hard to make). 2) improve terminal interface. Cons for this are that terminal interface can grow quite large and not all functions are relevant to terminal. 3) implement some generic code in kernel level. Pros is that it is easier to interface with it. Cons are that kernel size increases. 4) design some helper function interface that could be used to make dynamic function calls to module code. Cons are 'What happens then when module is unloaded?'. Perhaps there are other options ? Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: vesafb terminal for testing.
On Sunday 14 August 2005 23:48, Vesa Jääskeläinen wrote: As far I know, GRUB 2 doesn't support dynamic loading of function entry points, instead there are only two predefined entry points that can be called from modules so there has to be some interface for those if they are not implemented in kernel level. And it would be bad to duplicate that code in several places. Nope. GRUB 2 supports real dynamic loading. Entry points are used only when we want to allow symbols to be missing. So you need to implement code in the kernel only if it requires real mode or it is a critical function. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
