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:   Sun, 13 Aug 2023 11:08:30 +0200
From:   Willy Tarreau <w@1wt.eu>
To:     Zhangjin Wu <falcon@tinylab.org>
Cc:     david.laight@aculab.com, arnd@arndb.de,
        linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
        tanyuan@tinylab.org, thomas@t-8ch.de
Subject: Re: [PATCH v6 0/2] tools/nolibc: fix up size inflat regression
Message-ID: <20230813090830.GF8237@1wt.eu>
References: <cover.1691788036.git.falcon@tinylab.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cover.1691788036.git.falcon@tinylab.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Sat, Aug 12, 2023 at 05:49:36AM +0800, Zhangjin Wu wrote:
> After these two patches, will send the proposed my_syscall() patchset
> tomorrow, it can even further reduce more type conversions and therefore
> reduce more binary bytes, here is a preview of the testing result:
> 
>    // with the coming my_syscall() patchset, sys_* from functionsn to macros
>      i386: 160 test(s): 158 passed,   2 skipped,   0 failed => status: warning 19250
>    x86_64: 160 test(s): 158 passed,   2 skipped,   0 failed => status: warning 21733
(...)
> It can also shrink the whole sys.h from 1171 lines to around 738 lines.

Please, Zhangjin, please. Let's stop constantly speaking about potential
future improvements when the present is broken. It needlessly adds a lot
of noise in the discussion and tends to encourage you to explore areas
that are incompatible with what is required to fix the breakage, and
very likely steers your approach to fixes in a direction that you think
is compatible with such future paths. But as long as existing code is
broken you cannot speculate on how better the next iteration will be,
because it's built on a broken basis. And I would like to remind that
the *only* reason for the current breakage is this attempt to save even
more code lines, that was not a requirement at all in the first place!
Sure it can be fine to remove code when possible, but not at the cost of
trying to force squares to enter round holes like this. The reality is
that *some* syscalls are different and *some* archs are different, and
these differences have to be taken into account, and if we keep exceptions
it's fine.

So let's only speak about this later once the issue is completely solved.

Thanks,
Willy