From nobody Wed Jan 24 18:50:19 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TKtLw6ZkPz58Wyv for ; Wed, 24 Jan 2024 18:50:32 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TKtLw2zwPz3xKv; Wed, 24 Jan 2024 18:50:32 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 40OIoJBG098490; Wed, 24 Jan 2024 10:50:19 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 40OIoJ9o098489; Wed, 24 Jan 2024 10:50:19 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202401241850.40OIoJ9o098489@gndrsh.dnsmgr.net> Subject: Re: Removing fdisk and bsdlabel (legacy partition tools) In-Reply-To: To: Warner Losh Date: Wed, 24 Jan 2024 10:50:19 -0800 (PST) CC: Ed Maste , FreeBSD Current X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4TKtLw2zwPz3xKv X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US] > On Wed, Jan 24, 2024 at 8:45?AM Ed Maste wrote: > > > MBR (PC BIOS) partition tables were historically maintained with > > fdisk(8), but gpart(8) has long been the preferred method for working > > with partition tables of all types. fdisk has been declared as > > obsolete in the man page since 2015. Similarly BSD disklabels were > > historically maintained with bsdlabel. It does not yet have a > > deprecation notice - I have proposed a man page addition in > > https://reviews.freebsd.org/D43563. man page additions are not going to reach the people who may be using this. This should be a gonein(15) added to the binary. I also suspect that all of the people doing ufs installs are doing so via bsdlabel, not gpart. > > > > I would like to disconnect these from the build, and subsequently > > remove them. This is prompted by a recent bsdlabel bug report which > > uncovered a longstanding buffer overflow in that tool. Effort is much > > better focused on contemporary, maintained tools rather than > > investigating issues in deprecated ones. Removing these tools would > > happen in FreeBSD 15 only (no change in 14 or 13). > > > > Code review to disconnect fdisk: https://reviews.freebsd.org/D43575 How can you do bsdlabel -A -e /dev/foo with gpart? As far as I know that functionality never made it to gpart, neither the -A or -e. > > > > Note that this effort is limited to these maintenance tools only - > > there is no change to kernel or gpart support for MBR or BSD > > disklablel partitioning. That said, MBR partitioning and BSD > > disklabels are best considered legacy formats and should be avoided > > for new installations, if possible. > > > > If anyone is using fdisk and/or bsdlabel rather than gpart I would > > appreciate knowing what is preventing you from using the contemporary > > tools. My prototype files that are read by bsdlabel -R as far as I know can not be processed by gpart. fdisk I can probably get away from, but thats a working binary accross a lot of platforms which do not have gpart. > > > > nanobsd's legacy.sh still is using disklabel in two spots. > > But one is to just do gpart create -s bsd and the other is to display it. > Easy > to fix, but even easier to delete legacy.sh entirely. It's not really > needed any > more and was a product of CHS addressing... Now that we use LBA, it's > better to use the new embedded ones. Even at $WORK where we kinda > use legacy, we replace the partitioning stuff with our own custom thing... > > Those are the only users in the tree, but not for long :) > > fdisk was good, but somewhere around the CHS -> LBA transition things > got weird with it, and for really big disks there were reports of issues > that > I could never encounter when I set out to fix them... Most likely due to a > mismatch in the CHS data and the LBA data being recorded in the MBR. > The in-kernel gpart copes so much better. > > 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.... > > Warner -- Rod Grimes rgrimes@freebsd.org