From nobody Wed Jan 24 22:28:23 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 4TKzBX1ls4z58r1j for ; Wed, 24 Jan 2024 22:28:36 +0000 (UTC) (envelope-from ggm@algebras.org) Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com [IPv6:2001:4860:4864:20::31]) (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 4TKzBX05PZz4d6q for ; Wed, 24 Jan 2024 22:28:36 +0000 (UTC) (envelope-from ggm@algebras.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-2144c37f3d3so1476255fac.0 for ; Wed, 24 Jan 2024 14:28:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20230601.gappssmtp.com; s=20230601; t=1706135314; x=1706740114; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=IFF2upeg1xJ/qn7Y1Bj7P5CCnHC9/OVYg7f/sT6ryJk=; b=n20ArQNsif17Sz9sYNeIonDsDM6J44hnxodeNphaouF4LyDwvKBtI44liyWDerPdo2 NQ1E3YvOjYa32ZkLSLQv4gyc6ETseLLZUXMyD6S1wxqRgukqJGhzKDnLoZ0yD0o31bQk eyMWn5aURAQuKUnGbTB0AKCwO59M4BcPLt/nIiCv28cUUEGuH7CO7vz+5ZCyCcsIdpxx eDlSp96i2mKU9NattxtOBTtrWengSj+9IUqGrZeUenjg9yp8Us9hNbldVQr8662KObye aGDyFHmzeiXzTo0Fy+zkQ6Dg68qUOUvH5XgezXvUia5yW4mApwE4ZIx3q21jEdpOav6r x1Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706135314; x=1706740114; h=content-transfer-encoding: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=IFF2upeg1xJ/qn7Y1Bj7P5CCnHC9/OVYg7f/sT6ryJk=; b=sWKrDPDm/vgY7fuc5+cOnxlBhL931VxhMHpbPbI4+png6UkIYbdNyYFcUbVeV2flxs OHE1NgBWMCC++Xfv/Tt2rWq08t+zOP1Srg8Z4Ac15DVgGM3VWr3Ot/4p+aYc9MIjiIN/ Lc5BdsdPyDZQZsSAq+/nJulpF64R8XFDj6DYn9ok1Vt5tKqEGR1u/diu6JVQQXECluR4 0r/M/3gKaFMzOCZkv/fy1Rb4dTbiVzi8Hdkn3Akx+dGAIaQhu/LG+WGGUxZev+vkxMjF ZZJ4bfv7pB82wmztb25jsnVwn94rxcvZPhT6icJudgQvsIzoybUWq/UsqDynJJfmC+7P +f6Q== X-Gm-Message-State: AOJu0YzN+FRnMI3mxn6TwcFiHerdjl+NnGoGJF2o5w8AB944K7m1YRff 3nPIl31OE7SUvjDfkJGqfhtvM9CItSxtY1F31LaH7S+hhetKNK9XpbzuKx/nMaRWVPnc20Pg450 nO6Z3z66ZOvV0zsdqcx7qQIpH2XyPeT6JpVLrNQ== X-Google-Smtp-Source: AGHT+IHQOjsStZCNgKIJGar8LuAOeF1uIXVbcqE09e2OS3BBnL/cBfiFT96ltw+gvEaTOO6Us027mUgf1hCkOmyKdgg= X-Received: by 2002:a05:6870:d207:b0:210:a311:6b38 with SMTP id g7-20020a056870d20700b00210a3116b38mr3763703oac.99.1706135314240; Wed, 24 Jan 2024 14:28:34 -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: George Michaelson Date: Thu, 25 Jan 2024 08:28:23 +1000 Message-ID: Subject: Re: Removing fdisk and bsdlabel (legacy partition tools) To: Warner Losh Cc: Ed Maste , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TKzBX05PZz4d6q 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:2001:4860:4864::/48, country:US] I would agree personally, to moving to ports (eg ports/sysutils) with a DEPRECATED in the DESCR or something, or better yet a Make invokation event to say "superceded, here is how to proceed against advice") or something. -G On Thu, Jan 25, 2024 at 3:30=E2=80=AFAM Warner Losh wrote: > > On Wed, Jan 24, 2024 at 8:45=E2=80=AFAM Ed Maste wro= te: >> >> 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 nee= ded 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 'sek= ret' > 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 >