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

Re: GRUB maintainership



Gordon Matzigkeit <gord@trick.fig.org> wrote:

GM>>>>> Erich Boleyn writes:
GM> 
GM>  EB> Heh.  Yeah, I'm OK with that.  I'm also OK with the idea of being
GM>  EB> more focused for a while, to help you guys get a first version
GM>  EB> out.
GM> 
GM> It's good to know that you aren't defensive about this. :)
GM> 
GM> I'll try hard not to step on your toes, and to keep open communication
GM> about the things I'm working on.

Don't worry too much about it.  I have a few agendas of my own (who
doesn't?  ... mine are mostly related to usability arguments for experts
and novices), but none of them are entirely inflexible.  I also understand
wanting to make changes/fixes available faster.  As long as we discuss
things reasonably, I'll probably be fine with it.


...[most of the comments from the "Really-want list" deleted]...

GM> The most important feature I want is described in the next mail.
  [Note:  this was a feature to find the first partition of a specified
   type]

...and Roland McGrath <roland@frob.com> wrote:

RM> * Grok slice syntax (1-origin DOS partition numbers): hd0s1, hd0s1b.
RM>   It is just too horrible to explain to the users how the syntax that
RM>   gnumach and hurd use will not work in GRUB.
RM>   The (,,) syntax is nice too, but I think everyone here is down with
RM>   converting that to 1-origin DOS partition numbers too, cause that's
RM>   just what everybody does for DOS partition numbers.

OK.  I can do both the above easily enough, but doesn't having 0-based
numbering for disks and 1-based for slices seem a bit inconsistent? (maybe
this is just the math geek in me...)

The "search for first partition of selected type" idea is a good one,
though it seems natural to extend this to the rest of my search mechanism,
which could look for it across all available disks (i.e. I'm not sure of
the syntax you have, but the idea is right).


GM> The most important bug that needs fixing is support for the LS-120 IDE
GM> floppy drive.  I don't have one, but I'm sure somebody on debian-hurd
GM> can give you a report, if you haven't gotten one already.

RM> * Newfangled BIOS disk access interfaces??  Is it just me, or did I *not*
RM>   have this horrible agony with LILO or the {Free,Net}BSD boot loaders
RM>   about whether my kernels are in the first half of my gigabyte disk??

These are related in that there is always the sticky question of what to
do with the first sector.  Right now I have an autoprobe which determines
the size of the floppy (i.e. if you have a 1.44M floppy in a 2.88M drive,
it correctly picks it up. the BIOS does *not* usually tell you this), and
the geometry-neutral code to find the sectors programmed into it at install
time (this is for cases when the disk translation changes).

As it is, we're at about the limit.  (I think) I can fix the LS-120 thing
in a relatively elegant way, and I am going to test out the idea this
weekend before making another beta-release.  I'd like people who may have
these drives to try this out.

...but the newer BIOS interfaces are really out for the first sector.
There's just not nearly enough room to do this while providing
compatibility with the old interface, which we still need for some time.

Opinions?


--
    Erich Stefan Boleyn                      \_         <erich@uruk.org>
  Mad Scientist  --  CyberMuffin               \__    http://www.uruk.org/
  Motto: "I'll live forever or die trying"        ---------------------------


Reply to: