grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: 1.97 roadmap


From: Robert Millan
Subject: Re: RFC: 1.97 roadmap
Date: Wed, 12 Aug 2009 02:43:34 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Aug 10, 2009 at 07:10:12PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Mon, Aug 10, 2009 at 6:10 PM, Robert Millan<address@hidden> wrote:
> >
> > Hi,
> >
> > I think it's time we begin the discussion on GRUB 1.97.  What do we want to
> > see in it, and a rough schedule.  1.97 is meant to be a point release, 
> > without
> > any major changes (I mean, except for those we already have ;-)), and it 
> > should
> > happen soon (like this month or so).
> I think it would be good if we release before ubuntu's beta freeze.

Agreed.

> >  - Low memory heap (useful to move code off kern/i386/pc/startup.S).
> Originally I thought of a path relocator32->relocator users->mm
> relocator32 is ready for next round of review but is untested. Now I
> think about it mm patch isn't actually dependent on relocator32, just
> you won't get some features (as loading big initrds and removal of
> os_area_size/os_area_addr fields) before relocator32 is used by all
> loaders. I will adjust mm patch to this and add
> .(text|data|bss)-lowmem section support.

I don't understand, what is the relation between relocator in loaders and
low memory heap?

I'll need to catch up with the lowmem heap discussion.  What's the approach?

> What about savedefault? Which savedefault way you prefer?

I think it would be good to have.  But I haven't followed on the savedefault
discussion, I just know it would build upon the existing envfile support.

> > Bigger overhauls like the fancy menu
> I started splitting Collin's patches and actually only quite few need
> to go to the parts already present in grub2. Perhaps 1.97 can be
> brought to a state when gfxmenu can be compiled externally?

Depends on how intrusive are those changes :-)

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]