From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E3A2E7E642 for ; Tue, 26 Sep 2023 14:37:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233299AbjIZOhP (ORCPT ); Tue, 26 Sep 2023 10:37:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231137AbjIZOhM (ORCPT ); Tue, 26 Sep 2023 10:37:12 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 72AC9101; Tue, 26 Sep 2023 07:37:06 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02376C433C8; Tue, 26 Sep 2023 14:37:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695739026; bh=2NvGlKjGPmS59w7M/PVsQ0zOobsxsCNxbWVuC18Xz+Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=V0A5OdboYGi/BMVyBFZlepKCiGKAKAHP0O8iO/FE+rDWXdPJoD7t3JkIMi3pQeC9W mgUPJswwYx47wSPqtYNYj6Q/K/Dbg6i72lxgC0WOyyQYGApXCeztrhIv3XTI7wQ2yg 4LNNKreUN5GNfkMlJJGbIS1vd/i5p294BsIReAtMmEn5IvMqBIR2e/MYgCs3ncBXZk NmdgMgHynsRs9x7NI5FEq3iaYllJGm7udNH7Ft81u/6nj8aA6QMG1tUWEhPVXb3w09 lbcD+Y2hNdkxpUdiEmkoXttiwkC1CosYk/f0DKRcER8M6iBqVqqU2i5085rBM8VZuA /6QKrj0bLlmRg== Date: Tue, 26 Sep 2023 16:36:59 +0200 From: Christian Brauner To: Florian Weimer Cc: Miklos Szeredi , Miklos Szeredi , Linus Torvalds , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-man@vger.kernel.org, linux-security-module@vger.kernel.org, Karel Zak , Ian Kent , David Howells , Al Viro , Christian Brauner , Amir Goldstein Subject: Re: [RFC PATCH 2/3] add statmnt(2) syscall Message-ID: <20230926-parolen-gebohrt-bcb01adc1aae@brauner> References: <20230913152238.905247-3-mszeredi@redhat.com> <20230914-salzig-manifest-f6c3adb1b7b4@brauner> <20230914-lockmittel-verknallen-d1a18d76ba44@brauner> <20230918-grafik-zutreffen-995b321017ae@brauner> <871qeloxj0.fsf@oldenburg.str.redhat.com> <87wmwdnhj1.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87wmwdnhj1.fsf@oldenburg.str.redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org > With an opaque, pointer-carrying struct, copying out the data is not > possible in a generic fashion. Only the parts that the application > knows about can be copied out. So I think it's desirable to have a > fairly exact allocation. This could easily be added if we added size parameters like I originally suggested for the variable sized mnt_root and mnt_point records into struct statmount. If the user specified that they want to retrieve the mnt_root and mnt_mountpoint in @mask and the size for the relevant field is zero then we fill in the required size for the relevant field. If they aren't zero we just try to copy in the data in the relevant pointer field. I prefer this interface as it allows for both strategies: * users that don't care about exact allocation size can just pass a guesstimated buffer usually PATH_MAX/2 or sm * users that care about exact allocation size can query the kernel