On 01/27/2011 05:38 AM, Michal Simek wrote: > This patch add the support to fdisk utility. > > Signed-off-by: Michal Simek <[email protected]> > --- > util-linux/fdisk_osf.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/util-linux/fdisk_osf.c b/util-linux/fdisk_osf.c > index 79be0cd..5706978 100644 > --- a/util-linux/fdisk_osf.c > +++ b/util-linux/fdisk_osf.c > @@ -47,7 +47,7 @@ > || defined(__m68k__) || defined(__mips__) || defined(__s390__) \ > || defined(__s390__) || defined(__s390x__) \ > || defined(__sh__) || defined(__x86_64__) || defined(__avr32__) \ > - || defined(__nds32__) > + || defined(__nds32__) || defined(__microblaze__) > # define BSD_LABELSECTOR 1 > # define BSD_LABELOFFSET 0 > #elif defined(__alpha__) || defined(__powerpc__) || defined(__ia64__) \
Back before when I was banging on Hexagon (before Qualcomm got a multi-month budget renewal gap and I wandered off to do something else) I had to add a Hexagon stanza to fdisk too. Despite the fact that there's pretty much only about four minor behavior variations fdisk does, and all but one of those behaviors are for ancient targets with screwy historical breakage. I realize we inherited this mess from upstream, but is there some way to kill it with fire? (Or at least refactor it to have a sane "else" case, which would make 80% of it go away and most new platforms not care?) Rob _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
