From nobody Wed Jan 24 17:30:17 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 4TKrZZ4QKZz58PyT for ; Wed, 24 Jan 2024 17:30:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TKrZY5JNFz51Pc for ; Wed, 24 Jan 2024 17:30:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-55ad2a47b7aso5171611a12.3 for ; Wed, 24 Jan 2024 09:30:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1706117428; x=1706722228; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KY8Wls/2QkA/pAvEneJGY8AAIWQB7UYRxFdArZBzJVo=; b=d1FHorfJwK/g54bZDuITVo+n+6+/69J5hau2kc/QJgadazY6XreATjHT2U7v4kTcYi 1UM2p3+99me2OZCDFedwJ1FWO1PFlO7e3u6w3CwyxXOWTZlJtBIKoQIus+HizQZOtZ6u JIKF9EQAsm2raE/CA8iAWShfz+e551bnbNL7YQD7aEdgHneUPcIPOPBzZAFirjBOtOz6 /u6WB9+TeqkhhnnQaYb8O0pnrWZJ1PliAaiJEDZSuBnb0MTu0k74uTw8XmDrxl2e1WTU wvSumQGGT4l5Myut2EUOHyffi1EcYYAHKMqQCyomUmRb2iWbqRF6xp9ZzJHx88gcGFwH wJ5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706117428; x=1706722228; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KY8Wls/2QkA/pAvEneJGY8AAIWQB7UYRxFdArZBzJVo=; b=aSSY17C9OI3PIZ+/f9YLLo6pGAWKh4iqpBdUUldSuKG+u+kVOu9nDgRWW6tfTqZnJT xqWU4E41nqbwoFqk+QoWijgGfwglxgr7iPdOQfy+EsIdFIn/iRLcvoM/OBN0mD+Pl1Gh sYJV+tEsPnEC9cqpRy2XrZMZmFfm+Be+SRWekDxYIFlUuuuu1QZe17JNB9h5qClHQul7 YietPdpOob6wQoO2eWZuem9jHmrIBeY3Iol2fbHZfgRckSLiTT3SCYqJlv7RHmuE2e4n iRCI/Q/E+1NUYyNeUTj2Eajwx7m+qC38J2fiKc2XEpp9XCsg/5jy2b4VBGK1TEyhJsIv GGUg== X-Gm-Message-State: AOJu0YwkS/cIpZizicfhfQQeA9mLkUiiSfX9iQFAzibX0Tl0NVUAq4ct TmRRK2vvpQM1oBhL0JogwamsnenxiX8jvqRL8ymGFvarqTp465RVSvB0NziYOridWJ9EQmVmm8u xRMj6G/Aamqw8MvrRO+2Ey8WKRL/SZ4FcxJAbcxgdPxQsBHxK+fc= X-Google-Smtp-Source: AGHT+IFqdyOXAP7aZh8IO/sLJVP9z3Ektp+EnU5Q9JIZxmjE2KBA38JAv1MwFrxrqz6XcMGdM3r9ilZuiGxEeMEAhQA= X-Received: by 2002:a05:6402:518b:b0:55c:7b3b:5990 with SMTP id q11-20020a056402518b00b0055c7b3b5990mr1669854edd.7.1706117428432; Wed, 24 Jan 2024 09:30:28 -0800 (PST) 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 References: In-Reply-To: From: Warner Losh Date: Wed, 24 Jan 2024 10:30:17 -0700 Message-ID: Subject: Re: Removing fdisk and bsdlabel (legacy partition tools) To: Ed Maste Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000446006060fb46b31" X-Rspamd-Queue-Id: 4TKrZY5JNFz51Pc 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:15169, ipnet:2a00:1450::/32, country:US] --000000000000446006060fb46b31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 24, 2024 at 8:45=E2=80=AFAM 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. > > 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 > > 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. > 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 --000000000000446006060fb46b31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 24, 2024 at 8:45=E2=80=AFAM E= d Maste <emaste@freebsd.org>= ; wrote:
MBR (PC BIOS) partition tables were historically mainta= ined 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.

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/D4357= 5

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.

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 fi= x, 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, b= ut somewhere around the CHS -> LBA transition things
got weird= with it, and for really big disks there were reports of issues that
<= div>I could never encounter when I set out to fix them... Most likely due t= o a
mismatch in the CHS data and the LBA data being recorded in t= he MBR.
The in-kernel gpart copes so much better.

<= /div>
I wouldn't object to making these ports, but both these progr= ams use 'sekret'
bits from the kernel that might not rema= in exposed as we clean things up.
Though the IOCTLs they do (or u= sed to do) may no longer be relevant. It's
been so long that = I've forgotten....

Warner

--000000000000446006060fb46b31--