Re: new PedDisk interface

[Damien Genet]

Hi,

Andrew Clausen wrote:
> Hi all,
> 
> I've been thinking a lot about a new PedDisk interface.
> Motivation for changes:
> * automatic partitioning, allowing things like simulated annealing

sory, i don't understand what a simualted annealing is :(

> * "commit everything at the end" (like fdisk) - more user
> friendly / safer

:)

> * the existing interface is rather awkward - there is lots
> of code duplication between *_{create,open,read,write}

that was also my feeling when looking at disk_*.c files


> So basically, this is the "operation queue" thing.  Sort of.
> 
> I think something like this is best:
> 
> PedDisk* ped_disk_probe (PedDevice* dev);
> int ped_disk_clobber (PedDevice* dev);
> 
> /* creates an empty label in mem */
> PedDisk* ped_disk_new_clean (PedDevice* dev);
> 
> /* creates a label, reading from the device */
> PedDisk* ped_disk_new_from_dev (PedDevice* dev);
> 
> /* destroys the in-memory disk */
> int ped_disk_destroy (PedDisk* disk);
> 
> /* commits all changes to disk */
> int ped_disk_commit (PedDisk* disk);
> 
> 
> int ped_disk_push_checkpoint (PedDisk* disk);
> int ped_disk_pop_checkpoint (PedDisk* disk);
> int ped_disk_flush_checkpoints (PedDisk* disk);
> 
> 
> ped_disk_{push,pop}_checkpoint() are interesting, and probably
> going to be contentious!  I still don't know how I'm going to
> implement it... (I'm still not convinced it's the best way to go...)

hmm, but you will have to push a chekpoint after each (user) operation,
that's what user are waiting for an undo stuff (, no ?)

> Anyway, before we discussed (mainly on IRC) creating a "front end"
> to the existing API, that would have operation queues.  The big
> problem is, it's very difficult to implement "undo" with the existing
> API.  You would have to replay "inverse" operations.  It's impossible
> if you want to preserve pointers.  (If you don't preserve pointers,
> then how do you maintain the identify of partitions, for example?)
> 
> So, with checkpoints, undo is trivial.
> 
> But, implementing checkpoints looks very hard.  The only way I
> can think of is:
> * create a *_duplicate(), which duplicates everything in the
> disk label
> * have a translation list, for pointers, and associated
> memory.  i.e.
> 
> struct _TranslationList {
> TranslationList* next;
> void* orig;
> void* copy;
> size_t length;
> };
> 
> So, creating a checkpoint involves:
> (1) duplicating everything
> (2) remembering the address of everything, by mapping the duplicated
> stuff to their original addresses.
> 
> Restoring a checkpoint involves memcpy() everything from copy to orig.

or creating new objects with same properties...
but i think this is a worst idea.

> Yes, it's UGLY.  I hate it.  Better ideas?

can't we only duplicate changed objects, ie : only partition, fs....
but so you can't use chekpoints i think, or you must predict what will
be changed before pushing a chekpoint,
hmm, this can be done if ped_disk_push_checkpoint() is called in the
beginning of each "acting" function like (ped_partition_destroy()...
ped_file_system_resize()...).
but, then i'm not sure this is still the idea of chekpoints.

> Perhaps a better way to refer to partitions (and everything else), than
> pointers?  Perhaps some identifier code is assigned for PedPartitions,
> PedFileSystems, etc.  Then, for checkpoints, we just need to duplicate
> everything.  Only the PedDisk* needs to have it's address preserved -
> but it's contents don't change, anyway.
> 
> Comments?

sory, i don't see much how identifiers can help, can you explain
more ?

> Side note: the checkpoint stuff can be implemented after the rest.
> I intend to do "the rest" RSN.  i.e. fork off 1.5.x RSN.
> 
> If some people have no idea what I'm talking about, then please
> prod for a deeper explaination.  My mind isn't thinking properly
> today!
> 
> Andrew Clausen

so i resume, for the moment we had 3 different ideas:
* inversible operations
* duplicate only changed objects
* chekpoints

and the main problems are:
* fs stuff must be predict
* interraction between  current code and operation list


Dam