From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34]) by sourceware.org (Postfix) with ESMTPS id 53B8A385DC1A for ; Fri, 21 Jul 2023 13:03:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 53B8A385DC1A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-1ba2e911c24so1230126fac.0 for ; Fri, 21 Jul 2023 06:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1689944589; x=1690549389; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=GM/a1OQZn0VJ+NEjpbSD9FWl4M/eM6PsUdNjpH4Th28=; b=JLO8igAEjVrPWA89dFBC2MJgpqOjbaMSExraTyUwH0qKDW55mCjAIaD0sioH5UUtw1 NU9OzL7qXCc7l4/OLWK/5WZLUyYGZwLDlgWBg7Z+PGK93aw+nopC+mcKixdC1WOaxKqm JS1Oz74blekqOfi6CRAZx+sA15usBWtDJyaHSjgv6OF2dES/+Lb3JXUs22X4O3WDvQ45 YIaC8unpAFxKkPNA80V0G9ZxzPX4KXWmgDfACQxluWZXe6AqKLAYQaTWL8IwUNgKkUSt W0q0BZGbiH/iyXL3C84Ai50Xy8gi2TrAA6ix4XbfIHGUzcM/yFRpamm/PTlmWN/orwqF aJCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689944589; x=1690549389; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GM/a1OQZn0VJ+NEjpbSD9FWl4M/eM6PsUdNjpH4Th28=; b=MqPyr8+C/BfJRc6p2vBqWHBTbNh1il68GfkiTpOyqKoqW0KNSyCosP5dONeP6rfXZK bK+NLo8qnPRQfWEOcW0R+x6WIK7ZMEvdyJFf7MtSv1i54jfPDoTcsayeZDNjEF0UeeHM 51Ms//U2UP7KvvpIFGaCWr+bUPUOCmqDjeF+Gr8PsoWiFjcUOgTjSNs8U+BqKaBXxEKz YMYi04nppg2dPo7PDRpsa5zAySZLrwWTNnNavCGN3qA507ToLlC1xnpMHZPWROtW2uVy d7mC2P2s5Q/MoP+Rxwr2xSFNk3Ntn60De8eMftBNbVsvz5z2o0Ugptt4bWn1e58FY5GF 3/Ew== X-Gm-Message-State: ABy/qLZKta8/Fwm+kwwQA/ByDfPu8rLoeC5/gU7z74ZWdCYSzaCLe9TD eLW7yPm2SLxMNBzMPC07WH2jZQ== X-Google-Smtp-Source: APBJJlE7u1FVoqQdqtTRV4Xluc23nIEEAGf+cWQxINNFT0fjS2KCTjImRqY5Y9W3H1p1Gn4rAvkSgw== X-Received: by 2002:a05:6870:63a1:b0:1b0:24d0:5554 with SMTP id t33-20020a05687063a100b001b024d05554mr1940587oap.11.1689944589324; Fri, 21 Jul 2023 06:03:09 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:d4d2:a1c5:8e8b:25fe:79f3? ([2804:1b3:a7c0:d4d2:a1c5:8e8b:25fe:79f3]) by smtp.gmail.com with ESMTPSA id j11-20020a9d7f0b000000b006b9e81d94a7sm1330578otq.70.2023.07.21.06.03.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Jul 2023 06:03:08 -0700 (PDT) Message-ID: <4f0ff835-ef3d-5739-6d6d-1a360d97fd68@linaro.org> Date: Fri, 21 Jul 2023 10:03:05 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v3 2/3] linux: statvfs: allocate spare for f_type Content-Language: en-US To: =?UTF-8?B?0L3QsNCx?= Cc: Florian Weimer , libc-alpha@sourceware.org References: <662dabdece8e902a1234b84cdc46ffefb107397d.1688396342.git.nabijaczleweli@nabijaczleweli.xyz> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <662dabdece8e902a1234b84cdc46ffefb107397d.1688396342.git.nabijaczleweli@nabijaczleweli.xyz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 03/07/23 11:59, наб via Libc-alpha wrote: > This is the only missing part in struct statvfs. > The LSB calls [f]statfs() deprecated, and its weird types are definitely > off-putting. However, its use is required to get f_type. > > Instead, allocate one of the six spares to f_type, > copied directly from struct . > This then becomes a small glibc extension to the standard interface > on Linux and the Hurd, instead of two different interfaces, one of which > is quite odd due to being an ABI type, and there no longer is any reason > to use statfs(). > > The underlying kernel type is a mess, but all architectures agree on u32 > (or more) for the ABI, and all filesystem magicks are 32-bit integers. > > Link: https://lore.kernel.org/linux-man/f54kudgblgk643u32tb6at4cd3kkzha6hslahv24szs4raroaz@ogivjbfdaqtb/t/#u > Signed-off-by: Ahelenia Ziemiańska > --- > sysdeps/unix/sysv/linux/bits/statvfs.h | 6 ++++-- > sysdeps/unix/sysv/linux/internal_statvfs.c | 2 ++ > 2 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/sysdeps/unix/sysv/linux/bits/statvfs.h b/sysdeps/unix/sysv/linux/bits/statvfs.h > index 8dfb5ce761..cf98460e00 100644 > --- a/sysdeps/unix/sysv/linux/bits/statvfs.h > +++ b/sysdeps/unix/sysv/linux/bits/statvfs.h > @@ -51,7 +51,8 @@ struct statvfs > #endif > unsigned long int f_flag; > unsigned long int f_namemax; > - int __f_spare[6]; > + unsigned int f_type; > + int __f_spare[5]; > }; > > #ifdef __USE_LARGEFILE64 > @@ -71,7 +72,8 @@ struct statvfs64 > #endif > unsigned long int f_flag; > unsigned long int f_namemax; > - int __f_spare[6]; > + unsigned int f_type; > + int __f_spare[5]; > }; > #endif > All ABIs define fstatfs/statfs64 as signed, as the constants in include/uapi/linux/magic.h. Should we do the same here? > diff --git a/sysdeps/unix/sysv/linux/internal_statvfs.c b/sysdeps/unix/sysv/linux/internal_statvfs.c > index 6a1b7b755f..112d3c241a 100644 > --- a/sysdeps/unix/sysv/linux/internal_statvfs.c > +++ b/sysdeps/unix/sysv/linux/internal_statvfs.c > @@ -57,6 +57,7 @@ __internal_statvfs (struct statvfs *buf, const struct statfs *fsbuf) > buf->__f_unused = 0; > #endif > buf->f_namemax = fsbuf->f_namelen; > + buf->f_type = fsbuf->f_type; > memset (buf->__f_spare, '\0', sizeof (buf->__f_spare)); > > /* What remains to do is to fill the fields f_favail and f_flag. */ > @@ -99,6 +100,7 @@ __internal_statvfs64 (struct statvfs64 *buf, const struct statfs64 *fsbuf) > buf->__f_unused = 0; > #endif > buf->f_namemax = fsbuf->f_namelen; > + buf->f_type = fsbuf->f_type; > memset (buf->__f_spare, '\0', sizeof (buf->__f_spare)); > > /* What remains to do is to fill the fields f_favail and f_flag. */