Re: About devfs fixes

[Andrew Clausen]

On Sat, Jul 21, 2001 at 06:01:26PM +0300, Yura Umanets wrote:
> Hi Andrew!
> 
> I sent to address@hidden my parted fixes which help avoid some 
> problems when devfs is used. Sorry, but they includes the broken fixes 
> (about add_history and other :) ). I can send clear devfs fixes. What 
> you think?

I've been thinking lots.  Which is why it's taken me so long.

The patch looks like it's been done in reverse... (or got
parted-1.5.3-pre1-old and parted-1.5.3-pre1 mixed up)

Anyway, I've been thinking about The Issues TM around all of this
(which is why I've taken so long to respond ;)

Partition names (or major/minor pairs) are used to communicate with
the operating system.  This is used for:
 * mounting and unmounting
 * online resizing
 * checking if two partitions/devices/whatever are in fact the same
thing.
 * communicating with external programs.  Eg: mkfs.* use path names.
 * checking if a device is being used by the kernel (i.e. if it's
mounted, or swapped on)

So, this is actually very important.

As I have said before, I think PedGeometry and PedDevice should
share an interface (i.e. PedGeometry should inherit PedDevice, or
something similar).  Likewise PedPartition.

So, the relevant information on Linux is:
* path of /dev entry
* major/minor pair
* mount point

I suspect this may vary from OS to OS.  (eg: the Hurd's store
interface...)

So, I think there should be a generalized way to access information
relevant to communicating with the OS.  So, I'll assume that
a PedDevice knows how to get this information about itself...
i.e. it should be the PedDevice's responsibility.  This is yucky,
because it means we need OS code in all PedDevice stuff (including
partitions, etc.)  But, I don't think this is avoidable.  I think
the OS-specific code should be fairly minimal though.

Same problem for file systems.  Eg: online resizing... usually
online resizers need to be highly coupled to userspace code.
(Eg: you need to know if it can grow and shrink, or just grow,
and to what min/max size, which is online-resizer-specific)

So, I think we need a method:

PedDeviceCookie*
ped_device_get_cookie (PedDevice* dev);

The contents of PedDeviceCookie is OS-specific.

Also, there should be 2 functions defined on cookies:

int
ped_device_cookie_compare (PedDeviceCookie* a, PedDeviceCookie* b);

        which returns 1 IFF a and b refer to exactly the same device
        (address space).  So partitions aren't the same as their
        parent device.

We can add this too if necessary:

int
ped_device_cookie_hash (PedDeviceCookie* cookie);

        Which returns a hash of the cookie.  Cookies that are the
        same (according to ped_device_cookie_compare()) are
        guaranteed to have the same hash, but there may be collisions.
        Hash values should persist during the life-time of
        ped_{init,done}().
                The motivation for this is to allow the construction
        of the device-list in O(N) time (not O(N²) time!).  Might
        be important for big clusters...


Anyway, this is all out-of-scope for 1.4.x, and probably 1.5.x too.
This inheritance stuff is a PITA in C, and I'm tempted to use GObject
which will be in glib 2.0, when they release the damn thing!  (Also,
GObject has other nice things, like ref-counting, and properties)
While we're at it, we can probably use GList's, etc.


So, back down to planet earth, for now, we should:
 * not bother about duplicate devices
 * not bother about adding PedDisk.path.  It already exists in
PedDevice, and it's a device thing, not a partition table thing,
anyway.
 * make a temporary ped_partition_get_path(), and make it handle
devfs (and RAID, etc.) properly, and make everything use it.

Andrew