Loading...

freebsd-geom@freebsd.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: A replacement for GEOM_LABEL's gpt/gptid Jason J. Hellenthal Thu Apr 28 21:00:34 2011

Andrey,

Great work, thank you. I have a little destraught about this over the
years since its inception with having just a label class for itself. Now
that this has all be properly tested it seems like a good idea to me to
split them up into their respective sections as you have done.

Now with the following I have some insight and question of if these
sysctls are really needed.

>> 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
>

As I see from the patch listed above, you have properly turned off the
support of these in the label class to move them to the consumers that
they are actually used in.

With that said, I do not understand and cant seem to wrap my mind around
why there needs to be a compatibility layer to provide both a sysctl for
what you have done and the old sysctl.

Why if this is only going to be used by the class where it is only
enabled do we need two sysctl ?

Can we not just keep them under the same OID they are under now ? It is
just a label after all and I dont see a need for renaming the sysctl.

>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.
>
>


Anyway, thank you for you time.

-- 

 Regards, (jhell)
 Jason Hellenthal