Re: Current issues

[K.G.]

On Wed, 2 Nov 2005 16:28:04 +0100 Patrick Leslie Polzer <address@hidden> wrote:

> * code analysis tools: what do you think about setting up LXR and 
> nightly-updated Doxygen docs on our Berlios space? Too much overhead?
> Good idea?

For me it's a good idea. I would also like a wiki or something to discuss
about long term changes, a 1.7 branch, ...

> * patches: I see we are having patches for Apples iPod, some ATARI stuff
> and scientific units (how's the notation in detail, by the way?) in your
> personal repository, Guillaume. What's their status?

* ATARI adds support for... Atari partition tables :) It's quite complete
despite some lacks in parted infrastructure that implies some stuff are
invisible and not configurable (an area on the drive described in the
table is reserved for a bad block list and implemented as a metadata
partition). I've tested it against Linux parser and atari-fdisk, it
seems to work well, but the people i've contacted to make "real" tests
on Atari virtual machines seem to have problems with the VM that imply
non deterministic GCC errors, and i don't recommend inclusion before those
tests could be done.

* Apples iPod: Apple messed the whole msdos partition format on their iPods;
they did an awfull mix between DBR and MBR, used a system partition with
ID 0 (which means Free), ... Never seen anything so stupid before :)
So I did a quick hack to let Parted work with this strange format, but
i'm not really happy with it. I'm not sure this is really important to let
people use Parted on their msdos formated iPod anyway, especially if it
means supporting broken things. Maybe a detection and a message saying
that Apple uses a broken partition table format on their dos formated iPod
would be better. I really don't want to do any kind of voluntary after
sale support for Apple because of their own mess.

* scientific units: this is work in progress. The display changes are
done, the input ones aren't.

Display without:

(parted) p                                                                
Disk geometry for /dev/hda: 0kB - 123GB
Disk label type: msdos
Number  Start   End     Size    Type      File system  Flags
1       32kB    1078MB  1077MB  primary   reiserfs     boot
2       1078MB  2155MB  1078MB  primary   linux-swap   
3       2155MB  123GB   121GB   extended               
6       2155MB  7452MB  5297MB  logical   reiserfs     
7       7452MB  13GB    5445MB  logical   reiserfs     
5       13GB    123GB   110GB   logical   reiserfs     

Display with:

Disk geometry for /dev/hda: 0.00kB - 123GB
Disk label type: msdos
Number    Start     End    Size Type      File system  Flags
1        32.3kB  1078MB  1077MB primary   reiserfs     boot
2        1078MB  2155MB  1078MB primary   linux-swap   
3        2155MB   123GB   121GB extended               
6        2155MB  7452MB  5297MB logical   reiserfs     
7        7452MB  12.9GB  5445MB logical   reiserfs     
5        12.9GB   123GB   110GB logical   reiserfs     

If people like it this could be merged when it is finished.

For input i thought this could be interresting to let
654MB describe an area between 653.5 and 654.5 MB, while
231.4MB would mean something between 231.35 and 231.45M.

My goal is also to make sure that in most cases when
you enter the start of a partition you want to create
equal to the end of an existing partition, the constraints
are ok for these two partition to be able to not overlap,
which is not the case today especially with kB untis.

> * bugs: I recently noticed the constraint solver very often shows
> issues with mkpartfs, but not with mkpart. Does anyone know what kind
> of restrictions the file systems impose on the boundaries?
> I'm going to look into this today or tomorrow in any case.

This depends upon the FS i guess, but I doubt the constraints are
really strong.

Cheers,
Guillaume Knispel