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

[Andrew Clausen]

On Fri, Oct 26, 2001 at 11:09:04AM -0500, Don Mulvey wrote:
> >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);

_arch_device_read() takes a PedDevice, but gets at the fd like you said.
Those casts are unnecessary in practice (but useful here ;)

> 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);

First, disk->type->ops->read is for reading/writing the partition table,
not data within the partition.

IO for within partitions is usually done like this:

        ped_geometry_read (&part->geom, buf, offset, count);

PedGeometry has a very similar interface to PedDevice.  In my Utopia,
they should share an interface, and have vtables, etc.

e.g.
        int
        ped_volume_read (PedVolume* volume, void* buf, PedSector offset,
                         PedSector count)
        {
                return volume->ops->read (volume, buf, offset, count);
        }

And you could do things like:

        ped_volume_read ((PedVolume*) &part->geom, buf, offset, count);
        ped_volume_read ((PedVolume*) dev, buf, offset, count);

Geometry really should have been called "segment".  (Me and Lennert
procrastinated a lot about that one, and couldn't think of anything
better at the time, hehe ;)

> Parted has lots and lots and lots and lots of partition management
> functions: get_name, set_name, dup, align, ....

Right.  The "sane-look-a-like" inteface is much nicer... and that's
how most of it should be wrapped.

align/dup/enumerate/etc. are internal.

> 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.

Right.

> >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.

Please elaborate... I don't see how bbr, etc. are relevant.

Are you thinking of resizing, say?  I would have thought the complexity
was in the engine...

Andrew