[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ped_disk_alloc() mis-features
From: |
Andrew Clausen |
Subject: |
Re: ped_disk_alloc() mis-features |
Date: |
Sat, 13 Jan 2001 15:15:06 -0200 |
address@hidden wrote:
>
> Andrew,
>
> A small gripe with 1.4.6. ped_disk_alloc() must set disk->disk_specific =
> NULL, otherwise future PED_ASSERT(disk->disk_specific != NULL) tests can't
> work.
>
> The problem then becomes that ped_disk_alloc() calls ped_partition_new() to
> allocate freespace, before a callback to disk specific code has been made.
> No code in disk_xxx.c can execute to allocate their own disk_specific data
> prior to getting a call to xxx_partition_new(), which may well expect that
> disk->disk_specific be valid...
I see. But is this necessary for free space partitions?
> I recommend adding a new function to disk_ops:
> static PedDisk * (*disk_new)(PedDisk * disk);
>
> If !NULL, disk_new is called in ped_disk_alloc() after allocating disk, but
> before calling ped_partition_new(). That way disk specific code can
> allocate disk_specific themselves, rather than waiting for the first
> invocation of xxx_partition_new() which is the wrong place IMHO to allocate
> that.
>
> Thoughts?
Symbiotic relationships cause pain!
It's yucky whatever way you look at it. BTW: you don't have to use
ped_disk_alloc(), although I can't see why a free space partition
needs disk label specific data...
Perhaps the solution is to create disks in update mode (so they
don't need the free space partition). This is much simpler/nicer.
Why didn't I think of this before? ;-)
I think I'll fork off 1.5.x soon and do this. I don't want to do
this to 1.4.x, although I will if you shout loud enough ;-)
Thanks,
Andrew Clausen