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
Date: Sun, 13 Aug 2023 11:08:30 +0200 [thread overview]
Message-ID: <20230813090830.GF8237@1wt.eu> (raw)
In-Reply-To: <cover.1691788036.git.falcon@tinylab.org>
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
next prev parent reply other threads:[~2023-08-13 9:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-11 21:49 [PATCH v6 0/2] tools/nolibc: fix up size inflat regression Zhangjin Wu
2023-08-11 21:50 ` [PATCH v6 1/2] tools/nolibc: let sys_brk, sys_mmap and sys_mmap2 return long Zhangjin Wu
2023-08-11 21:51 ` [PATCH v6 2/2] tools/nolibc: fix up size inflate regression Zhangjin Wu
2023-08-13 9:00 ` Willy Tarreau
2023-08-13 13:39 ` Zhangjin Wu
2023-08-14 7:25 ` Willy Tarreau
2023-08-15 12:17 ` Willy Tarreau
2023-08-15 16:34 ` Zhangjin Wu
2023-08-13 9:08 ` Willy Tarreau [this message]
2023-08-13 13:56 ` [PATCH v6 0/2] tools/nolibc: fix up size inflat regression Zhangjin Wu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230813090830.GF8237@1wt.eu \
--to=w@1wt.eu \
--cc=arnd@arndb.de \
--cc=david.laight@aculab.com \
--cc=falcon@tinylab.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=tanyuan@tinylab.org \
--cc=thomas@t-8ch.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox