[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: fdisk cleanup
From:       Rob Landley <rob () landley ! net>
Date:       2006-02-25 14:16:06
Message-ID: 200602250916.06929.rob () landley ! net
[Download RAW message or body]

On Friday 24 February 2006 11:22 pm, Garrett Kajmowicz wrote:
> > Actually, I believe there's code in that mess somewhere that re-orders
> > the partitions if they're out of order (which breaks dell's hidden bios
> > partition thing).  I ranted about that back in November...
>
> That code is still in there (getting to it).  However, that particular call
> was a plain warning that your mother dresses you funny, not so much a
> warning that I'm about to press the button marked "do not press".

A point.

> > Could you check and see if this really is a useless warning or a "I'm
> > going to do something stupid" warning?
>
> This particular invocation is at the end of the list_table function, which
> returns void.  This printf isn't going to do much.
>
> > (I honestly think that the best use the current fdisk code can serve is
> > something you read to learn how to partition stuff, then start over from
> > scratch writing a new (sane) implementation.  Easier than paring down
> > this monster.  But that's just how I'd approach it...)
>
> I thought about it, but there is sufficient meat in here to actually be
> worthwhile keeping.  I pity the person who needs to learn SGI partitions al
> over again.  With enough swashbuckling it can be hacked into shape.

Is there currently any need for the busybox fdisk to support SGI partitions?  
Does any of our userbase care?  Are new users creating new systems likely to 
start caring in future?

I'm not saying we shouldn't learn from the existing code.  Or even splice bits 
of it on when necessary (it can be licensed under GPL2, life is good).

>
> As to your comment about the patch generation, I do as you request for
> future patches.  I took the previous approach simply because I'm not simply
> tweeking, but chopping with a chain saw all of the crufty bits.  Anything
> other than sequential patch management is going to cause problems simply
> because of the sheer number of changes.

Understood, but it makes 'em hard to apply.

The traditional way to do this is make a series of patch files that apply in 
sequence.  (patch1, patch2, patch3...)  It's ok for patches to depend on 
earlier patches having been applied...

> -     Garrett

Rob
-- 
Never bet against the cheap plastic solution.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]