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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:13 UTC