Re: [Evms-devel] Re: sanity check

[Andrew Clausen]

On Tue, Nov 06, 2001 at 08:10:56AM -0600, Don Mulvey wrote:
> >Your entire email came through as one paragraph... it would be easier
> >if it was broken up a bit ;)
> 
> Sorry ... I dont have much control over it ... I just do the best I can.

I thought that might be the case :/

> >1.5.x?
> 
> Yup! 1.5.3

You might want to get 1.5.4...

> >ala _arch_device_new() in libparted/device_linux.c?
> >That should be your model ;)
> 
> Right ... However, there seem to be device routines in device_linuc.c that
> I need to circumvent.

No.  You should be writing your own device_evms.c, so to speak.

> So, I created a device type of evms (dev->type ==
> PED_EVMS_DEVICE) and added it to device_linux.c.

I don't like this idea.  EVMS devices are fundamentally different, in
that IO should go through evms, not through the linux syscall interface.
Also, libparted shouldn't be telling the kernel to do discovery, etc.

> >Huh?  _arch_device_new() ped_malloc()'s it's own PedDevice... you
> >should be doing the same thing, IMHO.
> 
> Ok, you mean to say ... malloc a PedDevice in evms and fill in geometry,
> size and stuff?

Yes.  Exactly like _arch_device_new().  Cut&paste the whole file,
and start from there.

> > Currently, I am getting as far as read_table()
> > ( in disk_dos.c  ) but then failing on partition checks.  I think it is
> due
> > to reported geometry and invalid partition allignment.
> >Hmmm, does it usually complain?  (i.e. if you use parted normally)
> 
> Everybody else (including parted) seem happy with the partition scheme.
> That is why I believe I have the PedDevice info wrong or am missing some
> info.  I'll step through the code some more.

Ah, ok.  So, the device->heads, device->sectors, etc, are the same
when called via parted normally, and via evms?

> >YUCK!  Yes, I think this is crazy...
> 
> Could you elaborate?  The basic idea is to malloc a ped_device. Then, call
> to get a new ped_disk which will cause libparted to probe the disk's
> partitioning scheme, attaching a partition list to the ped_disk. Later,
> ped_disk_xxx routines can be called to: add, delete, resize, commit
> partitions.

The "crazy" bit is trying to modify device_linux.c to work with evms.
It should be device_evms.c instead.  (Except, that device_evms.c would
be distributed with evms, not parted.  So, I need to make this possible
via a vtable-type-interface...)

OTOH, your Crazy Design TM shouldn't be hard to fix, once we fix
libparted.  (Can you send me what you've got so far?)

Anyway, I've been thinking about how this should happen.

* EVMS seems to serve as a platform/architecture, like "gnu/hurd"
and "linux".  it (should) provide a way for doing IO, etc.

* there seem to be 2 main types of platforms: those that do discovery
in userland, and those that do them "in-the-kernel" (or whatever).
Linux 2.4 supports both.  BLKRRPART corresponds to "in-the-kernel"
discovery, and BLKPG corresponds to userland discovery.
        ATM, libparted's ped_disk_commit() (basically, "write this
partition table") both writes the partition table, and initiates
rediscovery, by one of the two methods.  ATM, it prefers userland
discovery, because it is more flexible.  (BLKRRPART will fail with
-EBUSY if there are ANY mounted partitions... even if those mounted
partitions weren't affected by any changes)  In the case of userland
discovery, userland needs to know what the partitions ARE, so it
needs to be coupled to the partition code to know this info.

* in EVMS, plugins aren't responsible for initiating [re]discovery.
So, this whole libparted "discovery" API is irrelevant for EVMS.
So, EVMS could provide libparted with dummy _arch_disk_commit(), and
_arch_disk_is_busy() functions.

* even if EVMS is going to be viewed as a platform, it will still
be running on top of Linux.  Should libparted support the Linux
and EVMS interfaces AT THE SAME TIME?  e.g. have an EVMS PedDevice,
and a Linux PedDevice?  (Is this ever useful?  I can't think of any
case)
        So, how should the architecture be selected?  ATM,
the constructor function for libparted doesn't do any arch-specific
stuff.  (All it does is register file system types, etc.)  So,
there should be no problems with having that constructor set some
global variable, ped_architecture, and that being set later by
a user of libparted (by any PedDevice's are created).  Or perhaps
several global variables (ATM: one for PedDisks, and one for PedDevices).
Probably just pointers to vtables.  PedDiskArchOps, and friends.

Any objections?

Andrew