Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp68136pxk; Wed, 30 Sep 2020 18:09:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxidyB81ktAtykljkdrhm+x+kH4y3MdTJZxomGZKgdp0DsKNO9h6EsSmoOhODvM9ZrxUKy/ X-Received: by 2002:a17:906:9416:: with SMTP id q22mr5544244ejx.82.1601514583093; Wed, 30 Sep 2020 18:09:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601514583; cv=none; d=google.com; s=arc-20160816; b=BN6trahg+Xd/LCoAyIzxWkz0xrBUU3vpeqnR9ChrkAoxeIu+buGzneLjrqU7WFNsp/ /fUqDmdRfMuG7xZSE6UYULLJb/rw0UoNA0zYEUUklGRrmHkIcpGV4+syCTwYlMwfyG7V yZMwJRByLIDRLUScyfeeObZTkmLpROqRF5rKdoKFto6YQYZgpIh0KMTf/P8CQ1p0CRw1 B1TgL8qtoFL1Vcjt1bSnhmOX7mFNoHCxx+GdbBBoztcBVuusQJN1LfBoqGhF9bBiNVQ9 5BnRPimhu0kM8Igs0Udo4C32BbrDapADhvy/3BOqVTmn+uWmSuVgkZxgqjemUgxkNUme Dr+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=eGJGja2fsgsiWCGsmjBcfVwijmdPHllMGQjHa+IRUqM=; b=loR027ld31XDt0gfdLahe31h7L2fPuCftknugGVB8UW3f4ObsO8EQh+ixrxiyuVPIy zuh4IhXHde1qe+uzrDvrN8gRkMkj66jP/gS7v1yovQG/sGSX5oXNbtxtu52F+aUXUHzt GQ/LmMSHpVGMJRTv2vB/LTNowbS3W3DvdhGp1a16yroHSxbTGumnZyNd8PelM/6clRlp 0mfFMjpBJPpKgybySApBub3jDrTx1rHcMl9fK/eqLy5QBS5dGeJXiS3aLMb2XVrPs4ST H6REUZiakuzcRBJR7bu15fuy6udQlh4wRsQxwWfjjWNCD3kLvkiREkSaXOBiSduWE2br Ss9A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l7si2545738edv.115.2020.09.30.18.09.20; Wed, 30 Sep 2020 18:09:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731858AbgI3XmU (ORCPT + 99 others); Wed, 30 Sep 2020 19:42:20 -0400 Received: from brightrain.aerifal.cx ([216.12.86.13]:58822 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730544AbgI3XmN (ORCPT ); Wed, 30 Sep 2020 19:42:13 -0400 Date: Wed, 30 Sep 2020 19:42:12 -0400 From: Rich Felker To: Petr Vorel Cc: linux-kernel@vger.kernel.org, "David S. Miller" , Michal Kubecek , musl@lists.openwall.com Subject: Re: [musl] [PATCH 1/1] linux/sysinfo.h: Add guarder for struct sysinfo Message-ID: <20200930234212.GK17637@brightrain.aerifal.cx> References: <20200930214636.186132-1-petr.vorel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200930214636.186132-1-petr.vorel@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 30, 2020 at 11:46:36PM +0200, Petr Vorel wrote: > for all but glibc libc. > > This fixes redefinition on MUSL which also defines struct sysinfo when > including (which includes via > ) and . > > glibc loads in . > > Signed-off-by: Petr Vorel > --- > include/uapi/linux/sysinfo.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/uapi/linux/sysinfo.h b/include/uapi/linux/sysinfo.h > index 435d5c23f0c0..c8ab18cd36b2 100644 > --- a/include/uapi/linux/sysinfo.h > +++ b/include/uapi/linux/sysinfo.h > @@ -5,6 +5,8 @@ > #include > > #define SI_LOAD_SHIFT 16 > + > +#if defined(__KERNEL__) || defined(__GLIBC__) > struct sysinfo { > __kernel_long_t uptime; /* Seconds since boot */ > __kernel_ulong_t loads[3]; /* 1, 5, and 15 minute load averages */ > @@ -21,5 +23,6 @@ struct sysinfo { > __u32 mem_unit; /* Memory unit size in bytes */ > char _f[20-2*sizeof(__kernel_ulong_t)-sizeof(__u32)]; /* Padding: libc5 uses this.. */ > }; > +#endif > > #endif /* _LINUX_SYSINFO_H */ > -- > 2.27.0.rc0 I don't think this is the right way to do it. It prevents getting access to the kernel uapi structure (which may be wanted) if you're not using glibc or if you include kernel headers before any libc headers. Rather, , whose only real purpose is providing this structure to legacy applications that don't know the renamed name for it, should not be implicitly included by other headers. There's an existing thread on the topic but I don't have the link handy. IIRC I proposed moving the alignment macros or whatever other useful stuff is in to a separate header and getting rid of all the indirect inclusions of . Rich