Re: Removing fdisk and bsdlabel (legacy partition tools)

> Am 25.01.24 um 16:38 schrieb Ed Maste:
> > On Wed, 24 Jan 2024 at 12:30, Warner Losh <imp@bsdimp.com> wrote:
> >>
> >> Those are the only users in the tree, but not for long :)
> > 
> > I have some reviews open to remove some old fdisk / diskabel /
> > bsdlabel invocations from the tree.
> > 
> > With those applied, for fdisk I see the following references
> > (excluding sbin/fdisk/* and comments, old examples, etc.):
> > 
> > contrib/netbsd-tests/sbin/gpt/t_gpt.sh
> 
> This test contains NetBSD specific details and will not run
> on FreeBSD.
> 
> > tests/sys/cddl/zfs/bin/zpool_smi.ksh
> 
> More than 99% of the tests in tests/sys/cddl/zfs are skipped,
> including this one, which relies on commands that do not exist
> on FreeBSD.
> 
> > For bsdlabel / disklabel:
> > 
> > sbin/growfs/tests/legacy_test.pl
> 
> This test could easily be changed to use gpart.
> 
> > tools/regression/msdosfs/msdosfstest-2.sh
> 
> Trivially fixed.
> 
> > tools/regression/tmpfs/t_vnd
> 
> Trivially fixed.
> 
> > tools/tools/nanobsd/legacy.sh
> 
> Does already use gpart and could easily be fixed.
> 
> > contrib/netbsd-tests/kernel/t_umount.sh
> > contrib/netbsd-tests/kernel/t_umountstress.sh
> > contrib/netbsd-tests/sbin/gpt/t_gpt.sh
> 
> These are unused and won't run without modification.
> 
> > sbin/newfs/runtest00.sh
> > sbin/newfs/runtest01.sh
> 
> Unused and do not run on a current version of FreeBSD.
> 
> > These will need to be addressed before actually removing any of these
> > binaries, of course.
> 
> I could fix those that are actually usable and installed on
> a current FreeBSD system within at most 1 hour.
> 
> >> I wouldn't object to making these ports, but both these programs use 'sekret'
> >> bits from the kernel that might not remain exposed as we clean things up.
> >> Though the IOCTLs they do (or used to do) may no longer be relevant. It's
> >> been so long that I've forgotten....
> > 
> > If we eventually stop exporting those kernel interfaces the tools
> > would fail anyway, so IMO we can keep providing the kernel interfaces
> > along with the headers etc, and keep building from source until/unless
> > we drop support altogether.
> 
> The bsdlabel/disklabel/fdisk programs could be rewritten using
> gpart without too much effort, at least for the use cases that

That would be wonderful.  Even just getting it to spit out
the FULL MBR values that are in a protective 0x238 MBR
would go along way to diagnose some corrupt GPT disks.

> have not become obsolete (e.g. CHS specifications) and only for
> use in scripts (i.e. no fdisk interactive edit mode).

You are fooling yourself if you think an MBR and CHS values
are obsolete.  GPT *IS* a type 0x238 MBR and see how many
BIOSes you can crash by writting garbage (Especially 0x0)
to the CHS values.  That MBR must have proper values, and
you cant just ignore that they exist.

> 
> Even parsing of the disktab format and a conversion to gpart
> backup format for use by gpart restore should not be too hard.
> 
> That would keep the commands available for those that use them
> in scripts outside the FreeBSD sources, but would also allow to
> remove the kernel interfaces used by those legacy tools.
> 
> I'd be willing to write those emulations of legacy tools, if
> there is interest in going that way ...

I would be interested in seeing these.
For me gpart does do a lot of things, but it is missing
some very low level stuff that is probably should have.

> Regards, STefan
-- 
Rod Grimes                                                 rgrimes@freebsd.org