Vesa Jääskeläinen <[EMAIL PROTECTED]> writes:
> Here is the newest modifications to video subsystem.
Hi Vesa. What a suitable name :)
Sorry for the delay, and lack of earlier comments, but I've been out
of the GRUB loop for a while. But I have a few comments on the video
subsystem;
Correct me
Vesa Jääskeläinen <[EMAIL PROTECTED]> writes:
> But the idea here was to make it easier to make function that operates
> on different render targets without knowing about it. eg:
>
> set_target a
> call common_func
> set target b
> call common_func
> set target c
>
> With your proposal this would
Marco, Okuji, could someone of you maybe commit this?
(Yes, I _KNOW_ I'm using the address I'm changing from, but I'm too
lazy to re-subscribe to the list with "new" address.)
2006-06-30 Johan Rydberg <[EMAIL PROTECTED]>
* THANKS: Update Johan R
Johan Rydberg <[EMAIL PROTECTED]> writes:
> --- ChangeLog 13 Jun 2006 22:50:00 - 1.284
> +++ ChangeLog 30 Jun 2006 16:04:30 -
I did not mean to send in the patch for ChangeLog. Sorry for that.
~j
___
Grub-devel mailing lis
Hi,
I would like to have the following patch committed. Some EFI
implementations do not provide a console control protocol instance,
and it is covered by neither EFI or UEFI specifications.
~j
2006-07-28 Johan Rydberg <[EMAIL PROTECTED]>
* kern/efi/efi.c (grub_efi_set_tex
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
>> I would like to have the following patch committed. Some EFI
>> implementations do not provide a console control protocol instance,
>> and it is covered by neither EFI or UEFI specifications.
>
> Right, right. My code was only for testing, so it
Hi,
Instead of generating the dependencies separately it can be done the
first time a file is compiled, with the -MD option to GCC.
Comments?
2006-08-12 Johan Rydberg <[EMAIL PROTECTED]>
* genmk.rb: Let GCC generate dependenceies the first time it
compiles a file; usi
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> I don't remember precisely, but I think I only added disk devices but not
> partition devices. On your system, don't disk devices as well as partition
> devices get enumerated?
I'm not 100% sure about this, but I think EFI does not have to add
Marco Gerards <[EMAIL PROTECTED]> writes:
>> I agree; I think there are far better replacements for CVS. Personally I
>> would highly recommend mercurial, but I suppose everybody has their own
>> preferences. I noticed that Savannah, where the GRUB tree is currently
>> hosted, offers subversion su
Hi,
In other projects that I've worked on, we've used a system where the
core developers can either give a +1 or a -1 on a contributed patch.
If a patch receives two +1's or more, it is accepted (if there are no
-1's) and committed by one of the developers.
This lowers the pressure on the maint
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> On Saturday 12 August 2006 18:07, Johan Rydberg wrote:
>> Instead of generating the dependencies separately it can be done the
>> first time a file is compiled, with the -MD option to GCC.
>
> That sounds
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> Our rules are:
>
> - When you are a committer and a patch is trivial enough, you can
> (and should) check in the patch by yourself.
>
> - If not, you should ask others in grub-devel.
It was for these two scenarios I suggested we could vote on pat
Marco Gerards <[EMAIL PROTECTED]> writes:
>> The last CVS dated June 14 2006 compiles fine.
>
> Sorry, but I do not really understand you. Which CVS snapshot do you
> mean? With the last statement you mean your problem was fixed in CVS?
I think he means that a CVS checkout of June 14 worked jus
Robert Millan <[EMAIL PROTECTED]> writes:
>> I'll commit it in a few days, or when you (or someone else) confirms
>> that it works.
>
> Confirmed.
Committed.
~j
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gru
[EMAIL PROTECTED] writes:
> this is a port of grub2 to ia64. ia64 systems (itanium) are EFI
> based so this port reuse existing EFI infrastructure.
Thank you for offering this contribution.
First a few legal comments. I poked through the patches, and it seems
that there are a few files that ar
[EMAIL PROTECTED] writes:
> some systems have a really big memmap. This patch remove the memmap
> size limit.
Overall the patch looks good, I have one comment through; (the patch
is for kern/efi/mm.c if someone wonders.)
+ memory_map = grub_efi_allocate_pages
+(0, 2 * BYTES_TO_PAGES (memor
[EMAIL PROTECTED] writes:
>> It is not possible to find similar integer division code in glibc for
>> example? And why is this code needed at all, doesn't IA64 have
>> division?
> No, it doesn't have integer division.
>
>> If it doesn't, my gut feeling tells me that this should be
>> in libgcc.
Marco Gerards <[EMAIL PROTECTED]> writes:
>> + memory_map = grub_efi_allocate_pages
>> +(0, 2 * BYTES_TO_PAGES (memory_map_size + 0x1000));
>>
>> I suppose you add 0x1000 to round it up. Maybe we should change
>> the BYTES_TO_PAGES macro to do roundup.
>
> Agreed. Can you make this change a
[EMAIL PROTECTED] writes:
> 2006-09-28 Tristan Gingold <[EMAIL PROTECTED]>
>
> * kern/misc.c (grub_strtoull): guess the base only if not specified.
>
Committed.
pgp9sQVY4rill.pgp
Description: PGP signature
___
Grub-devel mailing list
Grub-deve
Marco Gerards <[EMAIL PROTECTED]> writes:
> Iterating over files:
> for x in (hd0,3)/foo/* ; do commands ; done
I must say I would prefer this over the other ("foreach") suggestion,
since I'm more used to it.
Anyhow, is your plan to make expansion available through out the whole
shell, or only
Marco Gerards <[EMAIL PROTECTED]> writes:
> =
> Variables
> =
>
> - root: The active disk/partition (rw, global)
> ...
What about a 'prompt' variable?
~j
pgpf6nhSSgEl9.pgp
Description: PGP signature
___
Grub-devel mailing list
Grub-de
Johan Rydberg <[EMAIL PROTECTED]> writes:
> Anyhow, when I get a few more minutes over I'll try to review your
> patches more in depth.
A few comments;
* Would it be possible for you to rewrite kern/ia64/efi/startup.S,
so that you hold the copyright for it?
* Same goes
Jeff Bailey <[EMAIL PROTECTED]> writes:
>> > Anyhow, when I get a few more minutes over I'll try to review your
>> > patches more in depth.
>>
>> A few comments;
>>
>> * Would it be possible for you to rewrite kern/ia64/efi/startup.S,
>>so that you hold the copyright for it?
>>
>> * Sam
Tristan Gingold <[EMAIL PROTECTED]> writes:
> the code to relocate is used by grub to relocate itself. On EFI systems
> programs can be loaded at any address (physical mode).
You're telling me that EFI on your IA-64 system does not relocate the
program before start executing it? That sounds str
Tristan Gingold <[EMAIL PROTECTED]> writes:
>> You're telling me that EFI on your IA-64 system does not relocate the
>> program before start executing it? That sounds strange.
>
> It does relocate EFI PEI images. Unfortunatly there is no tools to create
> EFI PEI objects on Linux. The gnu efi t
Tristan Gingold <[EMAIL PROTECTED]> writes:
> On Thu, Oct 12, 2006 at 02:11:57PM +0200, Johan Rydberg wrote:
>> Tristan Gingold <[EMAIL PROTECTED]> writes:
>>
>> >> You're telling me that EFI on your IA-64 system does not relocate the
>> >>
"bibo,mao" <[EMAIL PROTECTED]> writes:
> Previously I posted this patch, now I repost again.
> Any suggestion is welcome.
I will just give a comment here. Please do not treat it as a full
review, I'll leave that to Okuji.
> +static int compare_ancestor_path(const grub_efi_device_path_t *paren
"bibo,mao" <[EMAIL PROTECTED]> writes:
> This patch moves find_mmap_size from i386/efi/linux.c to
> kern/efi/mm.c, and renamed as grub_efi_find_mmap_size, so that
> other arch on EFI platform can use this function.
Good call.
> Also this function solves memory map too small problem,
> on some EF
Johan Rydberg <[EMAIL PROTECTED]> writes:
> This code can be shorter; you only have to compare the lengths. If
> they match, you can do a memcmp on the whole device path.
It could look something like this;
/* Returns zero if device path SUBPATH is a subpath of device path
PATH
Hollis Blanchard <[EMAIL PROTECTED]> writes:
>> The idea is very good. But I don't like that loaded areas are always
>> allocated
>> from the heap. GRUB has a staging area for OS images on i386-pc, and I
>> prefer
>> to load an image directly instead of consuming the heap.
>
> Actually I'm not
Hollis Blanchard <[EMAIL PROTECTED]> writes:
> --- grub2-cvs.orig/include/grub/types.h 2006-10-31 19:06:47.0
> -0600
> +++ grub2-cvs/include/grub/types.h2006-10-31 19:06:58.0 -0600
> @@ -23,6 +23,8 @@
> #include
> #include
>
> +#define __unused __attribute__ ((unus
Hollis Blanchard <[EMAIL PROTECTED]> writes:
>> int
>> grub_foo (int x, unused int foo)
>> {
>> ...
>> }
>
> I believe gcc attributes can't be used as naturally as this; it would
> have to be "int unused foo" or "int unused *foo" (from memory).
[EMAIL PROTECTED]:~/tmp/t5 $ gcc -Dunuse
Jeroen Dekkers <[EMAIL PROTECTED]> writes:
> Any ideas for a new name for the define? Something like "grub_unused"?
"UNUSED" ?
~j
pgpvJUkjmvaQn.pgp
Description: PGP signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman
Hollis Blanchard <[EMAIL PROTECTED]> writes:
> For kernels that need to communicate information to GRUB (e.g.
> "vga_mode" from my previous email, or a.out load addresses), the
> multiboot header would be needed for GRUB to locate the parameter area
> within the executable.
My two cents;
In MB2
Joe Bonasera <[EMAIL PROTECTED]> writes:
> Hollis Blanchard wrote:
>
>> GRUB2's 'multiboot' command will load ELF64 files, so the "a.out
>> hack"
>> shouldn't be necessary for you in the future.
>
> That's fine and will let us delete a small amount of code from both
> the kernel startup sequence a
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> On Saturday 25 November 2006 04:33, Hollis Blanchard wrote:
>> That's exactly the point: there will be no difference. Both
>> architectures will use 64-bit types.
>
> No. Both should use 32-bit, because GRUB transfers control in 32-bit mode.
> Pa
"bibo,mao" <[EMAIL PROTECTED]> writes:
> If kernel image is bzImage, x64 efi bootloader need switch to 32 bit
> protect mode(or real mode) from 64 bit long mode, and if kernel
> image is gzipped/plain format, efi bootloader can directly jump to
> 64-bit kernel entry address without mode switch.
M
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> As you may know, Google Summer of Code 2007 is about starting:
Are we suggesting any tasks that could be done by the student(s)?
~j
pgpM0fH6Xw1ri.pgp
Description: PGP signature
___
Grub-devel mailing
"Hitoshi Ozeki" <[EMAIL PROTECTED]> writes:
> GRUB 1.95 cannot read the ufs filesystem.
> Because, 1.95 mistakes a usage of char pointer.
> This patch fixes this problem, and make it a bit better.
Thanks for you contribution.
> Attached file: ufs.patch.gz (1Kbytes)
In the future, could you mayb
"Hitoshi Ozeki" <[EMAIL PROTECTED]> writes:
> Hello, all.
>
> GRUB 1.95 cannot read the ufs filesystem.
> Because, 1.95 mistakes a usage of char pointer.
> This patch fixes this problem, and make it a bit better.
Could you maybe point out the problem for us? Personally, I think the
use of pointe
"Hitoshi Ozeki" <[EMAIL PROTECTED]> writes:
> At first, When we use the 'strcmp' for the purpose of comparision C-strings,
> It requires to terminate with the NIL sentry('\0').
>
> begin---
> grub_ufs_find_file (struct grub_ufs_data *data, const char *path)
> {
>
"Hitoshi Ozeki" <[EMAIL PROTECTED]> writes:
> At first, When we use the 'strcmp' for the purpose of comparision C-strings,
> It requires to terminate with the NIL sentry('\0').
>
> begin---
> grub_ufs_find_file (struct grub_ufs_data *data, const char *path)
> {
>
"Alex Roman" <[EMAIL PROTECTED]> writes:
> I've cleaned up the code and created a patch which will enable allow
> booting from the first CD-ROM on a system. This is my first patch so I
> checked my code many times... hopefully it won't cause unwanted side
> effects, and hopefully my patch is in th
Marco Gerards <[EMAIL PROTECTED]> writes:
> If I do not get any comments within a week, I'll just commit the
> patch. >
I have a few more comments;
> +#include
> +#include
> +
> +enum grub_memstack_type
> + {
> +GRUB_MEMSTACK_TYPE_ETHERNET,
> +GRUB_MEMSTACK_TYPE_IPV4,
> +GRUB_ME
Marco Gerards <[EMAIL PROTECTED]> writes:
> If I do not get any comments within a week, I'll just commit the
> patch. >
I have a few more comments;
> +#include
> +#include
> +
> +enum grub_memstack_type
> + {
> +GRUB_MEMSTACK_TYPE_ETHERNET,
> +GRUB_MEMSTACK_TYPE_IPV4,
> +GRUB_ME
[EMAIL PROTECTED] writes:
> During work on EFI, I have written a standalone ELF to PE/COFF converted. I
> still have to mark it work within the grub framework. Not a lot of work but
> it requires a few hours.
IIRC, we already have a ELF to PE/COFF converter in GRUB. Look at
util/i386/ef
46 matches
Mail list logo
