RFC: 1.97 roadmap

RFC: 1.97 roadmap

[Robert Millan]

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).

Here's what I'd like to see included:

  - Low memory heap (useful to move code off kern/i386/pc/startup.S).
  - Authentication support (even if it only supports passwords initially).
  - Gettext.
  - Integrated "hiddenmenu" functionality.
  - Other cleanups, like Vladimir's video split.

Bigger overhauls like the fancy menu or Bean's proposal for new module
format, I think should be considered after 1.97.

What I'd like is that 1.97 is released soon so that this doesn't lead
development to stall.  But this is an open invitation to discuss it, so
please bring in your opinions!

-- 
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."

Re: RFC: 1.97 roadmap

[Vladimir 'phcoder' Serbinenko]

On Mon, Aug 10, 2009 at 6:10 PM, Robert Millan<rmh@aybabtu.com> 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.
>
> Here's what I'd like to see included:
>
>  - 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.
>  - Authentication support (even if it only supports passwords initially).
>  - Gettext.
>  - Integrated "hiddenmenu" functionality.
>  - Other cleanups, like Vladimir's video split.
>
What about savedefault? Which savedefault way you prefer?
>
> 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?
> or Bean's proposal for new module
> format, I think should be considered after 1.97.
>

>
> --
> 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."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: RFC: 1.97 roadmap

[Michal Suchanek]

2009/8/10 Robert Millan <rmh@aybabtu.com>:
>
> 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).
>
> Here's what I'd like to see included:
>
>  - Low memory heap (useful to move code off kern/i386/pc/startup.S).
>  - Authentication support (even if it only supports passwords initially).
>  - Gettext.
>  - Integrated "hiddenmenu" functionality.
>  - Other cleanups, like Vladimir's video split.

If the video split is done properly then doing screen rotation on top
of it should be easy.

I would like to see that as well.

However, I am unsure as to how this would be configured.

In my current attempt to get this into the video mode parser without
adding too much stuff I have added a small bit that extracts the
direction from a few letters that are in front of the size.

ie

800x600x32 gives 800x600 resolution in 32bpp

E800x600 or MF800x600x16 gives 800x600 resolution with screen in
another direction.

This should work but I am not sure this would a nice way to specify
the screen direction for the end user.


What is the state of graphics on EFI?

Thanks

Michal

Re: RFC: 1.97 roadmap

[Vladimir 'phcoder' Serbinenko]

>
> What is the state of graphics on EFI?
in efi/linux.c there is a stub with a mixture of UGA and direct
access. I would prefer to switch to own drivers since EFI tries to
"abstract" video. Bean has GOP patch but only few mobos support it.
>
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: RFC: 1.97 roadmap

[Robert Millan]

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<rmh@aybabtu.com> 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."

Re: RFC: 1.97 roadmap

[Colin Watson]

On Mon, Aug 10, 2009 at 06:10:40PM +0200, Robert Millan wrote:
> 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).

Robert asked me on IRC about Ubuntu's release schedule. Our feature
freeze is 27 August; after that I can squeeze in bug-fixes but it gets
progressively harder. I understand that 1.97 is probably not feasible by
then; if we have an up-to-date snapshot at that point then I can
probably manage to justify resyncing at least some newer snapshots up to
24 September (beta freeze).

> Here's what I'd like to see included:
> 
>   - Low memory heap (useful to move code off kern/i386/pc/startup.S).
>   - Authentication support (even if it only supports passwords initially).
>   - Gettext.
>   - Integrated "hiddenmenu" functionality.
>   - Other cleanups, like Vladimir's video split.

I think my list is as follows:

  * Authentication, for parity with GRUB Legacy (i.e. passwords only
    would be fine).

  * Integrated hiddenmenu.
    Mark asked me yesterday if there was anything we could do to have
    "sleep" detect key state (ideally a shift key state rather than
    Escape) rather than having to wait for a key press, so that the
    timeout could be reduced to zero in our configuration; if anyone has
    any bright ideas about the keyboard layer then this would be very
    nice.

  * Some way to support a quieter boot when the menu isn't being
    displayed, without the status messages as GRUB loads
    (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/386922). I
    don't at all mind if this isn't the default, as I understand that
    there are debugging considerations; being able to check a shift key
    state would help here.

  * Unicode menu font by default. (I believe this is done.) The driver
    for this is from some of our OEM distributors, so while Gettext
    support would be nice we can certainly cope without it by having our
    custom engineering people just drop in alternative text, since the
    OEM typically knows what locale they're shipping to.

  * grub-reboot and grub-set-default. While it does look as though we
    can put this together using grub-editenv, grub-mkconfig will need to
    support it.

Thanks,

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: RFC: 1.97 roadmap

[Colin Watson]

On Wed, Aug 12, 2009 at 02:43:34AM +0200, Robert Millan wrote:
> On Mon, Aug 10, 2009 at 07:10:12PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > 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.

I thought Vladimir's general approach in
http://lists.gnu.org/archive/html/grub-devel/2009-06/msg00002.html was
just fine (nice and simple, no fancy event handling, builds on existing
facilities), although I agree with the suggestions from Robert/Pavel
that the save step should be a single command/function.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: RFC: 1.97 roadmap

[Colin Watson]

On Wed, Aug 12, 2009 at 09:41:39AM +0100, Colin Watson wrote:
> On Wed, Aug 12, 2009 at 02:43:34AM +0200, Robert Millan wrote:
> > On Mon, Aug 10, 2009 at 07:10:12PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > > 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.
> 
> I thought Vladimir's general approach in
> http://lists.gnu.org/archive/html/grub-devel/2009-06/msg00002.html was
> just fine (nice and simple, no fancy event handling, builds on existing
> facilities), although I agree with the suggestions from Robert/Pavel
> that the save step should be a single command/function.

Oh, Pavel said in
http://lists.gnu.org/archive/html/grub-devel/2009-06/msg00190.html that
we should use text rather than numbers. I assume that he meant that the
saved entry should actually be the menu item name? If so I tend to
agree; I'm pretty sure that we have a long-standing bug somewhere to the
effect that if you have a bunch of distribution kernels at the top of
the menu and another operating system at the bottom, then it's a pain to
declare the other OS as the default because every time new distribution
kernels are installed the menu indices change.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: RFC: 1.97 roadmap

[Michal Suchanek]

2009/8/10 Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>:
>>
>> What is the state of graphics on EFI?
> in efi/linux.c there is a stub with a mixture of UGA and direct
> access. I would prefer to switch to own drivers since EFI tries to
> "abstract" video. Bean has GOP patch but only few mobos support it.

I have found one such patch that AFAICT replaces UGA with GOP.

With GOP we get access to the framebuffer which is about as good or bad as VBE.

UGA is a different story. It only supports Blt (and FillRect), not
direct access, and the the Blt data probably has to be the same format
as the screen data.

This could be supported by creating an offscreen bitmap to which
video_fb would draw and which would be (partially) transferred using
the UGA Blt after every change. This would, however require some
callback which says what part was affected to be efficient.

Accelerated drivers might be also somewhat picky about the pixel
format (BGR vs RGB, 16bit vs 15bit) but these would typically have the
framebuffer mapped somewhere and could use video_fb for formats they
do not accelerate.

Thanks

Michal

Re: RFC: 1.97 roadmap

[Yves Blusseau]

[-- Attachment #1: Type: text/html, Size: 1466 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3313 bytes --]

Re: RFC: 1.97 roadmap

[Robert Millan]

Hi Yves,

Please could you include plain text in your mail?  HTML-only is difficult
to quote (see below)

On Wed, Aug 12, 2009 at 02:26:47PM +0200, Yves Blusseau wrote:
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
>   <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> </head>
> <body bgcolor="#ffffff" text="#000000">
> Colin Watson a &eacute;crit&nbsp;:
> <blockquote cite="mid:20090812084139.GU11691@riva.ucam.org" type="cite">
>   <pre wrap="">On Wed, Aug 12, 2009 at 02:43:34AM +0200, Robert Millan wrote:
>   </pre>
>   <blockquote type="cite">
>     <pre wrap="">On Mon, Aug 10, 2009 at 07:10:12PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>     </pre>
>     <blockquote type="cite">
>       <pre wrap="">What about savedefault? Which savedefault way you prefer?
>       </pre>
>     </blockquote>
>     <pre wrap="">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.
>     </pre>
>   </blockquote>
>   <pre wrap=""><!---->
> I thought Vladimir's general approach in
> <a class="moz-txt-link-freetext" href="http://lists.gnu.org/archive/html/grub-devel/2009-06/msg00002.html">http://lists.gnu.org/archive/html/grub-devel/2009-06/msg00002.html</a> was
> just fine (nice and simple, no fancy event handling, builds on existing
> facilities), although I agree with the suggestions from Robert/Pavel
> that the save step should be a single command/function.
>   </pre>
> </blockquote>
> I use the vladimir patch in my grub and it work like a charm. I think
> it's a good approach too.<br>
> <br>
> Yves Blusseau<br>
> </body>
> </html>



> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 
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."

Re: RFC: 1.97 roadmap

[Robert Millan]

On Wed, Aug 12, 2009 at 09:35:13AM +0100, Colin Watson wrote:
> On Mon, Aug 10, 2009 at 06:10:40PM +0200, Robert Millan wrote:
> > 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).
> 
> Robert asked me on IRC about Ubuntu's release schedule. Our feature
> freeze is 27 August; after that I can squeeze in bug-fixes but it gets
> progressively harder. I understand that 1.97 is probably not feasible by
> then; if we have an up-to-date snapshot at that point then I can
> probably manage to justify resyncing at least some newer snapshots up to
> 24 September (beta freeze).

I think it would be feasible to release 1.97 shortly after 27 August.

>   * Integrated hiddenmenu.
>     Mark asked me yesterday if there was anything we could do to have
>     "sleep" detect key state (ideally a shift key state rather than
>     Escape) rather than having to wait for a key press, so that the
>     timeout could be reduced to zero in our configuration; if anyone has
>     any bright ideas about the keyboard layer then this would be very
>     nice.

We can add an (optional) interface to input terminals that would allow
such check.  However, it would have to be provided by at_keyboard.mod
rather than BIOS console.  This means you'd also want to enable usb
keyboard support, which is not ready.

So, possible yes, but not with 1.97.  If you can help us get USB more
widely tested, this could be supported sometime after.

>   * Some way to support a quieter boot when the menu isn't being
>     displayed, without the status messages as GRUB loads
>     (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/386922). I
>     don't at all mind if this isn't the default, as I understand that
>     there are debugging considerations; being able to check a shift key
>     state would help here.

Some of the messages come from code in e.g. MBR that can't access configuration
files.  I guess you'll have to patch boot/i386/pc/*.

>   * Unicode menu font by default. (I believe this is done.)

Yes, I think Felix already enabled it as default.

>     The driver
>     for this is from some of our OEM distributors, so while Gettext
>     support would be nice we can certainly cope without it by having our
>     custom engineering people just drop in alternative text, since the
>     OEM typically knows what locale they're shipping to.

Ok.  In that case, I don't consider gettext essential for 1.97.

-- 
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."

grub configuration file format change?

[Seth Goldberg]

Hi,

   I know this isn't on the 1.97 roadmap, but I was wondering about the status 
of changing the grub.cfg format.  I'm currently trying to plan GRUB2 work for 
Solaris and I'd like to minimize as much code change as I can.

  Thanks,
  --S

Re: grub configuration file format change?

[Robert Millan]

On Thu, Aug 13, 2009 at 01:45:17PM -0700, Seth Goldberg wrote:
> Hi,
>
>   I know this isn't on the 1.97 roadmap, but I was wondering about the 
> status of changing the grub.cfg format.  I'm currently trying to plan 
> GRUB2 work for Solaris and I'd like to minimize as much code change as I 
> can.

We tend to change it very often.  I can't garantee there won't be any minor
change before 1.97.

Is this an issue for you?  Colin said he was concerned about core.img and
grub.cfg getting out of sync (see the other sub-thread).  Does this problem
also affect you?

-- 
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."

Re: grub configuration file format change?

[Seth Goldberg]

Hi,

Quoting Robert Millan, who wrote the following on Thu, 13 Aug 2009:

> On Thu, Aug 13, 2009 at 01:45:17PM -0700, Seth Goldberg wrote:
>> Hi,
>>
>>   I know this isn't on the 1.97 roadmap, but I was wondering about the
>> status of changing the grub.cfg format.  I'm currently trying to plan
>> GRUB2 work for Solaris and I'd like to minimize as much code change as I
>> can.
>
> We tend to change it very often.  I can't garantee there won't be any minor
> change before 1.97.

  Ok, I'll keep that in mind.  I do understand that GRUB is under rapid 
development.

>
> Is this an issue for you?  Colin said he was concerned about core.img and
> grub.cfg getting out of sync (see the other sub-thread).  Does this problem
> also affect you?

   I saw that thread :) -- I don't think it's as much of a problem, because 
we'll probably stabilize on a particular snapshot of GRUB2.  For incompatible 
updates to grub.cfg, I think we'll handle that when we update to a newer 
snapshot.  It may be a concern for users who try to update GRUB2 themselves 
with the bleeding edge from the svn repo, but I think the community can handle 
that on a case-by-case basis.

   --S

Re: grub configuration file format change?

[Robert Millan]

On Thu, Aug 13, 2009 at 02:12:41PM -0700, Seth Goldberg wrote:
>>
>> Is this an issue for you?  Colin said he was concerned about core.img and
>> grub.cfg getting out of sync (see the other sub-thread).  Does this problem
>> also affect you?
>
>   I saw that thread :) -- I don't think it's as much of a problem, 
> because we'll probably stabilize on a particular snapshot of GRUB2.

We would prefer if you can include GRUB releases in your own OpenSolaris
releases rather than snapshots.  1.96 is unfortunately not usable, but we
plan to change the pace at which we make releases, and also introduce a
pre-release testing period.

If you let us know about your own release schedules, we can try to help.

-- 
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."