absence notice...
Hi All,
I will be absence from the project related work for a while... So please
feel free to continue or replace the work that I may have got pending.
Some tasks that could be done:
- Video API: save/restore mode. Use anonymous data structure that only
device driver itself understands. Having one common block that video
subsystem understands and can choose proper video driver. Idea is to
save mode and then execute something in different mode (Eg. test
videomode) and then restore back to working one if it does not work.
struct
{
// common part
char *driver_name/id;
// driver specific data
char driver_specific[0];
};
- MM: improve allocation strategy to allocate from start or end of area.
Add more memory areas to MM. Needed at least on x86 with Real Mode
possibility (eg. PCBIOS in use). Need to have difference between lowmem
( 1MiB) vs. highmem. GRUB normal code/data should go to highmem. BIOS
access data need to go to lowmem. OS kernel code probably should be
loaded at begining on highmem.
Colin: Please feel free to integrate graphical menu change without my
approval. If you feel unsure, please ask in mailing list.
Can't remember anything else for this occasion what important would have
been under the work.
I might read this mailing list occasionally, but don't be suppriced if I
do not notice questions addressed to me.
Thanks,
Vesa Jääskeläinen
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: absence notice...
Vladimir 'phcoder' Serbinenko wrote: I will do this. I know you already had some work for mm underway that's why I wasn't doing it. Could you send what you already have even if it's far from complete? Sorry. Everything got lost on laptop. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Framebuffer/vbe separation
Vladimir Serbinenko wrote: Hello, currently vbe module contains all the framebuffer functions which are actually adapter-independent and I think more adapters can be implementing by providing a function which sets mode and framebuffer. Additionally it provides an interface to retrieve framebuffer address for loaders: check that current mode is framebuffer based and if it is, take the address. May I do it that way? Yes. I have nothing against making frame buffer code as common code as possible because other systems would also benefit from it. Just keep in mind that other video drivers will also need to use it and do not call directly VBE driver itself, provide proper interface over Video Subsystem. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
memory allocator enhancements...
Hi All, I have been thinking on how to improve memory allocator (thou hasn't got too much time lately to play with it) so it could aid in following scenarios: 1. Move VBE BIOS thunks or other code from kernel to actual driver - specially named segment that gets allocated to lowmem in order to call VBE BIOS extensions - These should be located right after kernel in lowmem - Seems to be a bit tricky to patch relocation info properly (at least this is what I was last debugging). Ideas are welcome. Perhaps my code was not just modified properly... 2. Allocate memory for BIOS extensions in order to support BIOS drive mapping and El Torito or what ever someone needs. - Probably need to make hole to memory map that is passed to OS so allocated memory needs to be at end of lowmem so no holes within low memory are present - Perhaps this should be only done at last step of boot process. Eg allocate first memory to high mem and then when boot decision has been made, then allocate to low mem and make necessary hooks 3. Load OS image at start of highmem. I do not remember which OS needed this thou... 4. Allocate memory for GRUB code/modules/data. This can be at end of highmem. Are there any other needs? So what does people feel about these changes. I am afraid if too much freedom is given it will make it complex... Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Move loader.c out of the kernel
phcoder wrote: This usage case isn't the main target case. If you embed the loader (which tend to be quite big) then you already have an overhead from loader module. Why are you so concerned with overhead of boot.mod? But on the other hand this forces all the people in other cases to have boot code in core.img. I want to add preboot hooks and don't want increment size of kernel. multiboot.mod currently increases the size by around 11KB. And my patch doesn't restrict you from putting loader in core.img in any way Even if you add the preboot hooks there, it should only cause size affect in couple of bytes for uncompressed image. Like in following sketch: ... preboot_handler_address: dd 0 ... cmp [preboot_handler_address], 0 je no_preboot_handler call [preboot_handler_address] no_preboot_handler: ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of the normal mode
Bean wrote: Hi, This patch split the function of normal mode into small modules, here is a summary: 1, Move dynamic command loader to commands/dyncmd.c (dyncmd.mod) 2, Move automatic fs loader to fs/autofs.c (autofs.mod) 3, Split normal mode into three major parts: parser/normal - normal mode parser (nparser.mod) reader/normal - normal mode command line reader (nreader.mod) menu/text - menu viewer (tmenu.mod) 4, Generic menu function move to menu/menu.c and menu/menu_viewer.c. (menu.mod) 5, Misc function move to lib/misc.c lib/completion.c (misc.mod) 6, setjmp function move to lib/i386, lib/x86_64, lib/powerpc and lib/sparc64 (setjmp.mod) Umh... I could somewhat agree with moving text menu out of normal.mod. But... I feel we have passed the over engineering milestone sometime ago... and I am not frankly happy about that... Changes like this just make it a) harder to maintain, b) bigger overall size impact, c) as a plus more modular approach... I also fear that we seem to be missing some lead for the project that could use his authority to make decisions... ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of the normal mode
Yoshinori K. Okuji wrote: You should select compile-time loading (i.e. linking) whenever possible. If a function is loaded eventually, it should be linked at compile time. You should select automatic loading, if you need runtime linking. Manual loading should be considered evil, in principle. I agree. FYI, I am planning to make a full review of recent changes (i.e. all changes made after I stopped reviewing every patch), and trash/revert/rewrite/blame everything I don't like. Changes made for no good reason must be all reverted. In brief, I take back the leadership of this project for general directions. For some subsystems (e.g. the coreboot support), I continue leaving the responsibility to those who know better or are more active. Once the current code is reviewed and fixed (at some degree), I will make a new release. Any objection? Not really. I will make some grief, but it might be a good thing in overall. I would thou propose that you discuss the issue on mailing list so we can probably fine tune principles and objectives of GRUB 2 at the same time. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of the normal mode
Vesa Jääskeläinen wrote: Yoshinori K. Okuji wrote: Any objection? Not really. I will make some grief, but it might be a good thing in overall. Just to make it clear: It will... ;) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of the normal mode
Here I must comment that in some cases it is favorable to do it this way. I personally will only commit changes that I am happy to live with. Even if you are developer with SVN commit rights it is in some cases good idea to have general review of the patch... but there has been some lack of the time from people to review them (and it does not cross everyones interest zones, thus get attention to the patch). phcoder wrote: I'm actually quite unhappy with the grub's authority in general. Some people can commit their patches after a week of no replies while others like me have to wait that someone has time to review their patches in depth. I already have a collection of patches that are not commited, not because someone objects against them but just because nobody qualified enough has time to review and commit it. All this despite having already signed copyright assignment which because of slowness of FSF took more time than it should. From developer viewpoint it's very frustrating experience. If I wasn't so motivated as I am I would have already given up. IMO opinion if we want people coding for grub2 this has to be changed. But now you come and say you want to revert some patches just because they seem useless to you or rewrite some code just because you find it ugly or because it has a minor bug which could be easily fixed without rewriting. IMO this can easily drive developers to fork or leave project altogether. And additionally your energy would be much better spent in writing new stuff and making/reviewing design propositions than rewriting chunks of already working code. Sorry for being somewhat rude but I really find it frustrating this coder-unfriendliness In brief, I take back the leadership of this project for general directions. For some subsystems (e.g. the coreboot support), I continue leaving the responsibility to those who know better or are more active. Once the current code is reviewed and fixed (at some degree), I will make a new release. Any objection? Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of the normal mode
Yoshinori K. Okuji wrote: On Sunday 29 March 2009 20:40:17 David Miller wrote: Everybody is too busy to give this project the attention and time it deserves to be maintained properly. I honestly do not think the situation will change significantly until someone is able to devote real time as a maintainer and process all of the patches that get submitted each day. This is ideal but not absolutely required. If you look at some popular projects, such as Linux and Firefox, you can find out that not all (actually, very few) patches are handled so quickly, but those projects are functioning so well. For both of those projects there are people that are paid to do that work either directly or indirectly. How it internally affects, I don't know. Anyway... when people are paid to work there is certainly different driving force behind it. Both of those projects has divided work force dedicated to maintain and drive enhancements to defined goals. Now if we map this to our situation: - We are missing what we want to do (eg. roadmap, feature plan) - What different components should be able to do, eg. design documentation. - Use cases what we want to support - We don't really have defined responsibilities (expect for maintainers, and even that can be a bit vague) - What is philosophy what kind of work is being accepted and what we require for patches/commits - Systematic software functionality verification (either manual or automated) - If I am not mistaken no-one is being paid to maintain GRUB* or to develop for. (not so big deal) I have tried from time to time enhance some of those... but they seem not to drive enough interest. Perhaps with better coordination it could work. So perhaps it would be best to form some kind of organization that defines the goals and then defines responsibilities and backups for components and tries to drive targeting those goals. Those could be like though like internal maintainers for specific components. It could be like bi-monthly meeting to tackle issues on horizon. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of the normal mode
Yoshinori K. Okuji wrote: On Sunday 29 March 2009 22:23:11 Vesa Jääskeläinen wrote: Both of those projects has divided work force dedicated to maintain and drive enhancements to defined goals. Now if we map this to our situation: - We are missing what we want to do (eg. roadmap, feature plan) This is somehow intentional, because I believe that volunteers do only what they want to do anyway. In fact, the TODO list in the wiki has several high priority items, but they have been pending for a long, long time (e.g. writing a manual). That item has been in my mind too as people complain that there ain't one, even the developer one would be useful. But even if there are items in TODO list, people hesitate what to do about it. Some questions that could arise: Who do they consult? is my contribution really wanted? Do I waste my time by doing this? I could be interested in this task, but there is a task reservation name there. So perhaps it would be best to form some kind of organization that defines the goals and then defines responsibilities and backups for components and tries to drive targeting those goals. Those could be like though like internal maintainers for specific components. It could be like bi-monthly meeting to tackle issues on horizon. So you like formalism. I myself like a loose development model. If you have many active developers, formalism works better, because they start to conflict and consume most of the time for endless discussions, otherwise. But, people appear and disappear frequently in GRUB. Do you really think it works with GRUB? Here is another example: Someone writes a large pile (or even a small change) of code that he/she would like to get into GRUB. He/she just sends a patch to mailing list (or to tracker) and feels happy that I have done something now. Even if there are several developers that could understand the code, they do not even look at that as it is not within their close interests, or they might not have time. Or they feel that there is someone else with more knowledge that should handle this. So no-one really makes any kind of response as there is no pressure. Thus time the person has spent doing something is wasted. This again generates negative publicity... Another related issue is copyright assignment to FSF that seems to hinder also some people. But for that we can't really do much. Some examples... I am involved with GRUB for 10 years, but I sometimes disappear completely for several months. Then, back again. I think Pavel is also working on GRUB for nearly as long as me, but he works from time to time. It looks nearly random to me. Those scenarios also map to myself. Robert seems to be relatively constant these days, but he apparently does not have time to comment on all patches. So, till now, Do whatever you want to do when you feel that you want to has been the most practical, and legwork has been finished by official maintainers who have some formal responsibility (actually, official maintainers have responsibility only for endorsing the GNU philosophy, but they have done more than this). Right. But if there is no other responsibility for anyone, you cannot really ask people to follow any kind of design philosophy if there is no-one watching the progress. If you give free permission to do what ever you want, then you can pretty much expect that you get what ever gets there. I have from time to time though about projects that I have followed, what has failed those or what could be the problem why there is no real progress. In my opinion most of those have failed because there is no real guidance on what to do next. People just do and assume that other people will do something until they get enough frustrated and make the necessary change themselves. If this happens, then it certainly does not feel like fun. Projects with active leadership/management seem to flourish much better than on projects that where open sourcing means that here is the code, do what ever you like with it. So... to answer your question about formal development, yes, I feel that it could help here. A bit relaxed model perhaps would be best but there should always be tasks in horizon that needs to be done. Even some kind of dependency graph for those could be a good idea to concentrate task that needs to be done first. If tasks are somewhat defined then it is easy just to pick one and do that, it also helps on keeping track of the progress. It needs management but for that I would say that bi-monthly irc/skype/or whatever meeting would be useful for. Also if there are some design issues that might need multiple people to decide what to do (or they might even need a vote or alternative authority override). ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Idea: move grub-emu to a separate platform
Bean wrote: Hi, Currently, the grub-emu is in every rmk files, but I don't see the difference between grub-emu in i386-pc, i386-coreboot or i386-efi. In fact, grub-emu runs inside the host os, it can't access firmware facility anyway. One quick fix to move grub-emu to i386.rmk, but we could also put it in a new platform altogether, something like i386-host. The advantage of using a separate platform is that we could now use modules like the other platform, instead of embedding all source files in grub-emu. For example, whenever we add a new command, we need to modify the source list of grub-emu. But if we build i386-host like other platform, we only need to change common.rmk. What's more, i386-host is not just a testing tool, it could be a real boot loader. kboot provides a minimum linux environment. We could use i386-host as a front end, and use kexec to launch additional boot files. I think I have from time to time proposed this too :) So I am all for it :) But my point was more to cleanup makefiles in sensible way and then on PC to allow more advanced automated (module) testing. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] 5/5 Graphical menu (gfxmenu)
Colin D Bennett wrote:
This long-awaited patch adds graphical menu support to GRUB 2. It is
largely the result of my work during the Google Summer of Code 2008.
The graphical menu system supports image-based themes, of which I have
created several sample themes[1].
There are still a few important things that need to be done on gfxmenu
before it is completely ready for end-users (off the top of my head):
- Need a good way to switch themes at runtime. I want to add a popup
menu that lists the available themes and lets the user choose one.
(Currently the keys 1, 2, 3, and 4 are hardcoded to switch between my
sample themes...)
Switching themes on runtime is not a priority. It is a nice to have
feature thou... but we can wait a bit with that.
- gfxmenu interacts badly with gfxterm. Running commands from the
terminal withing gfxmenu that switch the video mode
('videotest basic', for instance) cause a crash when the command
returns. I think this has something to do with the interaction of
video mode-switching and the GRUB output terminal.
I think we can live with some oddities so I would propose that we get
some version in. In fact it will make fixing bugs a bit more robust as
others can also contribute...
So whats the status of your actions. I think some of the patches were
already approved with some minor changes...
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB device names wrt. ieee1275
David Miller wrote: One issue I need to resolve before I can send finalized patches out for sparc is about device naming. Currently the PowerPC ieee1275 support allows using both device aliases and full openfirmware device path names with the usual GRUB partition specification concatenated at the end. For the most part this is fine. This works for a large group of cases, but in general it will not work. The problem is two fold: 1) , characters can appear anywhere in an openfirmware path name. For example my workstations disk is: /p...@1e,60/p...@0/p...@9/p...@0/s...@1/d...@0 There are no quick workarounds for this. For example, even if we can change the partition fetching code in GRUB to use strrchr() instead of strchr() in kern/disk.c:grub_disk_open() it will still think the above path has partition ,60 or something silly like that. Actually related question here is that how do you specify similar device paths in x86? Now that there is pci support and some kinda usb support it could be good idea to specify exact device somehow in some use cases. 2) Disks can have multiple comma seperated components especially on SCSI in OF path names. For example a disk on target 2, lun 3, would have final path component d...@2,3 And currently that ,3 would look like a parition specification to GRUB. Therefore, I would suggest that we adopt the openfirmware partition specification of : on GRUB for ieee1275 platforms. Then we just have a machine specific path seperator, defined in some grub/machine/foo.h header file and the kernel/disk.c code and elsewhere use the macro instead of , Any objections? So you propose following: (/p...@1e,60/p...@0/p...@9/p...@0/s...@1/d...@0:1) (/p...@1e,60/p...@0/p...@9/p...@0/s...@1/d...@0:a,1) ( $FW_DISK_NAME + ':' + $GRUB_PARTITION_SCHEME ) ? If we go that path we should use same delimeter for other archs to make it a bit easier for users to understand how it works. Lets try couple of examples: 1. (hd0) = a-d) device alias 'hd0', no partition 2. (hd0,1) = a-d) device alias 'hd0', partition '1' 3. (hd0:1) = a) device alias 'hd0:1', no partition b) device alias 'hd0:1', no partition c) device alias 'hd0', partition '1' d) device alias 'hd0:1', no partition 4. (/p...@1e,60/p...@0/p...@9/p...@0/s...@1/d...@0) a) = device alias '/p...@1e', partition '60/p...@0/p...@9/p...@0/s...@1/d...@0' b) = device alias '/p...@1e', partition '60' c) = device alias '/p...@1e', partition '60/p...@0/p...@9/p...@0/s...@1/d...@0' d) = device alias '/p...@1e,60/p...@0/p...@9/p...@0/s...@1/d...@0', no partition 5. (/p...@1e,60/p...@0/p...@9/p...@0/s...@1/d...@0:1) a) = device alias '/p...@1e', partition '60/p...@0/p...@9/p...@0/s...@1/d...@0:1' b) = device alias '/p...@1e', partition '60' c) = device alias '/p...@1e,60/p...@0/p...@9/p...@0/s...@1/d...@0', parition '1'. d) = device alias '/p...@1e,60/p...@0/p...@9/p...@0/s...@1/d...@0', parition '1'. 6. (/p...@1e,60/p...@0/p...@9/p...@0/s...@1/d...@0:) a) = device alias '/p...@1e', partition '60/p...@0/p...@9/p...@0/s...@1/d...@0:1' b) = device alias '/p...@1e', partition '60' c) = device alias '/p...@1e,60/p...@0/p...@9/p...@0/s...@1/d...@0', no partition parition. d) = device alias '/p...@1e,60/p...@0/p...@9/p...@0/s...@1/d...@0', no partition parition. Now the algorithms for a-d: a) look for first comma, split there b) look for first comma, split there, filter out results c) look for ':', if found split there, otherwise go to a) d) look for '/' at start, if found look for ':' to differentiate partitions, if not found go to a) Now lets play with phcoder's idea: (/p...@1e,60/p...@0/p...@9/p...@0/s...@1/d...@0) (/p...@1e,60/p...@0/p...@9/p...@0/s...@1/d...@0,1) (/p...@1e,60/p...@0/p...@9/p...@0/s...@1/d...@0,a,1) This could be easier to get right. Thou still needs some learning curve for user. This extension could be used to look out for all firmware names (assuming they map to ascii/utf-8). ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] dynamic cache allocation
phcoder wrote: Hello. Discussing with Robert Millan and Bean on IRC we noticed that disk cache index is statically allocated. Here is a proposal to change it to dynamic allocation proportional to the size of available memory. And the gain is ? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] linux/gfxterm integration
Robert Millan wrote: On Fri, Mar 06, 2009 at 08:57:35PM +0100, Robert Millan wrote: This patch integrates the generic Linux loader with gfxterm. The result is that graphical mode becomes usable with this loader. Our loader gets the screen settings from the video subsystem (as per gfxterm setup), and passes them to Linux. This way GRUB/gfxterm can transition to Linux/fb with no further mode setting. Perhaps this can be exploited to make the transition seamless by using the same background image in both places, but I haven't explored this possibility yet :-) Note: As the comment in grub/video.h says, struct grub_video_render_target didn't really want to be moved. My code only needs to access it to find the framebuffer address. Perhaps it'd be better to move this information elsewhere? Or split it in a separate structure / getter? New patch. This one calls grub_linux_setup_video() from grub_linux32_boot instead of grub_rescue_cmd_linux. This way it gets the video status we have when boot is issued instead of the one we have when linux is loaded. Any comments on my question about struct grub_video_render_target ? Don't like em... Let me think it a bit. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/7]: Fix sparc64 setjmp implementation.
David Miller wrote: + stx %g1, [%sp + 2047 + (14 * 8)] +retl + restore %o1, 0, %o0 Please check your white spaces. As we can see here those three commands are on different columns (mixed tabs and spaces). This applies to every other patch you sent too... ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/7]: Fix sparc64 setjmp implementation.
David Miller wrote: This corrects the sparc64 setjmp implementation. We need to store the return address register, the stack pointer, and frame pointer into the jump buf. And on longjmp we need restore those registers, flush the register window state, and pull in the top-most register window. 2009-03-03 David S. Miller da...@davemloft.net * normal/sparc64/setjmp.S: Fix setjmp implementation. * include/grub/sparc64/setjmp.h: Update grub_jmp_buf[]. --- include/grub/sparc64/setjmp.h |3 +-- normal/sparc64/setjmp.S | 18 +- 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/include/grub/sparc64/setjmp.h b/include/grub/sparc64/setjmp.h index 12d8e01..183a820 100644 --- a/include/grub/sparc64/setjmp.h +++ b/include/grub/sparc64/setjmp.h @@ -19,8 +19,7 @@ #ifndef GRUB_SETJMP_CPU_HEADER #define GRUB_SETJMP_CPU_HEADER 1 -/* FIXME (sparc64). */ -typedef unsigned long grub_jmp_buf[20]; +typedef unsigned long grub_jmp_buf[3]; I assume unsigned long is 64bit in sparc? Would it be more practical to use grub_uint64_t? Are there any other registers that needs to be preserved ? Other than that I cannot decipher more from that asm :). If you have tested it and it works. It probably ain't bad idea to commit this patch. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 0/7]: Get sparc building again.
David Miller wrote: Here is a series of patches that fix the most obvious sparc bugs and get the grub2 tree building again. I have code for boot/ that will implement the sparc boot blocks and things of that nature, but that will come later. First things first, let's get it to actually build. :) Thanks for looking at it. It has been rotting for some time now. Basic principle is to look how it is done on other archs (mainly x86 at this time). And adapt same principle there too. If those match quite close each other it is easier to keep them all in sync... ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 3/7]: Implement proper sparc64 kern startup.
David Miller wrote: This replaces the C implementation with a proper assembler one. Also add missing grub_prefix[] declaration to kernel.h 2009-03-03 David S. Miller da...@davemloft.net * kern/sparc64/ieee1275/init.c: Delete, replace with... * kern/sparc64/ieee1275/crt0.S: assembler implementation. * include/grub/sparc64/ieee1275/kernel.h: Declare grub_prefix[]. I must say that I am not familiar with sparc. But there were lots of functions inside of init.c. Are those all not needed at all? And if this is true. This patch is missing matching .rmk modifications... Please have a look at other archs how it is done there. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 5/7]: Add sparc64 loader implementation.
David Miller wrote: 2009-03-03 David S. Miller da...@davemloft.net * include/grub/sparc64/ieee1275/loader.h: New file. * include/grub/sparc64/ieee1275/memory.h: Likewise. * include/grub/sparc64/kernel.h: Likewise. * loader/sparc64/ieee1275/linux.c: Likewise. * loader/sparc64/ieee1275/linux_normal.c: Likewise. Please re-use as much as possible of common code. In example linux_normal.c is there in loader/linux_normal.c. I think Robert committed some changes that unified a bit these. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 7/7]: Get cob-webs out of sparc64-ieee1275.rmk
David Miller wrote: There is no way anyone tried to build the sparc target in years :-) This updates sparc64-ieee1275.rmk with modern times and regenerates sparc64-ieee1275.mk as well as DISTLIST. 2009-03-03 David S. Miller da...@davemloft.net * conf/sparc64-ieee1275.rmk: Update. * conf/sparc64-ieee1275.mk: Rebuilt. * DISTLIST: Rebuilt. There is no need to include .mk files in patches. They just make it a bit chaotic. Please make sure to sync in example normal.mod to be exactly how x86 is. This way that is much easier to maintain. Please compare those to each other and look that they match as much as possible. If you see it sensible to differentiate common arch stuff to own file like in: i386-pc.rmk i386.rmk common.rmk Then please do so. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Strip boot block built objects.
David Miller wrote: From: Vesa Jääskeläinen ch...@nic.fi Date: Wed, 04 Mar 2009 13:59:43 +0200 David Miller wrote: In order for the boot block images for sparc to work properly, we have to strip them out before doing the objcopy. This is harmless on i386-pc and some other future grub targets might need this too, so do it universally. Please have a look at mail from me with subject qemu + gdb debugging... on 22.2.2009 17:34. My patch only strips information for the foo.img boot block images built in the grub tree. Your debugging hacks are only for the rest of the grub kernel and don't even come close to touching the areas I am interested in and changing. Ok. Just wanted to inform you about that. If there is existing debug image that matches quite nicely to boot image then it is easier to debug as code matches quite nicely to assembly. It is much nicer to debug when debugger can follow actual code lines. Anyway. Idea there was that strip was not used, but objcopy was used to generate matching image. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Menu locks / password authentication
Robert Millan wrote: It's funny, we're all discussing about performing security measurements in GRUB and nobody mentioned that our user interface lacks even the most basic lock mechanism :-) Perhaps this would be a good time to retake the discussion on implementing an equivalent to lock and password commands. I think I even sent a patch a while ago! Vesa, do you still think we should design an extensible framework for authentication before we do anything else? I think it'd be interesting if we could implement the lock/password paradigm, even if later it would be replaced, since our users commonly need this, and it's blocking the transition from GRUB Legacy. I think that most important thing at this time is to match needed functionality with GRUB legacy. So just make it clean and perhaps think a bit about how it can be easily extended :). I think there was some hash algorithms posted previously that could be used for this. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
qemu + gdb debugging...
Hi All,
I was debugging some problem lately and felt that I need to use
debugger. As I like how JTAG debugging works I wanted to have similar
feeling :). Obivious choice is to use QEMU.
QEMU provides a GDB stub that can be used to debug code running on its
virtual session. I also found out that VMware also features this same
feature, though it needs a bit configuration changes. Anyway...
In order for GDB session to be a bit fancier you are going to need debug
symbols. In order to do that we need Lubomir Rintel's patch to support
debug symbol generation. (Adapted version is attached to this email).
After this everything is ready in GRUB 2 building. Next steps is to
improve GDB handling to support our dynamic module loader. For this
Lubomir's scripts for GDB comes in to play. I adapted them a bit for new
naming and after this I could nicely add breakpoint to code that gets
loaded later on by GRUB module loader and it stopped nicely there on
correct spot.
Based on this finding I would say that we integrate following bits of code.
Lubomir also create GDB stub that allows debugging on real hardware over
serial cable. This is fine for me, but at this time I only need to have
QEMU debugging working. And as this step is shared between those two I
propose that this work is sliced to two pieces.
Thanks,
Vesa Jääskeläinen
Index: ChangeLog
===
--- ChangeLog (revision 1999)
+++ ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2009-02-22 Vesa Jääskeläinen ch...@nic.fi
+
+ Based on patch by Lubomir Rintel lkund...@fedoraproject.org.
+
+ * genmk.rb: Add new stage to compile first debug symbol version of
+ module and then use objcopy to generate final image to allow easier
+ debugging.
+
2009-02-22 Robert Millan r...@aybabtu.com
* include/multiboot.h (MULTIBOOT_INFO_ALIGN): New macro.
Index: genmk.rb
===
--- genmk.rb(revision 1996)
+++ genmk.rb(working copy)
@@ -101,10 +101,11 @@
mod_obj = mod_src.suffix('o')
defsym = 'def-' + @name.suffix('lst')
undsym = 'und-' + @name.suffix('lst')
+exec = @name.suffix('mod.exec')
mod_name = File.basename(@name, '.mod')
symbolic_name = mod_name.sub(/\.[^\.]*$/, '')
-CLEANFILES += #...@name} #{mod_obj} #{mod_src} #{pre_obj} #{objs_str}
#{undsym}
+CLEANFILES += #...@name} #{mod_obj} #{mod_src} #{pre_obj} #{objs_str}
#{undsym} #{exec}
ifneq ($(#{prefix}_EXPORTS),no)
CLEANFILES += #{defsym}
DEFSYMFILES += #{defsym}
@@ -112,11 +113,14 @@
MOSTLYCLEANFILES += #{deps_str}
UNDSYMFILES += #{undsym}
-...@name}: #{pre_obj} #{mod_obj} $(TARGET_OBJ2ELF)
+...@name}: #{exec}
+ -rm -f $@
+ $(OBJCOPY) --strip-unneeded -K grub_mod_init -K grub_mod_fini -K
_grub_mod_init -K _grub_mod_fini -R .note -R .comment $^ $@
+
+#{exec}: #{pre_obj} #{mod_obj} $(TARGET_OBJ2ELF)
-rm -f $@
$(TARGET_CC) $(#{prefix}_LDFLAGS) $(TARGET_LDFLAGS) $(MODULE_LDFLAGS)
-Wl,-r,-d -o $@ #{pre_obj} #{mod_obj}
if test ! -z $(TARGET_OBJ2ELF); then ./$(TARGET_OBJ2ELF) $@ || (rm -f
$@; exit 1); fi
- $(STRIP) --strip-unneeded -K grub_mod_init -K grub_mod_fini -K
_grub_mod_init -K _grub_mod_fini -R .note -R .comment $@
#{pre_obj}: $(#{prefix}_DEPENDENCIES) #{objs_str}
-rm -f $@
# gmodule.pl - Generate GDB commands to load symbols to right addresses
# GRUB -- GRand Unified Bootloader
# Copyright (C) 2009 Free Software Foundation, Inc.
#
# GRUB 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 3 of the License, or
# (at your option) any later version.
#
# GRUB 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 GRUB. If not, see http://www.gnu.org/licenses/.
use strict;
use warnings;
while () {
# Line we get contains section number - load address pairs
# prepended by module name
my ($file, %load_addr) = split;
my $text = ''; # This one needs not be prepended by -s
my $sections = ''; # All but .text
print add-symbol-file $file;
open (READELF, readelf -S $file |)
or die $!;
while (READELF) {
/\[\s*(\d+)\]\s+(\.\S+)/ or next;
my $sec_num = $1;
my $sec_name = $2;
# .text section doesn't have to be prepended by -s .text
if ($sec_name eq '.text') {
$text = $load_addr{$sec_num};
next;
}
$sections .= -s $sec_name
Re: qemu + gdb debugging...
Oh... The usage information was left behind :) You might need to have most recent QEMU and GDB versions for most challenging bugs :)... 1. Copy grub.gdb and gmodule.pl to your build directory. 2. Create image for QEMU (grub2.iso in my case). 3. Launch QEMU with GDB stub: qemu -s -S -cdrom grub2.iso 4. Launch GDB gdb -x grub.gdb 5. Load connect to QEMU target remote localhost:1234 6. Load debug symbols for grub 2 kernel load_kernel 7. Setup breakpoint in grub_main break grub_main 8. Continue execution until there c 9. Next time you are at grub_main 10. Delete grub_main breakpoint if it haunts you del 1 ; where 1 is being breakpoint number use 'info break' to see numbers if you lost that. 11. Setup automatic symbol loading break_load 12. Happy debugging! If you want to debug boot code that can be done also... but its a bit more tricky... and I leave that to another time :). Tips for RM code debugging: 'set arch i8086' and 'x/10i ($cs4)+$eip'. Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
Hi All, Ok. Please keep the fighting of TPM out of this thread ;). Lets keep it to the topic first... (I am already waiting for summary of that other discussion at some point ;)) Jan Alsenz wrote: Next I think we can agree, that some sort of trusted boot chain can be useful. Also there should be more than one implementation for this (or at least the possibility to have them). I like the idea of modularity in here. However. It should work with different schemes but same generic interfaces if that is what is planned. If we could agree on this, then I think we could find a way to extend the GRUB module system to fully allow this. From my point of view the minimal needed features for these systems are: - easy exchange of the MBR binary to be installed - easy exchange of the core.img loader binary - hooks for any disk read (not sure if write is necessary) Note: I will skip MBR+core.img validation for a reason here now. I do like the idea what some protected systems use, they sign the binary (in our case .mod file and kernels of loaded OSes). Now in that scenario it is responsibility of the kernel module loader to first verify the signature for correctness. This way the signature checking would be somewhat transparent to the rest of the system. I do not see a need to add any hooks to disk read. It should be responsibility of the code needing signature checking to handle that. And please try to share some code with password/authentication features :) Last part to agree on would then be, that these infrastructure features should be in the mainline code. That way it would be easy to develop various trusted boot solutions (and probably some other systems too), but keep all the controversial code out of mainline. Yes. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
Jan Alsenz wrote: Vesa Jääskeläinen write: I do like the idea what some protected systems use, they sign the binary (in our case .mod file and kernels of loaded OSes). Now in that scenario it is responsibility of the kernel module loader to first verify the signature for correctness. This way the signature checking would be somewhat transparent to the rest of the system. I do not see a need to add any hooks to disk read. It should be responsibility of the code needing signature checking to handle that. Well, since to trusted operation should be transparent (and in my opinion should not need code changes in something like the loaders - so if someone writes a new loader, it should work by default), that's where the hooks come in. Maybe the disk read was misleading, what I meant where file reads. Hi, Well.. you probably don't want to verify authenticity of the fonts or bitmaps in graphical menu? Anyway. I think the right place for verification hook in this case is the module or OS kernel loader. If you think otherwise. Then you have to provide a complete technical design how it should work as I see no other good choice for it. (actually there is one other place that could be used, but I let you come up with the idea after you have given a bit more though on the implementation side :)) Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Jan Alsenz wrote: I agree too! Multiple methods are interesting and everything that can be, should be placed in modules. But some parts of a trusted boot chain need to be in the MBR, etc. which is mainline code (regardless of how how you build it). The way I have implemented my version of the MBR right now is with compile flags: If you don't want/need TPM code it won't be on your system! If you compile it with TPM support, it won't boot if there is no TPM (I don't like silent failures). In case it will get some day in. I would propose that you make own MBR code like that gets compiled to own img file like tpmboot.img (512 bytes). Then you can just provide img file for tool chain. You are probably throwing code away anyway from normal mbr boot code. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Handler support
Bean wrote:
On Sat, Feb 14, 2009 at 11:11 PM, Felix Zielcke fziel...@z-51.de wrote:
A. Am Samstag, den 14.02.2009, 22:46 +0800 schrieb Bean:
If there is no objection, I'd commit this patch in a few days.
Hello Bean,
if you want to drop termin_input and terminal_output command then please
don't forget to update util/grub.d/00_header.in
+GRUB_MOD_INIT(handler)
+{
+ (void)mod; /* To stop warning. */
+ grub_register_command (handler, grub_cmd_handler,
GRUB_COMMAND_FLAG_BOTH,
+handler [class [handler]],
+List or select a handler, 0);
+}
+
+GRUB_MOD_FINI(handler)
+{
+ grub_unregister_command (hello);
+}
This should probable be grub_unregister_command (handler).
Hi,
Thanks for pointing out, this new patch should fix the problem.
Hi,
Ok. I a way this functionality could be used. I just don't like how it
is visible to the user.
+if handler output ${GRUB_TERMINAL_OUTPUT} ; then true ; else
+ # For backward compatibility with versions that uses terminal.mod instead
+ # of handler.mod
+ if terminal_output ${GRUB_TERMINAL_OUTPUT} ; then true ; else
+# For backward compatibility with versions of terminal.mod that don't
+# understand terminal_output
+terminal ${GRUB_TERMINAL_OUTPUT}
+ fi
If we look at this snippet, for me keyword handler doesn't say a thing.
where it could be terminal for terminal handlers.
So I would propose to change it in following ways:
1. Do not register handler command unless you need to enumerate those or
allow more flexibility to configuration
2. Register command functions/alias to more understandable grub commands.
So following could be:
terminal output whatever
or keep it what it is (I would prefer above line)
terminal_output
Good idea with this handler stuff would be that if someone writes following:
terminal console
It would lookup if this console provides input and output service and
would use them out of the box.
Now if some-one writes something like:
terminal --input usbkbd --input console --output console
or:
terminal --input usbkbd
terminal --input console
terminal --output console
or
terminal_input usbkbd
terminal_input console
terminal_output console
or
terminal_input usbkbd console
terminal_output console
or
terminal_input console
terminal_output console
termianl_input --add usbkbd
User would now get two input sources like ps2 keyboard and usb keyboard
and then output to console.
Anyway... my point being... handler does not say anything to me in a
sens what does it logically give to user. It hinders the understanding
of the user for grub 2 usage...
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Bugfix] Characters disappearing in gfxterm
BandiPat wrote: Vesa Jääskeläinen wrote: phcoder wrote: Hello. I've run into the bug that when editing menu entry in gfxterm characters disappear after cursor moves away from its position. Here is bugfix I don't think this is a clean fix: It is not designed to work in there. I think modifying this needs logical level approach and not ad hoc fix. Has this fix been committed yet or is there further work to be done to clean it up before applying it? It has not been committed. Nor do I have had chance to personally to look at it. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Bugfix] Characters disappearing in gfxterm
phcoder wrote: Hello. I've run into the bug that when editing menu entry in gfxterm characters disappear after cursor moves away from its position. Here is bugfix I don't think this is a clean fix: Index: term/gfxterm.c === --- term/gfxterm.c(revision 1974) +++ term/gfxterm.c(working copy) @@ -744,6 +744,8 @@ /* Render cursor to text layer. */ grub_video_set_active_render_target (text_layer); grub_video_fill_rect (color, x, y, width, height); + if (! show) +write_char (); grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); /* Mark cursor to be redrawn. */ It is not designed to work in there. I think modifying this needs logical level approach and not ad hoc fix. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Bugfix] vbetest doesn't return to text mode
phcoder wrote: Hello. In text mode bits_per_pixel isn't set. Because of it grub_vbe_set_video_mode refuses to go back to text mode after vbetest command. Here is a bugfix Thanks for the report that there was a problem. I didn't like the hackishm in that patch so I rewrote that part of the code so it can also handle text modes. Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: compilation of grub-emu is currently broken
Felix Zielcke wrote: Am Sonntag, den 01.02.2009, 21:08 +0100 schrieb Felix Zielcke: grub_emu-normal_main.o: In function `grub_mod_init': /home/fz/grub/grub2.svn/normal/main.c:623: undefined reference to `grub_menu_viewer_register' grub_emu-normal_main.o: In function `grub_normal_execute': /home/fz/grub/grub2.svn/normal/main.c:580: undefined reference to `grub_menu_viewer_show_menu' Fix commited. Thanks. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Help with Grub2
BandiPat wrote: Compiled and installed grub2. Remove LILO from MBR. Ran grub-install /dev/sda. Run grub-setup /dev/sda. Ran update-grub to let it create a grub.cfg file. So far, so good and checking everything, it all looks great according to the instructions I have been able to find. By the way, I have done a lot of researching these past 2 days! That's how I came to find this mail list, but wanted to wait to finish my testing before using it. you should only need to use grub-install and update-grub (or grub-mkconfig) Running grub-setup after grub-install without matching arguments given by grub-install to grub-setup it can create non-working setup. So commands needed are: grub-install update-grub (or grub-mkconfig, or manually create grub.cfg) Now if you get stuck to rescue console you probably want to start loading normal mode first (insmod normal.mod) and required modules needed for booting. I think we should write something about rescue console to wiki. Here is what probably happened: When you issues grub-setup manually you probably forgot to specify filesystems and such so grub cannot load natively from MBR your system. As grub-setup is advanced tool it should not be used manually, please try with only grub-install and see if it help. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: compilation of grub-emu is currently broken
Felix Zielcke wrote: grub_emu-normal_main.o: In function `grub_mod_init': /home/fz/grub/grub2.svn/normal/main.c:623: undefined reference to `grub_menu_viewer_register' grub_emu-normal_main.o: In function `grub_normal_execute': /home/fz/grub/grub2.svn/normal/main.c:580: undefined reference to `grub_menu_viewer_show_menu' This is actually quite good reminder what is wrong in our current build system. How to specify common files for multiple places... One good example is normal.mod. There is only one non-common file that needs to be there and for that reason it needs to reside on arch specific makefile. So we have same definition on multiple files. In that light I would prefer to have grub-emu architecture that has only specific code there. And then somehow tackle nicely those arch specific stuff to own makefiles... Any ideas are welcome how to achieve that in good way? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GSoC #05 Menu entry class attribute (v2)
Colin D Bennett wrote: Thanks for the argument parsing improvement. I'm glad to rip out the '|class=' title kludge. Here is the result of merging your patch into the menu entry class code. Hi Colin, I combined your menu entry and menu viewer patches and committed them in with slight modifications. See if you are happy with it :) Oh. And btw. I think I am out of sync what is still missing. So let me know if you think there is something critical that needs to be there in order to integrate your gfxmenu. As you have now commit access please be free to consult list and commit small changes yourself. Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] 1/5 Multiple fallback entries
Colin D Bennett wrote:
This patch adds support for multiple fallback entries in grub.cfg.
I'll prepare the ChangeLog entry when the patch is approved to be
committed.
The patch is against GRUB trunk revision 1964.
What do you think if all text menu related would be moved to own file,
like menu_text.c or so ? I think it will cleanup code nicely...
=== modified file 'include/grub/normal.h'
--- include/grub/normal.h 2009-01-31 09:15:43 +
+++ include/grub/normal.h 2009-01-31 17:47:55 +
@@ -98,10 +98,24 @@
extern struct grub_menu_viewer grub_normal_terminal_menu_viewer;
+typedef struct grub_menu_execute_callback
+{
+ void (*notify_booting) (void *userdata, grub_menu_entry_t entry);
+ void (*notify_fallback) (void *userdata, grub_menu_entry_t entry);
+ void (*notify_failure) (void *userdata);
Usually pointer to userdata is last argument in list. Please use same
term for it as in grub_menu_execute_with_fallback (you are free to pick
new name if you see that it fits better).
+}
+*grub_menu_execute_callback_t;
+
void grub_enter_normal_mode (const char *config);
void grub_normal_execute (const char *config, int nested);
+void grub_menu_execute_with_fallback (grub_menu_t menu,
+ grub_menu_entry_t entry,
+ grub_menu_execute_callback_t callback,
+ void *callback_data);
void grub_menu_entry_run (grub_menu_entry_t entry);
void grub_menu_execute_entry(grub_menu_entry_t entry);
+int grub_menu_get_timeout (void);
+void grub_menu_set_timeout (int timeout);
void grub_cmdline_run (int nested);
int grub_cmdline_get (const char *prompt, char cmdline[], unsigned max_len,
int echo_char, int readline);
=== modified file 'normal/menu.c'
--- normal/menu.c 2009-01-31 09:15:43 +
+++ normal/menu.c 2009-01-31 17:47:55 +
@@ -244,8 +244,8 @@
/* Return the current timeout. If the variable timeout is not set or
invalid, return -1. */
-static int
-get_timeout (void)
+int
+grub_menu_get_timeout (void)
{
char *val;
int timeout;
@@ -272,8 +272,8 @@
}
/* Set current timeout in the variable timeout. */
-static void
-set_timeout (int timeout)
+void
+grub_menu_set_timeout (int timeout)
{
/* Ignore TIMEOUT if it is zero, because it will be unset really soon. */
if (timeout 0)
@@ -311,6 +311,44 @@
return entry;
}
+/* Get the first entry number from the variable NAME, which is a
+ space-separated list of nonnegative integers. The entry number which
+ is returned is stripped from the value of NAME. If no entry number can
+ be found, returns -1. */
We use term environment variable...
+static int
+get_and_remove_first_entry_number (const char *name)
+{
+ char *val;
+ char *tail;
+ int entry;
+
+ val = grub_env_get (name);
+ if (! val)
+return -1;
+
+ grub_error_push ();
+
+ entry = (int) grub_strtoul (val, tail, 0);
...
+
+/* Callbacks for grub_menu_execute_with_fallback() for the text menu. */
+
If you move these to new file, please replace this comment with new
comments for every function.
+static void
+notify_booting (void *userdata __attribute__((unused)),
+ grub_menu_entry_t entry)
+{
+ grub_printf ( Booting \'%s\'\n\n, entry-title);
+}
+
+static void
+notify_fallback (void *userdata __attribute__((unused)),
+ grub_menu_entry_t entry)
+{
+ grub_printf (\n Falling back to \'%s\'\n\n, entry-title);
+ grub_millisleep (2000);
I think this delay should be generic part of the implementation and not
specific to text menu. Or alternatively it needs to be documented that
fallback callback function is supposed to wait for 2 secs...
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] 2/5 VBE double buffering
Colin D Bennett wrote:
This patch adds double buffering support support to the VBE
video driver including page flipping and blitting from an offscreen back
buffer.
The patch is against GRUB trunk revision 1964.
Unless we come up with better idea we can go with this time being...
Check the comments below and act accordingly...
=== modified file 'include/grub/video.h'
--- include/grub/video.h 2009-01-02 15:26:06 +
+++ include/grub/video.h 2009-01-31 17:48:10 +
@@ -47,10 +47,10 @@
#define GRUB_VIDEO_MODE_TYPE_DEPTH_MASK 0xff00
#define GRUB_VIDEO_MODE_TYPE_DEPTH_POS 8
-/* Defined predefined render targets. */
-#define GRUB_VIDEO_RENDER_TARGET_DISPLAY ((struct
grub_video_render_target *) 0)
-#define GRUB_VIDEO_RENDER_TARGET_FRONT_BUFFER((struct
grub_video_render_target *) 0)
-#define GRUB_VIDEO_RENDER_TARGET_BACK_BUFFER ((struct
grub_video_render_target *) 1)
+/* The basic render target representing the whole display. This always
+ renders to the back buffer when double-buffering is in use. */
+#define GRUB_VIDEO_RENDER_TARGET_DISPLAY \
+ ((struct grub_video_render_target *) 0)
/* Defined blitting formats. */
enum grub_video_blit_format
=== modified file 'video/i386/pc/vbe.c'
--- video/i386/pc/vbe.c 2009-01-02 15:26:06 +
+++ video/i386/pc/vbe.c 2009-01-31 17:48:10 +
@@ -62,6 +62,7 @@
static struct
{
struct grub_video_render_target render_target;
We do not use comments at end of line. Please move it to line before
actual variable it is describing.
+ int is_double_buffered; /* Is the video mode double buffered? */
unsigned int bytes_per_scan_line;
unsigned int bytes_per_pixel;
@@ -76,6 +77,24 @@
static grub_uint32_t mode_in_use = 0x55aa;
static grub_uint16_t *mode_list;
Ditto for below. And after '.' in comment there should be two spaces.
+static struct
+{
+ grub_size_t page_size;/* The size of a page in bytes. */
+
+ /* For page flipping strategy. */
+ int displayed_page; /* The page # that is the front buffer. */
+ int render_page; /* The page # that is the back buffer. */
+
+ /* For blit strategy. */
+ grub_uint8_t *offscreen_buffer;
+
+ /* Virtual functions. */
+ int (*update_screen) (void);
+ int (*destroy) (void);
+} doublebuf_state;
+
+static void double_buffering_init (void);
+
static void *
real2pm (grub_vbe_farptr_t ptr)
{
@@ -375,6 +394,7 @@
/* Reset frame buffer and render target variables. */
grub_memset (framebuffer, 0, sizeof(framebuffer));
render_target = framebuffer.render_target;
+ grub_memset (doublebuf_state, 0, sizeof(doublebuf_state));
return GRUB_ERR_NONE;
}
@@ -390,6 +410,9 @@
/* TODO: Decide, is this something we want to do. */
return grub_errno;
+ if (doublebuf_state.destroy)
+doublebuf_state.destroy();
+
/* TODO: Free any resources allocated by driver. */
grub_free (mode_list);
mode_list = 0;
@@ -532,9 +555,12 @@
render_target-viewport.width = active_mode_info.x_resolution;
render_target-viewport.height = active_mode_info.y_resolution;
- /* Set framebuffer pointer and mark it as non allocated. */
+ /* Mark framebuffer memory as non allocated. */
render_target-is_allocated = 0;
- render_target-data = framebuffer.ptr;
Please add empty line here to group it a bit nicer.
+ /* Set up double buffering information. */
+ framebuffer.is_double_buffered =
+((mode_type GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED) != 0);
+ double_buffering_init ();
/* Copy default palette to initialize emulated palette. */
for (i = 0;
@@ -555,6 +581,166 @@
return grub_error (GRUB_ERR_UNKNOWN_DEVICE, no matching mode found.);
}
+/*
+ Set framebuffer render target page and display the proper page, based on
+ `doublebuf_state.render_page' and `doublebuf_state.displayed_page',
+ respectively.
+
+ Returns 0 upon success, nonzero upon failure.
+ */
+static int
+doublebuf_pageflipping_commit (void)
+{
Dot spaces..
+ /* Set the render target's data pointer to the start of the render_page. */
+ framebuffer.render_target.data =
+((char *) framebuffer.ptr) +
+doublebuf_state.page_size * doublebuf_state.render_page;
+
+ /* Tell the video adapter to display the new front page. */
+ int display_start_line =
+framebuffer.render_target.mode_info.height
+* doublebuf_state.displayed_page;
+
+ grub_vbe_status_t vbe_err =
+grub_vbe_bios_set_display_start (0, display_start_line);
+ if (vbe_err != GRUB_VBE_STATUS_OK)
+return 1;
+
+ return 0;
+}
+
+static int
+doublebuf_pageflipping_update_screen (void)
+{
Same here...
+ /* Swap the page numbers in the framebuffer struct. */
+ int new_displayed_page = doublebuf_state.render_page;
+ doublebuf_state.render_page
Re: [PATCH] 3/5 Bitmap scaling
Colin D Bennett wrote:
This patch adds bitmap scaling support to GRUB.
It also adds support to gfxterm for scaling the background image to fit
the screen. The background_image command supports a new -m/--mode
option, which takes stretch (the default) or normal as values.
The patch is against GRUB trunk revision 1964.
After commit this needs to be documented to wiki/gfxterm with an example
perhaps...
Vesa started a discussion about more flexible handling of bitmaps
including the concept of optimizing loaded bitmaps into a
display-specific format, at which point they could no longer be
modified by functions like the bitmap scaling functions.
This bitmap format optimization would be nice to add, but I think we
can at least add this basic bitmap scaling functionality to start
with. It only supports 24/32 bpp direct color modes at this point to
keep things simple.
True. Lets not block the feature because of this.
=== added file 'include/grub/bitmap_scale.h'
--- include/grub/bitmap_scale.h 1970-01-01 00:00:00 +
+++ include/grub/bitmap_scale.h 2009-01-31 20:18:45 +
@@ -0,0 +1,48 @@
+/* bitmap_scale.h - Bitmap scaling functions. */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2008,2009 Free Software Foundation, Inc.
New file. Change copyright to 2009.
+ *
+ * GRUB 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 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB 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 GRUB. If not, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef GRUB_BITMAP_SCALE_HEADER
+#define GRUB_BITMAP_SCALE_HEADER 1
+
+#include grub/err.h
+#include grub/types.h
+#include grub/bitmap_scale.h
+
+enum grub_video_bitmap_scale_method
+{
+ /* Choose the fastest interpolation algorithm. */
+ GRUB_VIDEO_BITMAP_SCALE_METHOD_FASTEST,
+ /* Choose the highest quality interpolation algorithm. */
+ GRUB_VIDEO_BITMAP_SCALE_METHOD_BEST,
+
+ /* Specific algorithms: */
+ /* Nearest neighbor interpolation. */
+ GRUB_VIDEO_BITMAP_SCALE_METHOD_NEAREST,
+ /* Bilinear interpolation. */
+ GRUB_VIDEO_BITMAP_SCALE_METHOD_BILINEAR
+};
+
+grub_err_t
+grub_video_bitmap_create_scaled (struct grub_video_bitmap **dst,
+ int dst_width, int dst_height,
+ struct grub_video_bitmap *src,
+ enum
+ grub_video_bitmap_scale_method
scale_method);
+
+#endif /* ! GRUB_BITMAP_SCALE_HEADER */
=== modified file 'term/gfxterm.c'
--- term/gfxterm.c2009-01-19 17:09:53 +
+++ term/gfxterm.c2009-01-31 20:28:20 +
@@ -27,6 +27,7 @@
#include grub/env.h
#include grub/video.h
#include grub/bitmap.h
+#include grub/bitmap_scale.h
#define DEFAULT_VIDEO_WIDTH 640
#define DEFAULT_VIDEO_HEIGHT 480
@@ -1095,8 +1096,18 @@
dirty_region_redraw ();
}
+
+/* Option array indices. */
+#define BACKGROUND_CMD_ARGINDEX_MODE 0
+
+static const struct grub_arg_option background_image_cmd_options[] = {
+ {mode, 'm', 0, Background image mode (`stretch', `normal')., 0,
+ARG_TYPE_STRING},
+ {0, 0, 0, 0, 0, 0}
+};
+
static grub_err_t
-grub_gfxterm_background_image_cmd (struct grub_arg_list *state __attribute__
((unused)),
+grub_gfxterm_background_image_cmd (struct grub_arg_list *state,
int argc,
char **args)
{
@@ -1123,12 +1134,36 @@
if (grub_errno != GRUB_ERR_NONE)
return grub_errno;
+/* Determine if the bitmap should be scaled to fit the screen. */
+if (!state[BACKGROUND_CMD_ARGINDEX_MODE].set
+|| grub_strcmp (state[BACKGROUND_CMD_ARGINDEX_MODE].arg,
+stretch) == 0)
Extra parentheses would be nice around grub_rtrcmp () == 0 compare.
+{
+ if (mode_info.width != grub_video_bitmap_get_width (bitmap)
+ || mode_info.height != grub_video_bitmap_get_height (bitmap))
This would benefit the same...
+{
+ struct grub_video_bitmap *scaled_bitmap;
+ grub_video_bitmap_create_scaled (scaled_bitmap,
+ mode_info.width,
+ mode_info.height,
+ bitmap,
+
GRUB_VIDEO_BITMAP_SCALE_METHOD_BEST);
+ if (grub_errno == GRUB_ERR_NONE)
+
Re: [PATCH] 4/5 Videotest enhancements
Colin D Bennett wrote: This patch improves the videotest command by adding a number of different tests for particular features. The 'videotest text' test tests the rendering of Unicode UTF-8 text, for instance, and the 'videotest bench' command runs a video performance benchmark. The original videotest command is accessed by executing 'videotest basic'. Please feel free to update videotest... The patch also adds the type 'grub_rect_t', which simply defines a rectangle and is required for the graphical menu patch. Actually the type was grub_video_rect_t... but it could be changed to grub_rect_t. Add year 2009 to copyright before commit if it wasn't there. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] 5/5 Graphical menu (gfxmenu)
Hi,
As this patch is quite large and I am going go to sleep soon so I only
comment your message on this run...
Colin D Bennett wrote:
This long-awaited patch adds graphical menu support to GRUB 2. It is
largely the result of my work during the Google Summer of Code 2008.
And thanks for it!
There are still a few important things that need to be done on gfxmenu
before it is completely ready for end-users (off the top of my head):
- Need a good way to switch themes at runtime. I want to add a popup
menu that lists the available themes and lets the user choose one.
(Currently the keys 1, 2, 3, and 4 are hardcoded to switch between my
sample themes...)
I think switching would need to validate new theme before taking it to
into use. When it is ok then it is safe to switch...
- gfxmenu interacts badly with gfxterm. Running commands from the
terminal withing gfxmenu that switch the video mode
('videotest basic', for instance) cause a crash when the command
returns. I think this has something to do with the interaction of
video mode-switching and the GRUB output terminal.
I have thought about this for some years... but still haven't
implemented it.
Basically it should work something like this:
state = grub_video_save_state()
change mode or what ever.
grub_video_restore_state(state);
State would have two parts. One is generic part that tells what video
driver to load and then second part is driver specific so it can restore
old video mode perhaps with same palette if in indexed color mode... but
contents of display does not need to saved. If there is no need to
perform any change on restore (eg. state matches) then no action is taken.
This should work also with text mode, so that at start before changing
video mode grub_video_save_state() would be called which records text
mdoe. And if graphical mode fails, then it would call restore with this
state. Now if there was graphical mode before this it would restore to
old working graphical mode.
The default theme is set in grub.cfg like so:
set theme=/boot/grub/themes/proto/theme.txt
I think it would be wise to pick some other theme extension that .txt.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: The ponderings of a newbie
Jay Sullivan wrote: 1) Mailing lists: I'm wanting to avoid asking questions that have already been answered, and I'd like to keep up on current issues with grub2, so I'd like to try to keep the grub-devel mailing list sorted...but I'm clueless. First of all, is it strange of me to ask, What email managers are everyone using? I'm more of a forum guy, so I find mailing lists hard to work with, and I'm hoping someone can clue me in on an email application that handles mailing lists properly. For example, on a forum, you can clearly see which messages were responses to which questions. But I can see the benefit of a mailing list, as everyone can use their own mail handlers... but I've tried to research things like sendmail, and my my brain nearly exploded. Is there a simple solution? Thunderbird + Threaded view for folder Automatically filter mailing lists to own folders ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove target_os
Javier Martín wrote: A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have $build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought to arise even with cross compilation enabled. AFAIK, the full power of $build+$host+$target only matters when building _compilers_ (and binutils, etc.), because you might want to use an AMD64/Linux machine to build a compiler that will run on PPC/Darwin but produce executables for a x86/Cygwin machine Now lets move this idea to GRUB 2: There is a build server is running on PPC/Linux and it wants to build all architectures supported by GRUB 2 (provide proper boot code for all arch and tools) and then makes software bundles (rpm,deb, or so) for all architectures. In example if all shell tools are to be ran on x86-64/Linux and then boot code needs to be compatible with x86-32 as there is PC-BIOS present on target system. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: State of GRUB on PowerPC
Michel Dänzer wrote: P.S. Please reconsider automatically rejecting posts from non-subscribers. I co-moderate half a dozen mailing lists, only costs me a couple of minutes a day thanks to a nice tool called 'listadmin'. grub-devel is a subscriber only list. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2 for DEC Alpha?
Matt Turner wrote: Hi, I learned today that GRUB 2 aims to be cross platform and already supports in some form PPC. Is there any interest in supporting the DEC Alpha (SRM) platform? If you are planning to provide the code for it and maintain it :) (or someone else). Alpha users currently use the long unmaintained aboot bootloader. Possibly code could be reused from aboot. We are using GPL v3. And that is not joy either to copy code... ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bugfix: no cursor on command line
phcoder wrote:
Testing grub I noticed this bug. Here is bugfix
Vladimir 'phcoder' Serbinenko
Index: normal/cmdline.c
===
--- normal/cmdline.c(revision 1959)
+++ normal/cmdline.c(working copy)
@@ -148,6 +148,7 @@
{
static char cmdline[GRUB_MAX_CMDLINE];
+ grub_setcursor (1);
grub_print_error ();
grub_errno = GRUB_ERR_NONE;
cmdline[0] = '\0';
I do not remember seeing a problem here. So what is actually the problem
and how to reproduce it?
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bugfix: no cursor on command line
phcoder wrote: I do not remember seeing a problem here. So what is actually the problem and how to reproduce it? I booted GRUB2 by GRUB-Legacy, command prompt appeared and worked but there were no cursor. I think the same problem appears when the user opens command line from the menu. Still not seeing this. There is already a call to grub_setcursor (1) at the beginning of this function... (and that was added somewhere in 2005)... I tried both graphical and text console and none seem to be affected. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Build system improvement
Javier Martín wrote: This patch modifies several files in the build system (mainly common.rmk and genmk.rb) to reduce the general verbosity of the build process to a manageable, semi-informative level. Thus, what currently appears as gcc calls, several lines long each is turned into lines like: [M xfs.mod] COMPILE ../src/fs/xfs.c - xfs_mod-fs_xfs.o [M xfs.mod] LINK xfs_mod-fs_xfs.o - pre-xfs.o [M xfs.mod] Looking for EXPORTED SYMBOL definitions: pre-xfs.o And so on. The change also makes warning-hunting marginally easier, though not by much since the patch intentionally shows a line for nearly every process that did so previously. This behavior could be simplified further if needed - this post is more of an RFC than anything else. Also, it is by no means thorough or complete - only the most common processes have been addressed - as I'm a bit busy with exams. The patch makes the new behavior the default one, so a new make-time option is added: V (for verbose), which must have the value 1 in order to get the behavior, as in make V=1 First of all I would like compiling process to be more tidier. However, what is the difference between Colin's similar patch? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: cmdline.c: ESC at any time exits: only mentioned once
jida...@jidanni.org wrote: Gentlemen, there is a serious usability problem with cmdline.c. At the very start the user sees the message made by grub_printf (\ [ Minimal BASH-like line editing is supported. For the first word, TAB\n\ lists possible command completions. Anywhere else TAB lists possible\n\ device/file completions.%s ]\n\n, nested ? ESC at any time exits. : ); This is kinda problem for translations anyway. So it would be preferable to have static text there... What is the overall gain for having nested to control output of that text? The problem is, just let him type help just once... The note about ESC at any time exits is now gone from the screen. He now faces a list of the help commands, with NO exit or quit choices. Now the question is, should we provide an exit command? Bash basically supports that so it could be a good idea. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: cat with pagination
Carles Pina i Estany wrote: Hello, On Jan/24/2009, Carles Pina i Estany wrote: In Grub command line I really miss a cat with pagination (like more/less). Any reason that it's not here? I don't remember if we discussed it. Or it's there and I have not found. I've just remembered set pager=1 and cat /boot/grub/grub.cfg :-) (from Grub console) Maybe a more command that would setup the pager, cat and remove the pager would be interesting for people who doesn't know about pager? (so doing TAB would appear a new command) Actually if we think about pager overall... it has a kinda failure also. It doesn't support aborting the print. There has been also a talk to enable pager=1 as a default. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: gettext patch (beta)
Carles Pina i Estany wrote: -I have seen that Grub2 is not printing correctly the accents, could be a problem in gettext or in some other layer Please provide example what is wrong and how it should look like. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] use grub-mkfont to create ascii.pf2 and unicode.pf2 if it's avaible
Felix Zielcke wrote: Here's a little patch for Makefile.in to use the new grub-mkfont to create the font files. Is it okay or is there a better way to do this? Please remove the java code toolchain with the same change. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Converter for the new font engine
Bean wrote: Hi, This patch converts existing font to pf2. It uses the freetype2 library, so it can support most common file format, like bdf, pcf.gz, ttf, etc. Usage: grub-mkfont [OPTIONS] FONT_FILES Options: -o, --output=FILE_NAMEset output file name -i, --index=N set font index -n, --name=S set font name -s, --size=N set font size -d, --desc=N set font descent -b, --boldconvert to bold font -a, --auto-hint enable autohint --no-bitmap don't use bitmap glyth -h, --helpdisplay this message and exit -V, --version print version information and exit -v, --verbose print verbose message Whoa... that was fast. I hope Colin didn't start yet with his implementation. Anyway. I think there needs to be support to specify ranges to font files do not bloat unneededly. Perhaps --range=0x1234-0x2345 ? (and allowing multiple of those) Btw. what does --no-bitmap do here? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Building a steady release cycle
Jerone Young wrote: Hey guys, I wanted to start up a discussion on building a steady release cycle. Many distros are now looking for some stability from Grub 2 as they are looking to include it in future releases. I was recently at the Ubuntu Developer Summit in December discussing the possibility of including grub 2 in future releases. One of the big concerns was that there was not a steady release policy working up to 2.0. I think it would be best to organize a release team which would then plan and explode release to tasks so people could grab one and develop them. Of course there should be some backup people that features really do get developed. Perhaps bi-weekly status checks would be a good idea to keep up with status of every feature. I can volunteer to be part of such team if decided to be started. Also this work should be visible so it would be easy for others to tag alone and help to develop missing features and to submit patches. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: incoming font engine update
Vesa Jääskeläinen wrote: Couple of days went and now patch finally went in. I have updated gfxterm part of the wiki to match new font enngine: I also moved common video subsystem code to common.rmk so that other architectures builds nicely too :) This does not however mean that all architectures features a graphical terminal. This is far from true. Only vbe.mod is there and it is used on x86-bios platform. So if you want that your platform supports graphical terminal I welcome you to develop a video driver to support it. In future this same interface will be used for graphical menu so that part is kinda kept architecture independent. Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GSoC #10 new font engine (UTF-8 support+bugfix)
Colin D Bennett wrote: On Fri, 2 Jan 2009 16:44:49 -0600 Jerone Young jer...@gmail.com wrote: I just paid attention to this (sorry). So everything seems fine. But the dependency on a proprietary java stack to generate fonts isn't good. Does it happen to work with gcc java ? The font tool does work with gcj (gcc's Java compiler). I just had to make a trivial change (see attached) since gcj 4.3.2 does not yet implement the String(byte[], Charset) constructor. Please feel free to make a commit with it. Just add Changelog entry. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Problem with fonts in different width
Colin D Bennett wrote: This would be fairly simple to do. The font would then effectively be a proportional-width font since the new font engine+gfxterm does not handle bi-width fonts in a character-cell environment. Actually it does :)... In a way at least. If you have lets say Hiragana glyphs which take 2 cells space will be displayed and acted like taking two normal characters. Basically the algorithm is: // determine normal cell width by analyzing ASCII character dimensions normal_cell_width = max_width(glyphs[32..127]); glyph_chars = (glyph.width + normal_cell_width - 1) / normal_cell_width; ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GSoC #10 new font engine (UTF-8 support+bugfix)
Vesa Jääskeläinen wrote: And the actual patch... ... went it. Instructions being updated... with another post when ready. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GSoC #10 new font engine (UTF-8 support+bugfix)
Jerone Young wrote: I just paid attention to this (sorry). So everything seems fine. But the dependency on a proprietary java stack to generate fonts isn't good. Does it happen to work with gcc java ? Paying attention is not a bad thing as such :) Never tried it myself but it should work. There isn't anything special on it. As long as Java 1.5 is being supported. Anyway... idea was to get rid of it as soon as possible. I just didn't feel right to hold features because of this. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GSoC #10 new font engine (UTF-8 support+bugfix)
Colin D Bennett wrote: Well, I don't have time right now to rewrite the converter; not for a couple of weeks, at least. I'm certainly willing to do it, so I'll get to it when I can, and then we can replace the Java converter. While we wait for that I have here a counter patch for the font engine. If there are no comments about it in near term this will be committed to SVN. To use automatic font conversion (unifont.bdf-ascii.pf2 and unicode.pf2), install bf-utf-source (ubuntu and probably debian). Font converter uses Java temporary. So when font compilation is enable font converter will be compiled and executed. Otherwise Java is not needed in anyway. Tested with Sun Java 1.6 on x86-64. grub-mkconfig should generate new grub.cfg with changed font commands. To convert custom fonts look for ascii.pf2 in Makefile.in and use matching commands to convert your fonts. These will be documented on Wiki once committed. 2008-12-28 Colin D Bennett co...@gibibit.com New font engine. Additional changes by Vesa Jääskeläinen ch...@nic.fi to adapt to build system and fixed gfxterm.c to work with different sized fonts. * configure.ac: Changed UNIFONT_HEX to UNIFONT_BDF. * configure: Re-generated. * DISTLIST: Removed font/manager.c. Added font/font.c. Added font/font_cmd.c. * Makefile.in: Changed UNIFONT_HEX to UNIFONT_BDF. Added Font tool compilation. * include/grub/misc.h (grub_utf8_to_ucs4): Changed prototype. Changed users. * kern/misc.c (grub_utf8_to_ucs4): Changed prototype. * kern/term.c: Changed users of grub_utf8_to_ucs4. * normal/menu.c: Likewise. * conf/common.rmk (font_mod_SOURCES): Removed font/manager.c. (font_mod_SOURCES): Added font/font_cmd.c, font/font.c. * include/grub/font.h: Replaced with new file. * include/grub/video.h (GRUB_VIDEO_MODE_TYPE_ALPHA): Changed value. (GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED): Likewise. (GRUB_VIDEO_MODE_TYPE_COLOR_MASK): Likewise. (GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP): Added. (grub_video_blit_format): Added GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED. (grub_video_mode_info): Added bg_red, bg_green, bg_blue, bg_alpha, fg_red, fg_green, fg_blue, fg_alpha. (grub_video_adapter): Removed blit_glyph. (grub_video_blit_glyph): Removed. * font/manager.c: Removed file. * font/font.c: New file. * font/font_cmd.c: Likewise. * video/video.c (grub_video_blit_glyph): Removed. * video/i386/pc/vbe.c (grub_video_vbe_map_rgb): Added 1-bit support. (grub_video_vbe_map_rgba): Likewise. (grub_video_vbe_unmap_color_int): Likewise. (grub_video_vbe_blit_glyph): Removed. (grub_video_vbe_adapter): Removed blit_glyph. * video/i386/pc/vbeutil.c (get_data_ptr): Added 1-bit support. (get_pixel): Likewise. (set_pixel): Likewise. * commands/videotest.c (grub_cmd_videotest): Added more tests for fonts. * term/gfxterm.c: Adapted to new font engine. * term/i386/pc/vesafb.c: Marked as deprecated. Made it compile. * term/i386/pc/vga.c: Likewise. * util/fonttool/src/org/gnu/grub/fonttool/BDFLoader.java: New file. * util/fonttool/src/org/gnu/grub/fonttool/CharDefs.java: Likewise. * util/fonttool/src/org/gnu/grub/fonttool/CharacterRange.java: Likewise. * util/fonttool/src/org/gnu/grub/fonttool/CharacterRange.java: Likewise. * util/fonttool/src/org/gnu/grub/fonttool/Converter.java: Likewise. * util/fonttool/src/org/gnu/grub/fonttool/Font.java: Likewise. * util/fonttool/src/org/gnu/grub/fonttool/Glyph.java: Likewise. * util/fonttool/src/org/gnu/grub/fonttool/PFF2Sections.java: Likewise. * util/fonttool/src/org/gnu/grub/fonttool/PFF2Writer.java: Likewise. * util/grub.d/00_header.in: Changed to use new loadfont command. * util/grub-mkconfig_lib.in: Changed font extension. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GSoC #10 new font engine (UTF-8 support+bugfix)
Colin D Bennett wrote: On Sat, 06 Dec 2008 22:18:14 +0200 Vesa Jääskeläinen ch...@nic.fi wrote: Colin D Bennett wrote: Update: I fixed an error pointed out to me by Y.Volta: In grub_font_get(), if no fonts are loaded, a null pointer is dereferenced. This is fixed in the attached patch. The grub_font_get() function now returns a dummy font object (a statically allocated font object with no characters) so that callers of grub_font_get() can be assured that the return value will never be NULL. If no fonts are loaded, then the unknown glyph will be used for all characters, but it will be safe. Hi Colin, I applied this patch against SVN today and tried it out. And noticed that gfxterm gets a bit broken after this. Was this the thing that I promised to look at :) ? Or was my merge just incomplete? There are two problems with gfxterm now: 1. unifont has problems rendering glyphs: they seem to be rendered too wide (maybe), and the cursor ends up being drawn after each character resulting in t_e_x_t_ _t_h_a_t_ _l_o_o_k_s like this. 2. With fonts that otherwise work (i.e. Fixed 10 for me), sometimes a few random junk characters with weird background/foreground colors show up in gfxterm -- mainly when it is first set as the terminal, leading me to think that there is some uninitialized memory. I think I have workable solution for these now in my local copy. Videotest was fine however. (or how fine it can be with just unifont.bdf) I should look closely at unifont.bdf and the .pf2 conversion and see why GRUB is rendering it weirdly in gfxterm. Actually what we want is to have improved conversion tool. If I make full conversion it generates ~1.7 MiB font file which does not fit to floppy. Now if we could specify unicode ranges what to put there it would make them smaller. This would be similar to how you specify ranges to old pff converter. I was planning to make such modification to handle near term goal. Actually it would be nice if converter tool would be in C. Then it could be compiled and executed easily during normal compilation process. Viewer application is not so important and it can be external to project . Same time with C implementation it would be easy to add compression there too. After: loadfont /boot/grub/unifont.pf2 lsfonts gives: Loaded fonts: Unknown -1 Is this expected? Yes, since there is no 'POINT_SIZE' or 'FAMILY_NAME' attribute in the unifont.bdf file. I added these manually, and it then showed up properly in the lsfonts listing (and can then be specified using the name/size in GRUB). Perhaps this addition should be moved to GNU Unifont's upstream? --- gnu-unifont-2008-04-06.bdf2008-12-22 08:48:00.0 -0800 +++ gnu-unifont-2008-04-06_tagged.bdf 2008-12-22 09:10:22.0 -0800 @@ -1,5 +1,8 @@ STARTFONT 2.1 FONT -gnu-unifont-medium-r-normal--16-160-75-75-c-80-iso10646-1 +FAMILY_NAME unifont +WEIGHT_NAME medium +POINT_SIZE 100 SIZE 16 75 75 FONTBOUNDINGBOX 16 16 0 -2 STARTPROPERTIES 3 The font converter should probably fall back on the file's name and the font's pixel size if such specifications are missing in the BDF file. Sorry for the delay getting back to you; now that the font patches are going in, I will be ready to continue work on submitting the graphical menu system patches. I've received e-mails from a number of people who have found my project web site and want to try out the graphical menu, and are asking when it will be merged into GRUB. I'll try to get them in. But I have to make it in way to normal grub operation do not break at same time. Temporary this means probably that toolchain is there in Java form unless you can make quickly the new converter. It can start without compression. What we want is to match functionality of old font converter. Eg. specify ranges and then generate file based on that one. Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
incoming font engine update
Hi All, I am about to integrate Colin's new Font Engine with additional changes to gfxterm. This means that current font tool chain will be obsolete and there will be new font commands to load fonts and so on. These will be detailed in more detail in later emails about the change. Side effects will be that font file format will change thus invaliding old fonts and it will affect font sizes too. Principal idea is to convert BDF fonts to GRUB 2 fonts. Normally used GNU Unifont is already provided in BDF form. This will open the needed path for GRUB 2 Graphical Menu developed by Colin. There are sill some patches that will need attention, but basically almost all ground work is after that ready. Next I will do some cleanup for the patch and try to commit it withing couple of days. Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Move kern/loader.c to boot.mod and add preboot_support (was Re: Sendkey patch)
phcoder wrote: Hello,all. I was busy studying so wasn't watching the list. Is there a particular reason why my patch still isn't incorporated? Perhaps we didn't like the move of loader/boot core functionality out of kernel? And I do not remember you describing in detail about interfaces and functional design of your idea. Tip: use threaded view to browse messages. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Contribution to Grub
Robert Millan wrote: On Tue, Dec 09, 2008 at 04:13:46PM +0530, Varun Deshpande wrote: hi I am interested to contribute something in open source. I would like to contribute something for grub. I downloaded source code of grub-1.96 in TODO file i got this mail id. I am very much familiar with C, C++, python, perl. I am completed my BE Computer from Pune University working with Marshall IT Services. This is my first time to work for open source i love to contribute for gruub Welcome! If you don't know how you could help, you might want to check the BTS at Savannah: https://savannah.gnu.org/bugs/?group=grub and maybe the one in Debian: http://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=0;src=grub2;dist=unstable;repeatmerged=0 That reminds me :) I updated a bit following wiki page: http://grub.enbug.org/ContributingChangesToGrub Comments are welcome if there is something missing or should be improved. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: configure fail for grub
James Shewey wrote: Grub will not currently compile on 64 bit distros. Try compiling with a 32 bit live cd or a 32 bit VM (you can try virtualbox.org for this) and then copying the requisite files to the 64 bit OS. I compile GRUB 2 SVN always on 64 bit Ubuntu... So please try with SVN version. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GSoC #10 new font engine (UTF-8 support+bugfix)
Colin D Bennett wrote: Update: I fixed an error pointed out to me by Y.Volta: In grub_font_get(), if no fonts are loaded, a null pointer is dereferenced. This is fixed in the attached patch. The grub_font_get() function now returns a dummy font object (a statically allocated font object with no characters) so that callers of grub_font_get() can be assured that the return value will never be NULL. If no fonts are loaded, then the unknown glyph will be used for all characters, but it will be safe. Hi Colin, I applied this patch against SVN today and tried it out. And noticed that gfxterm gets a bit broken after this. Was this the thing that I promised to look at :) ? Or was my merge just incomplete? Videotest was fine however. (or how fine it can be with just unifont.bdf) After: loadfont /boot/grub/unifont.pf2 lsfonts gives: Loaded fonts: Unknown -1 Is this expected? Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: I'm a newb, looking for guidance
Jay Sullivan wrote: Okay! I realized now that I would like to install the newest version of grub2 to a USB drive. Can anyone recommend to me the best way to do this? This seems like a good idea since if it fails to boot, I can easily fallback to my harddrive's bootloader. I'd like to point out that I'm currently having trouble getting started with grub2 development. The reason is that I currently have grub-legacy installed to my system, and I can't figure out how to get grub2 working properly and I have a feeling that they are conflicting. I have downloaded GRUB-1.96, and configured and successfully ran makefile, but if I run make-install will I overwrite grub-legacy? If not, how can I access the grub2 shell? I've attempted to install it but /usr/local/bin/grub still holds grub-legacy. Do I chainload core.img? Am I doing this whole thing wrong? Thanks and I'm sorry if I'm asking stupid questions =) These might help you: http://grub.enbug.org/TestingOnX86 http://grub.enbug.org/UseCases/Ubuntu On first url there is example how to boot grub 2 from grub legacy. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] --build-id= none in newer ld versions PowerPC
Manoel Rebelo Abranches wrote: This patch add --build-id=none option to newer ld versions when linking kernel.elf. This prevents grub-mkelfimage to behave wrongly. if test x$grub_cv_prog_ld_build_id_none = xyes; then MODULE_LDFLAGS=$MODULE_LDFLAGS -Wl,--build-id=none + PPC_BUILD_ID_FLAG=-Wl,--build-id=none fi ]) How about changing that to KERNEL_LDFLAGS? Then one could use it for other purposes if needed? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: I'm a newb, looking for guidance
Hi Jay, Welcome on the board! Jay Sullivan wrote: Hi, I'm very interested in helping out with the grub project, but I don't know where to begin! I've been interested in the project for a long time, but I try to respect people's time and I don't like to ask stupid questions until I've searched hard for the answers by myself. I've tried very hard to find good documentation for GRUB, but, erm..all of the decent tutorials out there are incomplete at best, and many of them make too many assumptions to be very helpful. I've read many tutorials but it seems like each one conflicts with the others. I assume you are wanting to help with GRUB 2. Well we have wiki. http://grub.enbug.org/ http://grub.enbug.org/ContributingChangesToGrub This is supposed to be central point for developer oriented information. There are parts that are outdated. So if you see something weird or would like to know something better, please ask so we can improve the wiki. First of all, I'm having trouble even understanding the grub architecture, and most of that is because I am constantly seeing conflicting information all over the internet due to the common fact that many people are ambiguous with which branch of grub they are referring to. Also, there seems to be a plague of broken and outdated links. For GRUB 2 there exists only one official development branch (there are others but basically we want to keep it as one branch). Idea for GRUB 2 is to promote other people to contribute patches to upstream. In general, though, I've found that grub is extremely underdocumented; but of the reading material which I have found to be at all helpful, there is a MAJOR tendency to overcomplicate things. I have a background in C and x86 assembly programming, and have had my fair share of device driving programming. I enjoy helping others track down bugs in their code, and I love writing idiot-proof tutorials (being the idiot that I am). I'm not afraid to sit down and read thousands of lines of code if that's what it takes to be up to date with the project. I just want to make sure I'm not headed in the wrong direction or anything. Ask what you want to know :) I remember reading a LONG time ago that the ETA for GRUB-2.0 was November 2008, and so I expected to start seeing a lot more tutorials devoted to helping people prepare for it, but this hasn't happened as quickly as I'd hoped. So I figured I would try to delve into the project and see what's REALLY going on. I would assume 2006 but hey :). So basically there are things to be done. There are different roles of developers. Some of them are developing specific features, and some of them are trying to catch up with features of GRUB legacy, and some just trying to follow the roadmap for GRUB 2. Which is kinda zapped at this time. Keypoint here is, what are your interests? What do you want to work on. Some pointers that we see missing: https://savannah.gnu.org/task/?group=grub http://grub.enbug.org/TodoList Oh.. before you start coding. Better start discussion on this list because there might be others working on the same thing, or there might be some ideas from long term developers how it should be made. I've only been using linux for a little over a year, and before that was a windows programmer (yes, I'm ashamed of my past), so I know I won't be much help as far as programming anything useful anytime soon. I can, however, offer to seek and hunt down typos or inconsistencies in the code comments, that is unless the grub team is against that idea. I think proper documentation is the key to any project's long term survival, and I take comments seriously and expect them to be unambiguous and at the same time not superfluous. Don't be shamed by your past. It is good to have variable development background. Documentation for GRUB 2 is missing so I have nothing against updating that one. However just walking the source code and trying to understand everything might be boring task. So I would prefer that take some of the bugs and see how they work (or why they wont) and then discuss it. Please skip bug reports about GRUB legacy and look at GRUB 2 issues if you go that path. https://savannah.gnu.org/bugs/?group=grub Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multi-terminal support (Re: [PATCH] terminal split)
Robert Millan wrote: On Tue, Nov 25, 2008 at 10:23:52PM +0100, Yoshinori K. Okuji wrote: I've been thinking... what if we make this generic? I.e. with an event loop, then terminals can register their poll functions to it, and write their stuff to a shared resource the rest of GRUB can read from. For inputs, this is trivial for me. But, for outputs, not simple. For example, although we don't support yet in GRUB 2, if we have a dumb terminal, the menu interface must be very different from others. Aside from the problem with output ones, what to you think of the event loop idea? It can be useful exploit the parellelism in hardware initialisations. Currently GRUB can do silly things like: - wait for keyboard controller in grub_keyboard_controller_read() and in grub_keyboard_controller_write() - move on - wait for ATA disk in grub_atapi_read() - move on - wait for _user_ to stare at the menu and pick an option - move on which could be avoided this way (instead of waiting, each function would register a hook that will be repeatedly run untill it returns non-zero). Well... I think better road would be co-operative multitasking. While waiting for hardware to respond you could give time to other tasks to handle their stuff. This would also make easier to write such tasks as you do not have to think about complex event system. System you propose can get quite complex to understand and maintain. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] PCI serial card support
[EMAIL PROTECTED] wrote: Bad news, I heard back from the two people who wrote the PCI serial code for Linux (Russell King Ted Tso) and they both agree that, no matter how the ambiguity got into the Linux source files, their intent was that the code was GPL v2 only. That being the case, we can't use the code and I don't want to try and re-write it from scratch so we're back to having the user manually specify the I/O port address but at least I can create a PCI ID table to map the base baud. Ok. Then I would suggest that only simple change is made at this time to support it. So we start from scratch on that implementation. Anyway... it can be improved later on. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] PCI serial card support
Robert Millan wrote: On Mon, Nov 03, 2008 at 04:38:02PM -0800, [EMAIL PROTECTED] wrote: The problem with using a PCI serial card for the console is that many PCI cards use a different crystal than the IBM PC standard. This means that serial drivers wind up computing the wrong divisor when trying to set the baud rate. This patch solves this problem by adding the `--base' parameter to the `serial' command. The allows you to set the base baud (typically the highest baud rate supported by the device) so that PCI cards with non-standard crystal frequencies can be supported. For example, the option I use with my PCI serial card is: serial --port=0xe880 --speed=115200 --base=921600 Is there no better way to do this than queriing the user? Can you read this info from the device itself, or from its PCI id? There are some serial boards where you have to give N * IO base addresses in order to support all N COMs. Actually there are even more complex cards than this one. Some supporting much higher than 921600 as maximum speed. Some needing even different kinds of formulas in order to get proper baud rates... But I think this should be good short term solution. More complex cards can have their own driver then. Thou base could be something different. As this is advanced feature it could be something more descriptive and harder to type... in example divbase, or maxbaud... Of course if we can detect some cards automatically we can store some table for those. For detection of PCI cases we could use PCI ID's. + return ((base 4) + (speed 3)) / (speed 4); Interesting formula. However. Whats the big gain against base/speed ? Perhaps I am missing something? This formula just gives +0.5 (rounding?) for resulting value which is then rounded down with integer maths. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] terminal split
Yoshinori K. Okuji wrote: BTW, I would like to obtain the capability of handling pipes, so that we can, say, help | more. I guess you have the same idea in your mind. This should be trivial, once the input and output are separate, right? I think this would need separated streams design in order to be functional. Not a bad idea as such I am wondering the gain however. What kind of implementation plan did you have for piping in example more? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] terminal split
Robert Millan wrote: Hi, This patch splits terminal handling in input and output. While at it, it resolves/removes some of the kludges we had to work around this limitation. For example, gfxterm/vga no longer need to assume the input is bios console, at_keyboard can be used in combination with any output terminal, etc. It will also be possible to turn vga_text.c into a standalone output term, but this needs more work since it is currently sharing much code with the bios console in console.c. I think multipath would be nice feature. Eg. you can have serial/other remote connected and then have local terminal at same time. This would allow remote maintenance for server and then if user is locally there he can operate machine too. For this there would need to be a way to say send output to these terminals and gather input from these terminals. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] framework for building modules externally
Robert Millan wrote: On Tue, Nov 04, 2008 at 08:55:52PM +0200, Vesa Jääskeläinen wrote: Robert Millan wrote: On Sat, Nov 01, 2008 at 01:32:29PM +0100, Robert Millan wrote: Hi, Attached patch makes it possible to build modules externally, by: - Installing headers in system include dir. - Exporting two ABI tags (a build-time macro and a run-time variable) for run-time comparison. - Exporting a makefile with COMMON_*FLAGS variables. Looks like I missed some important details. The headers and some macros are not enough, as we need to reproduce part of the build system to build a module externally. This new patch provides the following: Interesting idea. However how do you define GRUB ABI :) ? What is it, kernel, certain set of modules, or how :) ? Anything that can possibly break an external module. I.e. any interface exported by either the kernel or any of the modules. (I expect we'd bump this number a lot) Did you have some plan how to automate this ABI versioning :) ? If it is not automated I can almost guarantee that we get it wrong at one point of time :) Versioning of the modules would be a good idea indeed to make sure mismatched modules are not tried together. This should never happen if user always runs grub-install (which he should do anyway unless he's looking for trouble). My idea for external modules is that a separate package can put them in $pkglibdir and then grub-install will automaticaly include them the next time it's called. How do you treat differences in ABI ? Dis-allow loading of module with different value of ABI ? Or were you planning that module itself adapts to different versions of GRUB 2 ABI's? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GSoC #10 new font engine (UTF-8 support+bugfix)
Colin D Bennett wrote: On Fri, 31 Oct 2008 18:31:31 + Matt Sturgeon [EMAIL PROTECTED] wrote: will all these fonts be included in the next release of GRUB 2? Probably not; the licenses may not be compatible with GPLv3. These fonts are ones that came with X.Org on my system, and I just exported them to BDF files with 'xmbdfed' and then converted the BDF files to PF2 files with the GRUB font converter. Some of the fonts I used during my development of the graphical menu system are from the Artwiz bitmap font collection, which is a set of several fonts, but most all quite small in size (really no selection of font size within a font). I haven't spent a lot of time seeking out good free fonts that we could include in GRUB. I use the fabulous Liberation TrueType fonts on my desktop, but these are outline fonts, not bitmap fonts. I tried creating a bitmap font from some decent TrueType outline fonts using xmbdfed, but the results were quite ugly, so I gave up on that. Font issue is actually a bit problematic. At least there has to be some font somewhere that we can give to users so they can actually use graphical terminal :) Are there any free fonts that we can use ? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GSoC #09 Bitmap scaling
Colin D Bennett wrote:
On Tue, 14 Oct 2008 00:11:42 +0300
Vesa Jääskeläinen [EMAIL PROTECTED] wrote:
A minor point: You mentioned RGB and RGBA format--do you mean true
color (either RGB[A] or BGR[A] layout) or do you mean literal RGB byte
order? If we are talking about picking a single component order to
standardize on, it should be BGR[A]. Every video adapter I have tested
on so far (nVidia 7600GT, VIA Unichrome, VMware, QEMU) has supported
BGRA (32 bpp) or BGR (24 bpp) but not RGBA or RGB. Perhaps others have
found the contrary to be true; if so I would like to know.
As I stated before order is not an issue. We can use BGR[A].
I am just used to speak about RGB :)
As we have same handle all the time for bitmap we can just continue to
use it as is. If we would make new instance of it, would either need
to delete previous one and replace its usage with new one. Of course
use case here affects.
Ok. That's fine. I'm still a little confused about the purpose of
lock/unlock, however. Is it basically a way of catching mistakes in
the code where we accidentally try to modify bitmap data when we don't
want to? I guess what I'm asking is, do lock/unlock do anything more
than set a flag that is checked, as in: (pseudocode)
void *get_ptr(bitmap b)
{
if (b.optimized) return error();
return b.ptr;
}
void optimize(bitmap b)
{
if (b.locked) error();
/* optimize b... */
}
void lock(bitmap b)
{
if (b.locked) error();
b.locked = 1;
}
void unlock(bitmap b) { b.locked = 0; }
No, more like:
void *lock(bitmap b)
{
if (b.locked) return NULL;
if (b.optimized) return NULL;
b.locked = 1;
return b.dataptr;
}
void unlock(bitmap b)
{
b.locked = 0;
}
grub_err_t optimize(bitmap b, rendertarget r)
{
if (b.locked) return error;
if (b.optimized) return error;
// do magic
b.optimized = 1;
return success;
}
Now one would use it like:
ptr = lock();
if (ptr)
{
// modify it.
ptr[0] = blue;
ptr[1] = green;
ptr[2] = red;
if (has_alpha)
ptr[3] = alpha;
unlock();
}
Are you thinking that it would be best to have the
'optimize'/'unoptimize' operations actually just modify the bitmap
in place? I guess this is nice from a memory conservation
standpoint, but in some cases it wouldn't work well (i.e., 24-bit
to 32-bit formats).
I do not think at this point how optimize() or unoptimize() will be
implemented. Just general idea. Whether it is in-place operation or
re-allocation for memory, is same to me. It just have to work :)
Ok.
Another idea: What if the image-loading functions automatically
optimize()'d the bitmaps when loaded, since we don't normally expect to
modify loaded bitmaps before display. Then most all the bitmaps in use
would automatically get the performance benefit with no change to all
the users of the code. The only thing we do with loaded images is the
scale them and blit them.
No. If user has low color mode optimize will really make image look
ugly. So best to postpone this conversion to far as possible.
The scaling algorithms can easily work on any 24 or 32 bit color mode
without knowing details of which components are which (the process is
the same regardless of the color component). Thus optimized images
could still be scaled highly efficiently (without an
unoptimize-scale-optimize process). For 15/16 bit or indexed color
modes, we would have to unopt-scale-opt, but I really think that no
one should be using those modes. If your video memory is too limited
for 24 or 32 bit color, then just use the perfectly great text mode
menu.
I would still like to support all RGB modes. Indexed color modes are
just backup option.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: No scrolling for long input lines
Andy Goth wrote: Andy Goth [EMAIL PROTECTED] wrote: I'll test the current SVN this Friday, or perhaps Thursday night at the earliest. Actually I did spend time tonight investigating. I needed to get the latest SVN for another reason (about which I have questions I'll ask in a few days), so I went ahead and looked into my scrolling input problem. Yup, still there. Today's SVN is affected. The problem is present when actually booting using GRUB (ordinary VGA text mode), but it all works fine in grub-emu. Wait, I take that back. In grub-emu, typing very long lines (that wrap and *cause the screen to scroll*) results in the text wrapping at column 80 instead of column 79, so that there is *not* a white space character in the rightmost column. Pressing Ctrl-U from such a line will only erase only the bottom line of text, except for the first six characters (which presumably correspond to grub ). Something's flaky! However, this grub-emu stuff might be unrelated to the problem I've been having with the actual boot loader. I also add that in grub-emu, the carriage doesn't return after printing an error message, so I get a stairstep effect. With such an indented prompt, issuing a command like ls causes output to be printed to the *left* of the prompt. Enough about grub-emu. In the actual boot loader, I noticed that the pattern seems to be: it will scroll the screen if inserting text will cause the last character to overflow the right edge of the screen. That sounds like the way it should be, right? The problem is that only currently visible characters appear to be checked for overflow. This doesn't include the character being typed or characters that previously have failed to scroll onscreen. Test cases: 1. Near the top of the screen, type a bunch of text and overflow the edge. Works fine. 2. Hold down enter until the screen starts scrolling. Works fine. 3. Type a bunch of text and overflow the edge. Fails to scroll! 4. Use the left arrow key one or two times and type text. Fails to scroll! 5. Use the left arrow key until the cursor is onscreen, and type text. Everything scrolls into view. I'd absolutely love to debug all this and provide patches, but I really don't have time right now. In fact I didn't have time to do the research I did; I should have been sleeping. :^( This seems to be BIOS issue in a way. In startup.S grub_console_real_putchar there is quite good comment about what are BIOS limitations. Choices are to modify this code here, or make better bios console terminal. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GSoC #07 VBE double buffering (vs r1885)
Andy Goth wrote: Colin D Bennett [EMAIL PROTECTED] wrote: First make it work, then make it rock. I certainly do appreciate that, but... my plan is to avoid complicated dirty-region repaint strategies at first. Requiring full-screen repaints is an architectural design that might need rework to undo later. Or might not, depending on how you implement it. The interim approach you choose now should be informed by foresight. Full-screen repaint approach that will require rework later: - One function draws everything in sequence. It gets called every frame. Full-screen repaint approach that will be easy to integrate into a partial update scheme: - A separate function exists for drawing each logical unit of the screen. - Every frame, one function calls all the separate functions in sequence. Or something like that. Hi, I would like to thank Andy for his comments on the topic. I do share the same concern about designing double buffering to work properly without making hasty implementation first. We can use non-buffered solution as a first stage hasty implementation and design good enough solution to handle double buffering well. Dirty rectangles for every buffer (two in double buffer case) might be the best approach here. I think there is some kind of dirty rectangle implementation on gfxterm so that could be used as a base for this work. After that it could be improved to increase performance but the main point being that there has to be proper framework to make it work properly. Usually the slowest step is to transfer image data from main memory to video memory (and usually the slowest is to read from video memory to main memory and then save it back to video memory). If we can optimize memory copies between video and main memories we are on good track to solve speed problem. Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GSoC #05 Menu entry class attribute
Colin D Bennett wrote:
This patch adds support for a 'class' attribute on menu entries. It is
somewhat of a kludge, however since currently you just append
|class=this,that to the menu entry title to specify the classes.
Classes are used to provide a simple and flexible way for the best
available icon to be used in a graphical menu, but there are other
possible uses for them as well. The idea originates from the CSS
(cascading style sheets) and HTML 'class' concept.
Here is the patch snipped for using menuentry --class foo title { }.
Please try it out and see if it fits.
Index: normal/parser.y
===
--- normal/parser.y (revision 1885)
+++ normal/parser.y (working copy)
@@ -204,7 +204,7 @@
;
/* A menu entry. Carefully save the memory that is allocated. */
-menuentry: menuentry argument
+menuentry: menuentry arguments
{
grub_script_lexer_ref (state-lexerstate);
} newlines '{'
Index: normal/main.c
===
--- normal/main.c (revision 1885)
+++ normal/main.c (working copy)
@@ -148,13 +148,15 @@
}
grub_err_t
-grub_normal_menu_addentry (const char *title, struct grub_script *script,
+grub_normal_menu_addentry (int argc, char **args, struct grub_script *script,
const char *sourcecode)
{
- const char *menutitle;
+ const char *menutitle = 0;
const char *menusourcecode;
grub_menu_t menu;
grub_menu_entry_t *last;
+ int failed = 0;
+ int i;
menu = grub_env_get_data_slot(menu);
if (! menu)
@@ -166,10 +168,59 @@
if (! menusourcecode)
return grub_errno;
- menutitle = grub_strdup (title);
- if (! menutitle)
+ /* Parse menu arguments. */
+ for (i = 0; i argc; i++)
{
- grub_free ((void *) menusourcecode);
+ /* Capture arguments. */
+ if (grub_strncmp (--, args[i], 2) == 0)
+ {
+ char *arg = args[i][2];
+ char *value = 0;
+
+ /* Handle menu class. */
+ if (grub_strcmp(arg, class) == 0)
+ {
+ i++;
+ value = args[i];
+ continue;
+ }
+ else
+ {
+ /* Handle invalid argument. */
+ failed = 1;
+ grub_error (GRUB_ERR_MENU, invalid argument for menuentry: %s,
args[i]);
+ break;
+ }
+
+ }
+
+ /* Capture title. */
+ if (! menutitle)
+ {
+ menutitle = grub_strdup (args[i]);
+ }
+ else
+ {
+ failed = 1;
+ grub_error (GRUB_ERR_MENU, too many titles for menuentry: %s,
args[i]);
+ break;
+ }
+}
+
+ /* Validate arguments. */
+ if ((! failed) (! menutitle))
+{
+ grub_error (GRUB_ERR_MENU, menuentry is missing title);
+ failed = 1;
+}
+
+ /* If argument parsing failed, free any allocated resources. */
+ if (failed)
+{
+ grub_free ((void *)menutitle);
+ grub_free ((void *)menusourcecode);
+
+ /* Here we assume that grub_error has been used to specify failure
details. */
return grub_errno;
}
Index: normal/script.c
===
--- normal/script.c (revision 1885)
+++ normal/script.c (working copy)
@@ -206,7 +206,7 @@
The options for this entry are passed in OPTIONS. */
struct grub_script_cmd *
grub_script_create_cmdmenu (struct grub_parser_param *state,
- struct grub_script_arg *title,
+ struct grub_script_arglist *arglist,
char *sourcecode,
int options)
{
@@ -232,9 +232,9 @@
cmd-cmd.next = 0;
/* XXX: Check if this memory is properly freed. */
cmd-sourcecode = sourcecode;
- cmd-title = title;
+ cmd-arglist = arglist;
cmd-options = options;
-
+
return (struct grub_script_cmd *) cmd;
}
Index: normal/execute.c
===
--- normal/execute.c(revision 1885)
+++ normal/execute.c(working copy)
@@ -216,16 +216,33 @@
grub_script_execute_menuentry (struct grub_script_cmd *cmd)
{
struct grub_script_cmd_menuentry *cmd_menuentry;
- char *title;
+ struct grub_script_arglist *arglist;
struct grub_script *script;
+ char **args = 0;
+ int argcount = 0;
+ int i = 0;
cmd_menuentry = (struct grub_script_cmd_menuentry *) cmd;
- /* The title can contain variables, parse them and generate a string
- from it. */
- title = grub_script_execute_argument_to_string (cmd_menuentry-title);
- if (! title)
-return grub_errno;
+ if (cmd_menuentry-arglist)
+{
+ argcount = cmd_menuentry-arglist-argcount;
+
+ /* Create argv from the arguments. */
+ args = grub_malloc (sizeof (char *) * argcount);
+
+ if (! args)
+ {
+ return
Re: [RFC] Different keyborad layouts
Robert Millan wrote: Btw, what happened to the handlers patch? I thought it was about to be merged. Handlers has nothing to do with this :) That is still pending before we get more discussion about that :) Anyway... what you are after is multiple terminal inputs and outputs support. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GSoC #09 Bitmap scaling
Vesa Jääskeläinen wrote: Vesa Jääskeläinen wrote: It is really necessary that all generic graphical menu code like bitmap scaler works always. Not just for some optimized formats as otherwise it would render graphical menu unusable in some cases. It can be not so pretty on low end systems, but it should at least work. That is the reason there is map/unmap functions in video api. So there has to be first generic implementation and then you can use optimized one if there exist one. Just thinking as this is operating in a bitmap, we could just make sure we use only couple of formats and let video driver dot the rest. That would simplify it a bit. Hi, Now that Colin is back in action I am reviving this thread :). I have been thinking this a bit and I think best solution to bitmaps is something like following. Two types of bitmap: easily accessible and optimized bitmaps for hardware. Easily accessible are meant to be modified by user and provides slow blitting performance. Basically we should only support two formats. RGB888 and ARGB (order can be different). This way we can make easy code to modify bitmaps. When there is no need to modify bitmap anymore, one calls grub_video_bitmap_optimize(bitmap, rendering_target) and then bitmap is optimized to match reder_targets format. there would be two new helpers that gives access to bitmap data. grub_video_bitmap_lock() and to release it grub_video_bitmap_unlock(). Lock will fail if bitmap is optimized. I am wondering should we have grub_video_bitmap_unoptimize() to map back to editable mode. But that might be more pain and promote bad ways to do conversion. Now bitmap loaders would be modified to return data in easily accessible format so bitmaps can be modified and so on. Now to bitmap scaling. This can only be done for easily accessible formats and could be something like this: +grub_err_t +grub_video_bitmap_create_scaled (struct grub_video_bitmap **dst, + int dst_width, int dst_height, + struct grub_video_bitmap *src, + enum + grub_video_bitmap_scale_method scale_method); Now in example static bitmaps would be optimized right away in order to make their blitting fast. I do not know if we need special handling for transparent bitmaps. May need some experimenting. Actual scalers would be hidden from API and can only be specified by enum type. It could be a good idea to implement all scalers in same file. Unless there is some weird scaler that needs thousands of lines of code. Any opinions? Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Different keyborad layouts
Carles Pina i Estany wrote:
Hello,
I was thinking how we could have different keyboard layouts and after
have some ideas I sent some emails to Robert about this topic (who had some
better ideas :-) )
Let me to explain here some plan/design. I would like to research on it
after some weeks, but if we need some discussion we could have it before
:-)
(this is the result of some mails with Robert, so I'm copying/pasting and
changing some things, if I'm wrong Robert correct me!)
Plan:
- in term/i386/pc/at_keyboard.c we could have something like this:
static char english_map[] = { x, x, x };
char *map = english_map;
Explain this a bit more...
Remember that in some keyboard you need to press combos in order to
generate some character. Like in Finnish keyboard you press alt-gr + e
in order to generate euro sign (or alt-gr + 5). Also there are
multi-keypress sequences like in order to make '^' this sign you have to
press ctrl + '^' button and when released then press space. If you
happen to press in example 'a' after ctrl + '^' key you get 'â'. And I
do not think this is the only keyboard with this feature. Also there is
those dec input sequences like alt+number sequence. In example alt
(pressed) + '6', '5' you get 'A'.
- have a new module with different layouts and variable hook
- when user (or grub.cfg) change some variable (KEY_LAYOUT?), this module
would
redefine the term/i386/pc/at_keybord.c char *map to KEY_LAYOUT_map (es_map,
de_map, etc.)
I do not like the idea of using variable for this as it will most likely
require loading of keymap definition form disk. So I would prefer something:
insmod keymap
keymap /boot/grub/keyboard/fi
Also remember that you most likely want to play with scancodes when
transcoding keysequences. I would propose that you convert those
sequences to unicode so it would be easier to process. And if key is not
possible to code as unicode then some kinda of keyevent with flag that
this is eg. key up or something like that.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: localization of Grub
Robert Millan wrote: On Sun, Sep 28, 2008 at 11:49:54PM +0200, Carles Pina i Estany wrote: - gettextise the util tools, so they can be translated as normal programs. ok! (I guess/hope that will be more burocratic work than new work) It _is_ technical work I think, but less fun than the other part :-/ I don't expect to have time until 22th October (aprox.). I have more interest in the second part (it's newer) than first part, but first part has a practical and fast effects with (I think) less investment. The second part also builds on the first, to some extent. I.e. if you want to test gettext support in GRUB itself, you need some strings to translate, and these are provided by the .mo files which are only built if the build system supports that, etc. Before you guy's go too deep in detail I would like to remind special requirements for graphical user interface related to localization. You can't just printf stuff to screen in there. There has to be some changes in logic how information is presented to user. Currently there is lot of printf's in the code to display information and that is not going to be too pretty for graphical menu as we need to display some kind of console on event when there is something to be displayed. Also try to think how different languages differentiate for displaying certain types of information. Here is some simple example. (Bear in mind if there are grammatical errors or typos or so :)) (eng) See Figure 2 in page 14 for more details.' - (fin) Sivulla 14 olevassa kuvassa 2 on enemmän tietoa asiasta.' Please notice difference in order of arguments in the languages. Also there are some weird scripts that change order of characters. In example for some right-to-left scripts seem to have this feature. On example that I think belongs to this group is hebrew where they normally write from right-to-left, but for English (or foreign) texts are still visually correct. In example: nativeThis is native 1/nativeenglish2and this is English3/englishnative4, so weird./native Would be something like: .rdiew os ,42and this is English31 evitan si sihT So this subject really has more details than meets the eye in first sight :) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 summer code theme in debian?
Bean wrote: On Wed, Sep 24, 2008 at 12:19 AM, Vesa Jääskeläinen [EMAIL PROTECTED] wrote: J.Bakshi wrote: In my debian lenny, the grub2 has very simple look. I know it can be tweak to get ubuntu style graphical grub2 interface. After searchine google I have found the Grub2 summer code project 2008 and I have downloaded the theme folder. But I can't understand how to include the theme file in grub.cfg. Please let me know how to use those theme with grub.cfg. Integration of the Summer of Code 2008 codes are still work-in-progress. So at this time this is not possible. You have to wait a bit in order integration to be completed. Hi Vesa, The integration process seems to be halted, I wonder if there is something wrong. IMO, we can commit the patch if there is no serious breakage, we can fix minor issues later. I have been rather busy with other stuff. There is however some patches that could be looked independently. pretty make patch [PATCH] GSoC #03 Menu viewer interface [PATCH] GSoC #04 Multiple fallback entries [PATCH] GSoC #05 Menu entry class attribute - I do not like usage of '|' to separate arguments. So it would need to be either used as is, or menu parser would need work. I have started with those video subsystem improvements and have committed some of those (with modifications) already. And also some simple changes or bugfixes has already went. You can easily track patches with comments about commit that has went in. (I use threaded mail view to make things visually easy to process) There are still some video subsystem related stuff and then the new font engine that are next on my list. Also [PATCH] GSoC #10 font tools needs a bit discussion. And also can we use Lua for scripting (I think there is thread somewhere about that). Our second GSoC project for USB needs a bit more testing and perhaps some cleanups (Marco Robert any comments?). ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 summer code theme in debian?
J.Bakshi wrote: In my debian lenny, the grub2 has very simple look. I know it can be tweak to get ubuntu style graphical grub2 interface. After searchine google I have found the Grub2 summer code project 2008 and I have downloaded the theme folder. But I can't understand how to include the theme file in grub.cfg. Please let me know how to use those theme with grub.cfg. Integration of the Summer of Code 2008 codes are still work-in-progress. So at this time this is not possible. You have to wait a bit in order integration to be completed. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: setting the system clock before launching operating system
Daniel Kahn Gillmor wrote: On Sat 2008-09-13 00:52:47 -0400, Arthur Marsh wrote: Vesa Jääskeläinen wrote, on 2008-09-13 00:13: Geoff Karl wrote: I would like to be able to set the clock to a particular time automatically before launching an operating system. Anyone have any ideas if this can be done during the boot loader process? Yes it can be done. But why? Some machines (e.g. a Compaq Armada 1750) don't have the option to set the time via BIOS or set-up boot floppy. When the time had been lost, I'd have start-up problems with fsck checking when the file system had last been checked. The same is true for many older PowerPC machines whose mainboard batteries have begun to fail. Being able to automate the bootloader to say look, if the hardware clock thinks it is 1904 (or 1900, or 1970, or anytime before the turn of the century) it is probably wrong; set it to at least 2008 at every boot would be pretty useful. Well... replace the battery ;) This is especially useful on 32-bit architectures with a default hardware epoch date so far in the past that crappier NTP implementations think that it's actually in the future. I've dealt with this at the OS level (for various OSes) on older PowerPC machines, and it's doable, but a pain. Being able to guarantee that no matter what OS you're booting, the initial clock will be at least set to time X would be pretty handy. ...and update your NTP software ;) Should we one day support NTP time synchronization within GRUB 2, then it would be usable. Personally I do not see need for this. I would propose that you use your OS startup script to handle this case in case you refuse to/can't replace your battery. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: setting the system clock before launching operating system
Geoff Karl wrote: I would like to be able to set the clock to a particular time automatically before launching an operating system. Anyone have any ideas if this can be done during the boot loader process? Yes it can be done. But why? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: About VBE double buffering
y.volta wrote: I noticed that `grub_vbe_bios_set_display_start () which used AX=4F07h INT10h' used in the fancy menu patch. This will use the video buffer to do buffering, but this function will fail on some system, Collin told us in his Journal: However, VMware doesn't seem to support the VBE set display start operation, at least in the video mode that GRUB uses (for the basic video test, which uses indexed color 1024x768 mode). so, this may have compatible issue. i think, is there any possible, use a non-video-card memory to be the drawing buffer, when done, we copy its contents to video memory? this obviously has performance issue, but has more compatible. It will have backwards compatibility mode if not available. And before I will commit any change to support hardware double buffering I will make sure it works in qemu/vmware/my hardware so do not worry about that one. Furthmore, i suggest, we should implement the bank-switch function in VBE framework, for there are a few system's video card may have no LFB modes. for example, here is a card i meet: ( i gathered 22 cards, it is only one without lfb in each modes; many cards have no lfb in 4 colours mode. ) As I said previously, I have no plan to work with bank switch functionality. You are however free to do so. And please state what card you had? I am pretty surprised that you got vbe3.0 there and no LFB. Oh... and I pretty much don't care about 4 color modes ;). In my opinion they shall be unsupported. 256 index color in minimum feasible for any use. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Move normal, serial pci to i386.rmk
Pavel Roskin wrote: I believe we could declare SPARC broken, but keep PowerPC working. The PowerPC code can be cross-compiled and tested in qemu. I can send my testing scripts if you want. Can you put that on Wiki? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Move normal, serial pci to i386.rmk
Robert Millan wrote: On Mon, Sep 08, 2008 at 10:49:02AM -0400, Pavel Roskin wrote: Quoting Robert Millan [EMAIL PROTECTED]: This patch moves normal, serial and pci to conf/i386.rmk. Why i386? That code is not i386 specific. It is. Notice it's being moved from conf/i386-*.rmk, not common.rmk. normal: Includes normal/i386/setjmp.S Should we move this out of normal.mod ? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Release Plan update...
Robert Millan wrote: On Sun, Sep 07, 2008 at 08:12:02PM +0300, Vesa Jääskeläinen wrote: Hi All, As our release plan is rotting a bit, I zapped current plan on Wiki and here is my proposal for plan targetting 2.0 gold release. == 1.97 == Estimate Date:: 2008-??-?? (ASAP) Release Focus:: General release. Improving usability and stability. == 1.98 == Estimate Date:: 2009-??-?? (2009 new years release :) ?) Release Focus:: Integrating USB and Graphical Menu to baseline. Improving usability and stability. Where do we put the handlers patch, and the move code off startup.S one? Anywhere where when they are ready. They aren't really important for functionality. They are just improvements. Note:: We would like to claim that GRUB 2 is ''beta'' at this stage. ''beta'' means that GRUB 2 has the same usability as GRUB Legacy. I think we surpassed GRUB Legacy in usability already ;-) We are still missing network and password support at least :) (Thou that was copy paste from previous milestones ;)) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Move kern/loader.c to boot.mod and add preboot_support (was Re: Sendkey patch)
phcoder wrote: Hello. As I said in another email there is no need for it. I send a patch for it. Doesn't this break our rescue mode ? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Move kern/loader.c to boot.mod and add preboot_support (was Re: Sendkey patch)
Javier Martín wrote: El lun, 08-09-2008 a las 22:48 +0300, Vesa Jääskeläinen escribió: phcoder wrote: Hello. As I said in another email there is no need for it. I send a patch for it. Doesn't this break our rescue mode ? How would it? As with other commands, there would be two versions of it, one for rescue and one for normal. Besides, what is the point in having the boot command in kernel -and thus always available- if you can't load a kernel to boot? You may want to chainload something? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Release Plan update...
Hi All, As our release plan is rotting a bit, I zapped current plan on Wiki and here is my proposal for plan targetting 2.0 gold release. == 1.97 == Estimate Date:: 2008-??-?? (ASAP) Release Focus:: General release. Improving usability and stability. == 1.98 == Estimate Date:: 2009-??-?? (2009 new years release :) ?) Release Focus:: Integrating USB and Graphical Menu to baseline. Improving usability and stability. == 1.99 == Estimate Date:: 2009-??-?? (mid 2009?) Release Focus:: Feature catchup from GRUB Legacy. Serious stabilization and documentation. Note:: We would like to claim that GRUB 2 is ''beta'' at this stage. ''beta'' means that GRUB 2 has the same usability as GRUB Legacy. == 2.00 == Estimate Date:: 2009-??-?? (2010 new years release :) ?) Release Focus:: Serious stabilization and finalize documentation. Note:: GRUB 2 is now ''gold''. Official major release intended to replace GRUB Legacy in mainstream use. Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: When the 'Fancy Menu' branch will be availble on the main thread?
y.volta wrote: hi, all: Collin has submit the 'Fancy Menu', when it will be available on the main svn thread? When it gets reviewed and merged. I have been slowly adapting some of the patches to my local devel tree so they can get committed. However I need to make sure they are architectually correct and that takes time. If changes are more radical then we wait that we have improved patches. And i want to make sure: - the fancy menu will support two bytes language? Unicode support is built in. Other than English script (eg. character positioning) is not supported however. It should be good enough for most of the languages on world (eg. Japanese, European, US), but is not working properly on more challenging ones like Hebrew and Islam - the vbe engine support non linear frame buffer modes? i read the vbe.c line 445: /* We support only linear frame buffer modes. */, if so, the graphic menu will not be available for some hardware or screen resolution. I have no plans to write support for banked modes. - grub video uses double buffering, if this is available. if not, the bliting will be very slow. so, how about using clip-box to improve it? backup area - draw contents - recover area - draw new contents. ( by using this, there is no need to switch a whole screen. ^_^ ) There is similar feature in gfxterm. We will first get this merged and then we worry about performance. - can the VBE engine support 16 bits (5:6:5) mode? Yes. Thou, there are no accelerated functions for it, so it will be slow. i've not familiar with grub2's video system, so, please help me out. Thanks! http://grub.enbug.org/VideoSubsystem ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Can LUA e coming with future Grub2
Robert Millan wrote: On Wed, Sep 03, 2008 at 04:25:12PM +0800, Bean wrote: On Wed, Sep 3, 2008 at 12:56 PM, y.volta [EMAIL PROTECTED] wrote: For the Grub2 internal script engine, yes, it is little. but need more work to be improved. About the size, i think, Lua can be a replacement if this lua.mod is available at runtime. at the same time, why not load gziped mod file from disk? this will reduce the size of lua module: 100,436 bytes - 49,766. But the benifit of using Lua, i think, is for graphic menu. the gfxmenu uses a strange script engine, it is hard to learn for a common user; but the Lua, it is easy. ;-) So, it is good to have lua support in Grub2. Hi, In my suggestion to split normal mode, the script engine is separated and can be replaced, as long as they export a certain interface that return information like the menu items, etc. But now, I'm waiting for the handler patch, as it's the basic of the new model. Note that size is still an issue, though. For example coreboot users will usually want to use scripting for the grub.cfg they store in their ROM. Hi, I like the idea of using Lua personally for graphical menu related scripting and in my opinion it could be additional script that could be used. User could in example defined scripting language in a bit same way that you do that in HTML pages: lua:script-filename.lua grub:exec grub-script-filename own-extension:do this and this effect that is integrated to some other module In order to one of those work, you need to load script module that registers handler for it. Do anyone have skills to decipher Lua's license is it compatible with GPLv3 ? Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Boot parameters and geometrical stability
phcoder wrote: I was thinking about the scenario when ide drives are trusted but not USB or removable devices. Cryptographic checksums wouldn't bring much because if attacker can modify harddrive he can also modify GRUB to skip checksum check. Then you password protect it :) Once that is supported. But really, if attacker has access to your HDD then there is not a really reason why we should do defense against that one as they can overwrite us at will. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Boot parameters and geometrical stability
phcoder wrote: But consider a scenario when attacker can't overwrite the existing harddrive but can plug new one. Then the attacker can prepare a harddrive having a partition with the same UUID as our boot partition. Then he plugs it and depnding on factors like order of interfaces, devices, phase of the moon, ... GRUB can load attacker's modules. While it's ok to use UUID on personal desktop system when attacker can't plug his devices it shouldn't be the default. That is a valid point. Would you prefer to use hardware path to device or what you had in mind then? Because this is something that we can left for expert people. Most common problem is that user plugs in new drive to system and bios/hardware order gets changed or something like that, and that renders system unbootable. UUID is perfect solution for that case. Possibilites are there, but basically they are limited to something like: (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0) I do not know if those all would be valid, but I hope you get the idea. Alternative would be that you integrate some module to core that validates your system that there is no extra devices or such. Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
