RFC: making gpart default

[Marcel Moolenaar]

All,

I'd like to switch all architectures to gpart for the reasons given
below. All current partitioning schemes are supported by gpart and
work on all platforms. On top of that, ia64 and powerpc are using
gpart exclusively already.

Rationale:
1.  Having different utilities for different schemes, which are
     otherwise identical in functionality, is painful. Especially
     since they all provide a different user interface. While this
     is a non-issue for the old geezers among us (we don't know any
     better), it is something that the younger crowd perceives as
     "low-quality", especially when compared to Linux' parted.
     However, the fact that some allow scripting while others
     don't is important even for the old geezers. gpart(8) is the
     answer.
2.  We currently have multiple GEOMs in the kernel that do not
     provide a unified, common and/or standard interface. This is
     especially problematic for unified tools like the installer.
     In fact, we don't have unified tools that use the ctlreq
     interface at all, because it's virtually impossible. The
     fact that we have sade, is an indication that we do want a
     unified tool for partitioning, but without using the GEOM I/F
     the tool is useless to modify partitions on a disk with
     mounted file systems. The gpart GEOM provides a unified I/F
     usable by any tool for creating and modifying any kind of
     partitioning scheme.
3.  fsck and newfs contain some logic to find out what kind of
     file system they're working on and invoke the appropriate
     back-end executable. This is good functionality, but only
     works for BSD labels. With GPT being used more often and
     non-PC hardware using different partitioning schemes, this
     means that the functionality isn't working in most cases.
     There's fundamentally no reason why newfs or fsck cannot
     automatically detect a partition that uses the MSDOS file
     system and DTRT. With gpart, we can make that functionality
     working across all partitioning schemes.
4.  Like the above, but for mount. By checking the partition
     type, it's possible to have mount DTRT much more often.
5.  The gpart show command can give you a unified list of disks
     with their partitions, irrespective of the partitioning
     scheme used. For the first time a single command gives us
     the overview we're lacking.
6.  Not all "disk" devices have a geometry. Especially md(4)
     devices and USB mass storage devices. This is a problem
     for newfs_msdos. With gpart, there's always a geometry
     that processes can query for so that newfs_msdos et al
     will work without any additional options.
7.  gpart breaks the 8-partition barrier for bsdlabel.
8.  gpart adds VTOC information to sunlabel.

With gpart default, tools like fdisk and bsdlabel continue to
work on new disks and disks that have no mounted file systems.
In that respect there's no difference. However, they cannot
be used when file systems are mounted. In those cases gpart
needs to be used. As such, the impact is limited and makes the
switch much more manageable.

In short: gpart is the first step towards a unified set of
tools and interfaces and provides the basis for extending
file system related tools by allowing us to attach real
meaning to partition types. With the commit and undo feature,
gpart is ready for use by next generation installers that
allow us to use any partitioning scheme on any platforms.

Thoughts?

-- 
Marcel Moolenaar
xcllnt at mac.com