From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="RidsUlOg" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 365B898 for ; Thu, 16 Nov 2023 12:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700167001; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aM588nCLOMRy9nyQwkvqYwn6Kk0o6YyUQbITALEnpPc=; b=RidsUlOgm1Akk+4v61NVLWwwU2JSV/kd2H3S9DgHK74rSBv0ED7PRj7J4B4soB3U5jOIpm DoyFC1VTZo6y9gRHJ/2AbHbPBCVJ94TIoWINFmNvv1P7jQVm3K6gyYdrsnN5FXhh9bvEZQ gnvhXgXBJzRgaW52Vx4bHM7wTVKtlRw= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-588-oZKvOkczMViKr_5ETt-vCw-1; Thu, 16 Nov 2023 15:36:39 -0500 X-MC-Unique: oZKvOkczMViKr_5ETt-vCw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id F3038101A590; Thu, 16 Nov 2023 20:36:38 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.3]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AD6431C060AE; Thu, 16 Nov 2023 20:36:36 +0000 (UTC) From: Florian Weimer To: Miklos Szeredi Cc: libc-alpha@sourceware.org, linux-man , Alejandro Colomar , Linux API , linux-fsdevel@vger.kernel.org, Karel Zak , Ian Kent , David Howells , Christian Brauner , Amir Goldstein , Arnd Bergmann Subject: Re: proposed libc interface and man page for statmount(2) References: Date: Thu, 16 Nov 2023 21:36:35 +0100 In-Reply-To: (Miklos Szeredi's message of "Wed, 15 Nov 2023 16:08:55 +0100") Message-ID: <87fs15qvu4.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 * Miklos Szeredi: > Hi, > > Attaching the proposed man page for the new statmount() syscall. > > It describes a libc interface that is slightly different from the raw > kernel API. The differences from the two API's are also described in > the man page. > > Raw: > > long syscall(SYS_statmount, const struct mnt_id_req *req, > struct statmount *buf, size_t bufsize, unsigned int flags); > > Libc: > > struct statmount *statmount(uint64_t mnt_id, uint64_t request_mask, > struct statmount *buf, size_t bufsize, > unsigned int flags); > > I propose the libc one to allow automatically allocating the buffer if > the buf argument is NULL, similar to getcwd(3). In addition to Adhemerval's observation that we'd prefer to have some hint regarding the buffer size, it's probably better to have entirely separate interfaces because it makes static analysis easier. With a unified interface, we can still convey the information with an inline wrapper function, but we can avoid that complexity. Thanks, Florian