grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Remove has_paritions


From: Vladimir 'phcoder' Serbinenko
Subject: Re: [PATCH] Remove has_paritions
Date: Sun, 30 Aug 2009 15:44:51 +0200

On Sun, Aug 30, 2009 at 3:33 PM, Robert Millan<address@hidden> wrote:
> On Fri, Aug 28, 2009 at 09:25:15PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> diff --git a/disk/lvm.c b/disk/lvm.c
>> index 126b494..59bf2d7 100644
>> --- a/disk/lvm.c
>> +++ b/disk/lvm.c
>> @@ -97,7 +97,6 @@ grub_lvm_open (const char *name, grub_disk_t disk)
>>    if (! lv)
>>      return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "Unknown LVM device %s", 
>> name);
>>
>> -  disk->has_partitions = 0;
>>    disk->id = lv->number;
>>    disk->data = lv;
>>    disk->total_sectors = lv->size;
>
> Why would LVM users want to nest partition maps in them?
>
> This makes me think removing has_partitions is not such a good idea.
>
Probing for partition map when already probing for fs is cheap.
has_partitions gets in the way of probing and the need for it was
dictated by FAT floppies being detected as msdos partmap. This was
recently fixed (by checking bootflags) and now has_partitions has
become an artifact needing support in code, increasing code size and
no benefit.
> Actually, LVM is a partition map of sorts.  If we're going to refurbish our
> partition handling model, I think we should contemplate the possibility of
> LVM (and perhaps swRAID) becoming less ad-hoc.
>
I would happy if we could do it someway considering LVM can span
across multiple devices. We have to consider multidrive filesystems
like zfs and btrfs too.
> But that is more an idea for 2.0.  What are our inmediate needs?
This was actually triggered by grub2 not seeing partitions on Apple
bootable CDs just because has_partitions=0. I vaguely remember I
noticed other places where has_partitions was set in a heuristical way
but can't point it now
>
> --
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git




reply via email to

[Prev in Thread] Current Thread [Next in Thread]