Re: A replacement for GEOM_LABEL's gpt/gptid

On 25.04.2011 14:38, Andrey V. Elsukov wrote:
> I wrote a small extension for the GEOM_PART class. It adds an ability
> to GEOM_PART class to create partition labels for schemes which are
> support them.
> 
> Currently we have GEOM_LABEL class which does similar functions,
> but it has problems in conjunction with GEOM_PART (e.g. kern/154226).
> Current implementation of GEOM_LABEL's gpt/gptid module does direct
> access to GEOM_PART object structures, that seems not so good for me.
> 
> So, my patch contains:
> 
> * new GEOM class "PART::LABEL". It attaches to partition provider and
> create new providers for each label.
> 
> * new kobj method - G_PART_LABELS. It called when new partition is creating.
> A partition scheme can implement this method if it supports partition labels.
> Method should just call g_part_create_label() function to create new label for
> given partition.
> 
> * g_part_spoil_labels() function. It called from GEOM_PART to destroy labels
> providers or mark them stale. At this time it called only from "gpart modify"
> method.
> 
> What differs from GEOM_LABEL:
> 
> * PART::LABEL class has not ".spoiled" method and all providers are persistent.
> 
> * if label is changing while provider is in use, it will not be destroyed until
> access does not released, but new label will become available.
> 
> * also it has support for APM and PC98 schemes.
> 
> The patch is here:
> http://people.freebsd.org/~ae/gpart_labels.diff

I updated the patch, it is in the same location.
I turned off glabel's gpt/gpid support and added loader tunables:

kern.geom.part_label.apm.enable
kern.geom.part_label.gpt.enable
kern.geom.part_label.gptid.enable
kern.geom.part_label.pc98.enable

Also for compatibility glabel's tunables still here:

kern.geom.label.gpt.enable
kern.geom.label.gptid.enable

So, if you have them in your loader.conf and want to have gpt/gptid labels,
you should remove them from loader.conf.
Also now they are only loader tunables and they can not be changed in runtime.

If there will no objections i am planning to commit patch in this weekend.

-- 
WBR, Andrey V. Elsukov