2009/8/14 Vladimir 'phcoder' Serbinenko :
> On Fri, Aug 14, 2009 at 4:04 PM, Michal Suchanek wrote:
>> Hello
>>
>> I am sending the rest of framebuffer patches that were not included in
>> the split by Vladimir.
>>
>> remove-dup-function.patch
>>
>> * video_fb.c: remove grub_video_fb_get_video_ptr
On Fri, 2009-08-14 at 22:53 +0200, Vladimir 'phcoder' Serbinenko wrote:
> Hello. Currently afs and befs modules handle both big and little
> endian variants. Here is a patch to split into 2 modules.
> Unfortunately I wasn't able to find easily-available big-endian images
> to test but it shouldn't
On Thu, 2009-08-13 at 02:24 -0400, Pavel Roskin wrote:
> > Since Yves is interested perhaps he could do the "dirty job" of
> > applying repetitive fixes and testing different images? And submit a
> > patch then?
>
> Fine with me.
I have fixed the *.img files other than kernel.img, but there is s
Hello. Currently afs and befs modules handle both big and little
endian variants. Here is a patch to split into 2 modules.
Unfortunately I wasn't able to find easily-available big-endian images
to test but it shouldn't be a huge problem since we currently don't
boot corresponding OS on big-endian m
Hello. As I mentioned in my previous e-mail there seems to be a
problem in how HFS manages file->offset. Similar problems seem to
affect other filesystems as well. The similar check is already done in
kern/file.c I extend it to check for offsets past the file too and
eliminate the check in filesyst
Hello. When search encounters an unknown filesystem or filesystem
without partition it triggers fs module autoload which takes
noticeable time. To improve the situation I propose (after discussing
with Robert Millan) to first search without autoloading modules if we
need to find only one device (wi
>> > 2) The Memory Map information under GRUB2 seems to be "zeroed" which
>> > leads me to believe that there must be something different in the way
>> > Legacy GRUB and GRUB2 handle Data and BSS segments (ie: initializing
>> > data by zeroing out).
>> The most common reason is the OS zeroing it o
On Mon, Aug 3, 2009 at 12:41 AM, Robert Millan wrote:
> On Sun, Aug 02, 2009 at 11:42:43PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> >> No. Now we have an extra element that is always present and we want to
>> >> remove but when we remove command line can be empty and code must
>> >> handle it
On Fri, Aug 14, 2009 at 4:04 PM, Michal Suchanek wrote:
> Hello
>
> I am sending the rest of framebuffer patches that were not included in
> the split by Vladimir.
>
> remove-dup-function.patch
>
> * video_fb.c: remove grub_video_fb_get_video_ptr which is duplicated in
> fbutil.c
> * fbutil.c: cop
Hello
I am sending the rest of framebuffer patches that were not included in
the split by Vladimir.
remove-dup-function.patch
* video_fb.c: remove grub_video_fb_get_video_ptr which is duplicated in fbutil.c
* fbutil.c: copy the note from fbfill.c
rename-var.patch
vbe.c: grub_video_vbe_setup re
On Fri, Aug 14, 2009 at 3:23 PM, Vladimir 'phcoder'
Serbinenko wrote:
> Framebuffer patch comitted and I removed framebuf branch on my repo.
>>
>> OK, I did not get why fbfill.h of the three private headers.
>>
>> Perhaps fbutil.h which already declares blit_info would be a better place
>> then.
>
Framebuffer patch comitted and I removed framebuf branch on my repo.
>
> OK, I did not get why fbfill.h of the three private headers.
>
> Perhaps fbutil.h which already declares blit_info would be a better place
> then.
>
I haven't looked in depth how private headers were organised, I just
moved t
2009/8/14 Vladimir 'phcoder' Serbinenko :
> On Fri, Aug 14, 2009 at 2:13 AM, Michal Suchanek wrote:
>> 2009/8/13 Vladimir 'phcoder' Serbinenko :
Considering that vbe.c and sdl.c currently aren't affected a lot
whether there is or there isn't encapsulation in place, I'm ok tih
encapsu
>
> Hello Robert,
>
> Today I got a response from hdt developers. They mentioned that hdt
> needs some syslinux internal hence it will not function without
> syslinux.
Probably grub exposes to its modules a similar functionality as
syslinux to com32. Of course function names differ but prbably by
w
On Fri, Aug 14, 2009 at 2:13 AM, Michal Suchanek wrote:
> 2009/8/13 Vladimir 'phcoder' Serbinenko :
>>> Considering that vbe.c and sdl.c currently aren't affected a lot
>>> whether there is or there isn't encapsulation in place, I'm ok tih
>>> encapsulating it but if any driver needs the breach of
2009/8/14 Michal Suchanek :
> 2009/8/13 Vladimir 'phcoder' Serbinenko :
>>> Considering that vbe.c and sdl.c currently aren't affected a lot
>>> whether there is or there isn't encapsulation in place, I'm ok tih
>>> encapsulating it but if any driver needs the breach of encapsulation
>>> it will be
On Fri, Aug 14, 2009 at 1:18 PM, Marco Gerards wrote:
> Hi,
>
> "J.Bakshi" writes:
>
>> It is nice to see that grub 1.97 is on its way. Everyone is waiting
>> for this power pack. But we also need a good doc for it.
>> The wiki is out-dated.
>
> You are completely right. Do you volunteer to write
Hello!
A short success report about using GRUB2 on a LVM-only system, with GPT
instead of the usual MBR booting, on a AMD64 system, installed with the
20090531-7 Debian Installer.
I had the DI create a GPT partition table, partitioned that into a small
(1 MiB) GRUB booting partition (as suggested
Hi,
"J.Bakshi" writes:
> It is nice to see that grub 1.97 is on its way. Everyone is waiting
> for this power pack. But we also need a good doc for it.
> The wiki is out-dated.
You are completely right. Do you volunteer to write documentation?
--
Marco
_
19 matches
Mail list logo
