Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 13 Apr 2023 10:33:54 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Willy Tarreau <w@1wt.eu>
Cc:     Mark Brown <broonie@kernel.org>,
        Thomas =?iso-8859-1?Q?Wei=DFschuh?= <linux@weissschuh.net>,
        Shuah Khan <shuah@kernel.org>, linux-kernel@vger.kernel.org,
        linux-kselftest@vger.kernel.org
Subject: Re: [PATCH] tools/nolibc: Fix build of stdio.h due to header ordering
Message-ID: <c8021d03-4da0-4956-8744-4a3a1f8dd533@paulmck-laptop>
Reply-To: paulmck@kernel.org
References: <20230413-nolibc-stdio-fix-v1-1-fa05fc3ba1fe@kernel.org>
 <ZDg3K2nI+5l6as/L@1wt.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZDg3K2nI+5l6as/L@1wt.eu>
Precedence: bulk

On Thu, Apr 13, 2023 at 07:08:59PM +0200, Willy Tarreau wrote:
> Hi Mark,
> 
> Sorry for this issue, I don't know why it didn't trigger in our tests,
> maybe due to the includes being explicit in the test program.
> 
> On Thu, Apr 13, 2023 at 05:26:32PM +0100, Mark Brown wrote:
> > When we added fd based file streams we created references to STx_FILENO in
> > stdio.h but these constants are declared in unistd.h which is the last file
> > included by the top level nolibc.h meaning those constants are not defined
> > when we try to build stdio.h. This causes programs using nolibc.h to fail
> > to build.
> > 
> > Reorder the headers to avoid this issue.
> > 
> > Fixes: d449546c957f ("tools/nolibc: implement fd-based FILE streams")
> > Signed-off-by: Mark Brown <broonie@kernel.org>
> Acked-by: Willy Tarreau <w@1wt.eu>
> 
> Paul, the commit above is in your rcu/next branch but fortunately not
> in the series you've prepared for 6.4, so it will be sufficient to pick
> it on top of next and you can take it directly if you want.

Queued and pushed, thank you both!

With respect to -next, travel plans next week are causing me to instead
update my rcu/next branch to the merge point of all of this coming
merge window's pull requests.  Though it only makes a difference of a
few days, as I would normally pull rcu/next back the Monday before the
merge window opens.

There is some possibility that I will be off the grid for extended periods
next week, which shouldn't make any difference for nolibc, aside from my
possibly being unresponsive during that time.  The odds of an emergency
fix to last merge window's changes are quite low this late in cycle,
and I will be back before the next merge window opens.

Just let me know what I need to pull in, and I will do that early the
week after this coming one.  Or you can buffer it up and send me one
big series upon my return, your choice.  Either way works for me.  ;-)

							Thanx, Paul