On Fri, Sep 4, 2009 at 4:41 AM, Vladimir 'phcoder'
Serbinenko wrote:
> On Thu, Sep 3, 2009 at 9:20 PM, Bean wrote:
>> Hi,
>>
>> This is the bug fix for command/loadenv.c. Here is a small program to
>> illustrate what happen:
> Update your branch:
>
> 2009-09-01 Vladimir Serbinenko
>
> * c
From: "Vladimir 'phcoder' Serbinenko"
Date: Thu, 3 Sep 2009 17:08:34 +0200
> I can't agree with designating nested functions as root issue. Imagine
> tomorrow we discover a bug in "for" loop compiling. This wouldn't be a
> reason to replace all "for"s with "while"s. The root issue is compiler
> b
2009/9/3 Bean :
> On Thu, Sep 3, 2009 at 4:41 PM, Michal
>> And how would you place the menu items then? At random?
>
> Hi,
>
> First we can implement the classic menu, which is basically multi-line
> text box, one item per line. Later we could add more style, perhaps by
> inserting a panel compone
On Thu, Sep 03, 2009 at 05:38:27PM +0200, Robert Millan wrote:
> Ok. Unless someone knows better, I'm fine with your previous approach.
Committed, then; if somebody has a better idea they can always refine
from here.
--
Colin Watson [cjwat...@ubuntu.com]
On Thu, Sep 03, 2009 at 04:38:27PM +0200, Robert Millan wrote:
> On Wed, Sep 02, 2009 at 03:11:32PM +0100, Colin Watson wrote:
> > I realise that Robert already said that this was post-1.97 material, but
> > I'd like to see if we can agree on this in advance.
>
> This patch looks sane to me. I'm
>>
>> Compil and work on OSX.
>>
>> Is it ok to commit it ?
>
> However, on our side, I'm not satisfied at all with accomodating to arbitrary
> limitations like this one. This seems like a slippery slope. If we do it
> now, what's the next one?
I agree that we shouldn't support a compiler if it r
Le 1 sept. 09 à 13:46, Robert Millan a écrit :
On Mon, Aug 31, 2009 at 11:10:17PM +0200, Yves Blusseau wrote:
What about following compromise:
diff --git a/loader/i386/linux.c b/loader/i386/linux.c
index 4144384..1380eb8 100644
--- a/loader/i386/linux.c
+++ b/loader/i386/linux.c
@@ -543,7 +543
On Thu, Sep 3, 2009 at 9:20 PM, Bean wrote:
> Hi,
>
> This is the bug fix for command/loadenv.c. Here is a small program to
> illustrate what happen:
Update your branch:
2009-09-01 Vladimir Serbinenko
* commands/loadenv.c (check_blocklists): Fix off-by-one error.
(write_blockli
Hi,
Maybe that compiler has been configured with -fdelete-null-pointer-checks as
the default?
--S
Quoting Bean, who wrote the following on Fri, 4 Sep 2009:
Hi,
This is the bug fix for command/loadenv.c. Here is a small program to
illustrate what happen:
#include
#include
struct data
Hi,
This is the bug fix for command/loadenv.c. Here is a small program to
illustrate what happen:
#include
#include
struct data
{
struct data *next;
int length;
};
struct data *
new_data ()
{
struct data *p;
p = malloc (sizeof (*p));
p->length = 1;
p->next = 0;
return p;
}
in
On Thu, Sep 03, 2009 at 04:30:31PM +0200, Robert Millan wrote:
> I wonder if we should enable grub.texi in the build system. Core
> documentation
> is not complete yet, but it's better than nothing.
> What do you think?
If we do, I suggest it ships with a complete index, even if the missing
sect
Quoting Robert Millan, who wrote the following on Thu, 3 Sep 2009:
On Thu, Sep 03, 2009 at 09:30:31AM -0700, Seth Goldberg wrote:
Quoting Robert Millan, who wrote the following on Thu, 3 Sep 2009:
On Wed, Sep 02, 2009 at 04:45:28PM -0700, Seth Goldberg wrote:
Hi,
I know I've been anno
On Fri, Aug 28, 2009 at 09:21:02PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >> + /* clear the request area, buggy BIOSes may not clear it */
> >> + xor %edi, %edi
> >> + movl %edi, 4(%eax)
> >> + movl %edi, 8(%eax)
> >> + movl %edi, 12(%eax)
> >> + movl
On Thu, Sep 03, 2009 at 09:30:31AM -0700, Seth Goldberg wrote:
>
>
> Quoting Robert Millan, who wrote the following on Thu, 3 Sep 2009:
>
>> On Wed, Sep 02, 2009 at 04:45:28PM -0700, Seth Goldberg wrote:
>>> Hi,
>>>
>>> I know I've been annoyed by this (as have many others I've talked to).
>>> Ho
On Thu, Sep 3, 2009 at 5:54 PM, Paolo Bonzini wrote:
>
>>> #include
>>>
>>> void foo (int a, int b, void (*hook) (int aa, int bb, int cc))
>>> {
>>> b += a;
>>> hook (a, b, a + b);
>>> }
>>>
>>> void qq (int a)
>>> {
>>> auto void q1 (int aa, int bb, int cc);
>>> void q1 (int aa, int bb, int cc
On Tue, Sep 01, 2009 at 11:46:21PM +0200, Magnus Granberg wrote:
> Hi
>
> On Gentoo Hardened we compile with -fPIE in the default specs and
> grub fails to compile.
> This patch check if the compiler use -fPIE in the default specs and add
> -fno-PIE to TARGET_CFLAGS.
Committed. In the future, pl
Quoting Robert Millan, who wrote the following on Thu, 3 Sep 2009:
On Wed, Sep 02, 2009 at 04:45:28PM -0700, Seth Goldberg wrote:
Hi,
I know I've been annoyed by this (as have many others I've talked to).
How about we enabling paging (set pager=1) automatically for the duration
of the help
>On Thu, Sep 03, 2009 at 12:31:57AM +0200, Magnus Granberg wrote:
>> >Why not just check if the compiler accepts -fno-PIE and use it? No
>> >harm done if -fPIE wasn't default, right?
>> --
>> Didn't want to add -fno-PIE when it was not needed and to be on the
>> safe side . I can make it to ch
On Thu, Sep 3, 2009 at 11:49 PM, Felix Zielcke wrote:
> Am Donnerstag, den 03.09.2009, 17:36 +0200 schrieb Robert Millan:
>> On Wed, Sep 02, 2009 at 12:20:19PM +0800, Bean wrote:
>> >
>> > Hi,
>> >
>> > Oh, I was wrong previously, gcc does respect __attribute__
>> > ((__regparm__ (3))) flag (I forg
On Thu, Sep 3, 2009 at 5:49 PM, Felix Zielcke wrote:
> Am Donnerstag, den 03.09.2009, 17:36 +0200 schrieb Robert Millan:
>> On Wed, Sep 02, 2009 at 12:20:19PM +0800, Bean wrote:
>> >
>> > Hi,
>> >
>> > Oh, I was wrong previously, gcc does respect __attribute__
>> > ((__regparm__ (3))) flag (I forge
Am Donnerstag, den 03.09.2009, 17:36 +0200 schrieb Robert Millan:
> On Wed, Sep 02, 2009 at 12:20:19PM +0800, Bean wrote:
> >
> > Hi,
> >
> > Oh, I was wrong previously, gcc does respect __attribute__
> > ((__regparm__ (3))) flag (I forget to add -Os so it still uses stack
> > to store value). An
On Thu, Sep 03, 2009 at 04:27:57PM +0100, Colin Watson wrote:
> On Thu, Sep 03, 2009 at 04:47:40PM +0200, Robert Millan wrote:
> > On Thu, Sep 03, 2009 at 11:22:04AM +0100, Colin Watson wrote:
> > > I'd like to commit this for 1.97; it's important for users of recent
> > > distributions that use GC
On Wed, Sep 02, 2009 at 12:20:19PM +0800, Bean wrote:
>
> Hi,
>
> Oh, I was wrong previously, gcc does respect __attribute__
> ((__regparm__ (3))) flag (I forget to add -Os so it still uses stack
> to store value). And the bug is still there ! Try this test program:
Thanks Bean. I have opened a
On Thu, Sep 03, 2009 at 04:47:40PM +0200, Robert Millan wrote:
> On Thu, Sep 03, 2009 at 11:22:04AM +0100, Colin Watson wrote:
> > I'd like to commit this for 1.97; it's important for users of recent
> > distributions that use GCC 4.4 by default (which is the current release
> > series of GCC). Oth
On Thu, Sep 03, 2009 at 03:52:43PM +0100, Colin Watson wrote:
> On Thu, Sep 03, 2009 at 04:33:23PM +0200, Robert Millan wrote:
> > On Wed, Sep 02, 2009 at 12:01:42PM +0100, Colin Watson wrote:
> > > 2009-09-02 Colin Watson
> > >
> > > * commands/loadenv.c (grub_cmd_save_env): Allow an optiona
On Wed, Sep 2, 2009 at 12:26 AM, David Miller wrote:
> From: Yves Blusseau
> Date: Tue, 1 Sep 2009 21:30:01 +0200
>
>>
>> Le 1 sept. 09 à 17:43, Bean a écrit :
>>
>>> IMO, if we are to tackle the NESTED_FUNC_ATTR issue, we should do it
>>> properly by removing nested function, this also has other
> Hi,
>
> Oh, I was wrong previously, gcc does respect __attribute__
> ((__regparm__ (3))) flag (I forget to add -Os so it still uses stack
> to store value). And the bug is still there ! Try this test program:
I confirm with gcc-4.4
This is a grave problem then. This check was added by Marco Gerar
On Tue, Sep 01, 2009 at 06:07:04PM +0200, Robert Millan wrote:
> On Tue, Sep 01, 2009 at 03:44:18PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >
> > +AC_CACHE_CHECK([whether gcc is recent enough], grub_cv_cc_recent, [
> > + CFLAGS=
> > + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
> > +#if defined
On Thu, Sep 03, 2009 at 03:00:48PM +0100, Colin Watson wrote:
> Index: normal/main.c
> ===
> --- normal/main.c (revision 2561)
> +++ normal/main.c (working copy)
> @@ -503,7 +503,7 @@
> }
>
> static grub_err_t
> -grub_norma
On Thu, Sep 03, 2009 at 04:33:23PM +0200, Robert Millan wrote:
> On Wed, Sep 02, 2009 at 12:01:42PM +0100, Colin Watson wrote:
> > 2009-09-02 Colin Watson
> >
> > * commands/loadenv.c (grub_cmd_save_env): Allow an optional
> > explicit value (`save_env variable_name=value').
> > (GR
On Thu, Sep 03, 2009 at 04:30:31PM +0200, Robert Millan wrote:
> I wonder if we should enable grub.texi in the build system. Core
> documentation
> is not complete yet, but it's better than nothing.
>
> What do you think?
I think we should; it would hopefully encourage some specific bug
reports
On Thu, Sep 03, 2009 at 11:22:04AM +0100, Colin Watson wrote:
> I'd like to commit this for 1.97; it's important for users of recent
> distributions that use GCC 4.4 by default (which is the current release
> series of GCC). Otherwise, the core is too big to embed when using LVM
> and RAID (https:/
On Wed, Sep 02, 2009 at 03:11:32PM +0100, Colin Watson wrote:
>
> I realise that Robert already said that this was post-1.97 material, but
> I'd like to see if we can agree on this in advance.
This patch looks sane to me. I'm afraid I can't fully commit to it (specially
since noone else has comm
On Wed, Sep 02, 2009 at 12:01:42PM +0100, Colin Watson wrote:
> This implements saving an environment variable with a given value
> without having to set that variable first, as suggested by Pavel here:
>
> http://lists.gnu.org/archive/html/grub-devel/2009-06/msg00190.html
>
> 2009-09-02 Colin
On Wed, Sep 02, 2009 at 10:30:09AM +0100, Colin Watson wrote:
> > Other than this patch is good. I don't think it needs more review. You
> > can commit it.
>
> All right, thanks. Committed.
I wonder if we should enable grub.texi in the build system. Core documentation
is not complete yet, but it
On Wed, Sep 02, 2009 at 11:51:30AM +0200, Yves Blusseau wrote:
> ChangeLog:
>
> 2009-09-02 Yves BLUSSEAU
>
>Embedding loadenv module into grub-emu
>
>* conf/i386-pc.rmk (grub_emu_SOURCES): add lib/envblk.c and
>commands/loadenv.c
>* conf/i386-coreboot.rmk (grub_emu_SOURCES): Like
On Thu, Sep 03, 2009 at 04:16:27PM +0200, Robert Millan wrote:
> On Tue, Sep 01, 2009 at 05:19:51PM +0100, Colin Watson wrote:
> > (Per a discussion with Robert on IRC, this can be post-1.97 if you
> > like.)
> >
> > Would it make sense for grub-editenv to have a default for the filename?
> > I di
On Wed, Sep 02, 2009 at 04:45:28PM -0700, Seth Goldberg wrote:
> Hi,
>
> I know I've been annoyed by this (as have many others I've talked to).
> How about we enabling paging (set pager=1) automatically for the duration
> of the help command, since it will inevitable scroll off of the screen
I broke gcc < 4.4 by mistake, sorry. Updated patch follows.
With this patch and './grub-mkimage -d . -o tmp biosdisk ext2 part_msdos
raid mdraid lvm fs_uuid':
gcc 4.3: 30370 bytes
gcc 4.4: 30331 bytes
(Before this patch, gcc 4.4 produced an image that was 33000-some-odd
bytes.)
2009-09-03
On Tue, Sep 01, 2009 at 03:23:01PM -0700, David Miller wrote:
> From: "Vladimir 'phcoder' Serbinenko"
> Date: Tue, 1 Sep 2009 16:12:20 +0200
>
> > Even if gcc<4.2 seem to work ok I think we shouldn't waste resources
> > on it and officially declare a minimal requirement ("you're free to go
> > un
On Wed, Sep 02, 2009 at 02:45:24AM +0100, Colin Watson wrote:
> I just committed this bug fix. It seemed obvious enough that it didn't
> need to be posted for review first. (If that was wrong, I'm sorry and
> I'll adjust my practices in future.)
It's fine, thanks.
--
Robert Millan
The DRM opt
On Thu, Sep 03, 2009 at 12:31:57AM +0200, Magnus Granberg wrote:
> >Why not just check if the compiler accepts -fno-PIE and use it? No
> >harm done if -fPIE wasn't default, right?
> --
> Didn't want to add -fno-PIE when it was not needed and to be on the
> safe side . I can make it to check fo
On Tue, Sep 01, 2009 at 05:19:51PM +0100, Colin Watson wrote:
> (Per a discussion with Robert on IRC, this can be post-1.97 if you
> like.)
>
> Would it make sense for grub-editenv to have a default for the filename?
> I dislike hardcoding something in package maintainer scripts that needs
> to ma
Normal mode startup currently displays some text that really only makes
sense if it's about to display a shell prompt. If it ends up displaying
the menu, then that'll set up the screen for itself anyway; but in that
case it really makes no sense to display a help message about BASH-like
line editin
On Thu, Sep 3, 2009 at 4:41 PM, Michal
> And how would you place the menu items then? At random?
Hi,
First we can implement the classic menu, which is basically multi-line
text box, one item per line. Later we could add more style, perhaps by
inserting a panel component that control the layout. F
I'd like to commit this for 1.97; it's important for users of recent
distributions that use GCC 4.4 by default (which is the current release
series of GCC). Otherwise, the core is too big to embed when using LVM
and RAID (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/423412).
Any objections?
2009/9/3 Bean :
> On Thu, Sep 3, 2009 at 3:43 AM, Michal Suchanek wrote:
>> 2009/9/2 Bean :
>>> On Thu, Sep 3, 2009 at 1:25 AM, Michal Suchanek wrote:
2009/9/2 Bean :
> On Wed, Sep 2, 2009 at 11:27 PM, Michal Suchanek
> wrote:
>> How will it fit screen? What if the image is 4:3 an
On Wed, Sep 02, 2009 at 03:11:32PM +0100, Colin Watson wrote:
> Still to do: update grub-set-default to use this (obvious, I think);
> implement 'savedefault --once' and grub-reboot (useful when you want to
> tell the boot loader to boot something else just once, but then return
> to the previous d
48 matches
Mail list logo
