Re: [Evms-devel] Porting GNU Parted to EVMS

[Don Mulvey]

>s/PedDevice/PedDisk/ ?
>PedDevice == block devices
>PedDisk == partition tables

I think the comparison goes "sorta" like this ...

PedDevice == disk storage object

I/O to a disk storage object is through the plugin function table.  I/O to
the PedDevice is via arch_specific routines.

((struct plugin_function_s *)logical_disk->plugin->functions.plugin)
->read(a,b,c,d);
_arch_device_read( ((LinuxSpecific *) ((PedDevice *)dev)->arch_specific)
->fd, a,b,c,d);

The evms runtime code does all the device probing and provides this info to
the engine code via an ioctl call.
There are no seek operations on a disk storage object. You read/write to
the logical sector number.



PedPartition == segment storage object

I/O to a segment object is through the plugin function table.  I/O to a
PedPartition is via PedDisk's PedDiskOps.

((struct plugin_function_s *)disk_seg->plugin->functions.plugin)
->read(a,b,c,d);
((PedDisk *)((PedPartition *)ped_part)->disk)->ops->read
((PedDevice)dev,a,b,c,d);


Parted has lots and lots and lots and lots of partition management
functions: get_name, set_name, dup, align, ....
The segment storage object answers to commands like: expand, shrink,
delete, create, ...




PedDisk == dunno ... sorta like a container with partitions, partition
commands and some disk commands for reading labels and such.

Seems kinda like a segment manager plugin because PedDisk instances manage
partitioning schemes.



>> The evms segment plugin is suppose to respond
>> to the commit command by writing its partition scheme to the disk ...
and
>> nothing more ... that is how it contributes to the entire commit
procedure.
>> Following the segment plugin commits ... feature plugins can commit
their
>> metadata.  Ah ... a segment manager is but cog in wheel of life ;-)

>OK, sounds sane.  So, the solution is to make the "EVMS port" of PedDisk
>do nothing but write to disk.

Sounds too simple. PedDisk needs to interact with various user interfaces,
to manage partitioning schemes, found on local and clustered disks, working
within a volume stack where: volume groups(aix,lvm,..) and
features(bbr,drivelinking,snapshot,..) may be using the partitions, with
the engine orchestrating changes.

You said you were looking at the os2 seg mgr plugin code.   I'll be looking
at libparted code over the weekend ... esp PedDevice ...  pretty neat stuff
... perhaps I'll understand things a bit better by Monday ... ;-)

-Don