Received: by 2002:a05:6500:1b45:b0:1f5:f2ab:c469 with SMTP id cz5csp693844lqb; Wed, 17 Apr 2024 08:14:17 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWkd77P8FbmfvEmtMGZb0u7L7dfJIspQwCthVjU1nINi2leL0DvcbewtzApDW5yAxmEb1QppKCTk32QIayBIIlmkslVYQvO707kZsollg== X-Google-Smtp-Source: AGHT+IHplrDDYSRu0QKo5gUSo7g36wtWX17NrBddD59FMAoovt4634pZA1qMPeqExZtFKsR9K8p7 X-Received: by 2002:a17:906:7f8a:b0:a55:3488:f730 with SMTP id f10-20020a1709067f8a00b00a553488f730mr4909859ejr.31.1713366857237; Wed, 17 Apr 2024 08:14:17 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713366857; cv=pass; d=google.com; s=arc-20160816; b=Be29Hy01PD3pRj5ZyJ5J+KXni24GrOMyuBDFTRkTW1w28M6IFo3NK4/YZC6+R4DST7 6hivX+w7XbtQOyeCFDPg+NUOx7/+NvwrGdPcTuxpBvvW3rz7TkXgQ7XoSFZEDVkbFgwC Ai/ApfEzUds0cW0UkXFDDh9qUJMCWMi4EVn4Axhx35oUtwhB5cISfmux6ianyYh518Mf kx1RYThfjIrjZ+moYB9mWILsaaTJgLnBE3syuYJ+Ss8tb1Rh88DrdLDrSxYKxH0uOxoO RK5m4MsTO7X04AxyxA/Hvk1g3+Zm5e2M61xx/C/5PTLLv6gailUTqng54b7gD8SqYBlP T4Pw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:references :message-id:subject:cc:to:from:date; bh=QhgaJsnQ4GmWv7Acc5TT4Jj2fJ3BIAgwLyBt0LKT10Q=; fh=xs5Zl4S1ATiVcwjGw+ax7iAD20AXwcnG8Q+gDZi9YJ0=; b=fJwH5WWSccnIx9298HT4k8cguQw7xd9cwXkh+sZcxLyI9clxby05tPjUO40Q74WqEZ bM0iY4Z4cVUeS2SQtcL+P9wnNiMYUvssiy1HqNXKwFwlUr2/6sKJVEbLAQGWdrAqn2Ig KbvjMZ9aYVUsz4ZO/3zQw8+dcmwwMrc2YX5nQWV9daBWb8xuZI9bhPFgt0hl9r48hrP4 ez0nEgKrX3UKjvIZJCvZeDnu96RW+ojZz0KZ66hnYDdO+97RdwUZ7e8VdXyYH+J/ZggX cWYR7JjgXKK+oqrQ5ReyW2Ke3yjJm0WPO9yFe1RiXP+SMOK77L+w5gtbvEVxDlKoV63E Orfg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=lst.de); spf=pass (google.com: domain of linux-kernel+bounces-148771-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-148771-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id b10-20020a17090636ca00b00a51901dc2casi6723912ejc.209.2024.04.17.08.14.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Apr 2024 08:14:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-148771-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=lst.de); spf=pass (google.com: domain of linux-kernel+bounces-148771-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-148771-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 660D61F225E0 for ; Wed, 17 Apr 2024 15:14:14 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D72A91474CC; Wed, 17 Apr 2024 15:13:56 +0000 (UTC) Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 076DC146D41; Wed, 17 Apr 2024 15:13:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713366836; cv=none; b=aMVTrsXJnq0XiOvG7UQOywbqiKD4GaY9G8ysxDQYLajfxRSHHw5Di0wxS8RzbHApmeAICW1BK33DpX0USXXi2zxhrLFbrUBQgAX/nn65oZl1gDmr5AQrZv3C4Ym8UYA2ZLr1UpWr5iv2oNHXOKNZfPcP5oLd94kGDItKSU4BDKs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713366836; c=relaxed/simple; bh=eeHlBHvXaDB3on0ByhfRt5OA6kYCTofvpJLzF7XmYtk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=M+kk4cFhQN5YE/xLldDbn+h0inY7XhHGmHages7La/XwB0KxB5IpkVWVQW5ivJG0pALuSo4plKRe40MVhl4eqSN0JyVJykY/pOA6Bx7cAhUopFxF9MA+PAyZmq6LcXYtssH+TQBfqqaID8KU/XBGchpVXkHIAMM2GCNqGrphT7A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de Received: by verein.lst.de (Postfix, from userid 2407) id 285EF227A88; Wed, 17 Apr 2024 17:13:51 +0200 (CEST) Date: Wed, 17 Apr 2024 17:13:50 +0200 From: Christoph Hellwig To: Keith Busch Cc: Lennart Poettering , Christoph Hellwig , Linux regressions mailing list , linux-block@vger.kernel.org, LKML , Jens Axboe Subject: Re: API break, sysfs "capability" file Message-ID: <20240417151350.GB2167@lst.de> References: <54e3c969-3ee8-40d8-91d9-9b9402001d27@leemhuis.info> <20240409141531.GB21514@lst.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) On Tue, Apr 16, 2024 at 08:44:55AM -0600, Keith Busch wrote: > The patch that introduced this was submitted not because the API was > stable; it was committed to encourage developers to update it as it > changed because it is *not* stable. That's not the kind of interface you > want exported for users to rely on, but no one should have to search > commit logs to understand why the doc exists, so I think exporting it > was just a mistake on the kernel side. To say this doc is "good" > misunderstands what it was trying to accomplish, and what it ultimately > created instead: technical debt. Yes. It might be a problem with the documentation generation mess, but something that is generated from a random code comment really can't be an API document. Anyway, instead of bickering about this, what does systemd actually want to known? Because all these flags we talked about did slightly different things all vaguely related to partition scanning. We also have another GD_SUPPRESS_PART_SCAN bit that is used to temporarily suppress partition scanning (and ublk now also abuses it in really whacky way, sigh). I'm not really sure why userspace would even care about any of this, but I'm open to come up with something sane if we can actually define the semantics.