From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
git@vger.kernel.org, Sam James <sam@gentoo.org>,
Andreas Larsson <andreas@gaisler.com>
Subject: Re: [PATCH] chainlint.pl: Extend regexp pattern for /proc/cpuinfo on Linux SPARC
Date: Mon, 20 May 2024 10:23:59 -0700 [thread overview]
Message-ID: <xmqqbk50jt1s.fsf@gitster.g> (raw)
In-Reply-To: <CAPig+cQsc4AUJ7-0v=rS8VVK9JG1+_iSwa_gWUUigs=uwYq6Lw@mail.gmail.com> (Eric Sunshine's message of "Mon, 20 May 2024 12:50:12 -0400")
Eric Sunshine <sunshine@sunshineco.com> writes:
>> I was wondering if we want to first add the "reasonable fallback"
>> Eric mentioned ealier, and then build on top, whose result may look
>> like the attached.
>
> I'm fine with a well-focused patch which just fixes the reported
> problem; the "reasonable fallback" change can be layered atop at any
> time.
Yeah, I never suggested to do these in a single patch. Since I
would think that it is easier to do and review a patch that cleans
up the code and adds a reasonable fallback before adding new support
for sparc or alpha (after all, such a clean-up is also for longer
term maintainability---by definition, it must be easier to add new
support to the result of a clean-up than the original, or it is not
a clean-up), I suggested to first add such a change. What you saw
was how the result of "then build on top" would have looked like.
> I had a more all-inclusive change in mind. These number-of-cpu checks
> are in order from least to most costly but they are not necessarily
> mutually exclusive. As such, my thinking was that the logic would fall
> through to the next check if the preceding check produced zero or
> nonsense.
OK. All the more reason to clean-up first, then? If we pile more
on top of the current structure, it would make the later clean-up
more cumbersome, wouldn't it?
Thanks.
next prev parent reply other threads:[~2024-05-20 17:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-20 11:11 [PATCH] chainlint.pl: Extend regexp pattern for /proc/cpuinfo on Linux SPARC John Paul Adrian Glaubitz
2024-05-20 16:16 ` Junio C Hamano
2024-05-20 16:48 ` John Paul Adrian Glaubitz
2024-05-20 16:52 ` Eric Sunshine
2024-05-20 16:50 ` Eric Sunshine
2024-05-20 17:07 ` Eric Sunshine
2024-05-20 17:23 ` Junio C Hamano [this message]
2024-05-20 19:01 ` [PATCH 0/3] improve chainlint.pl CPU count computation Eric Sunshine
2024-05-20 19:01 ` [PATCH 1/3] chainlint.pl: make CPU count computation more robust Eric Sunshine
2024-05-20 19:01 ` [PATCH 2/3] chainlint.pl: fix incorrect CPU count on Linux SPARC Eric Sunshine
2024-05-22 8:32 ` Carlo Marcelo Arenas Belón
2024-05-22 8:47 ` John Paul Adrian Glaubitz
2024-05-22 9:05 ` Eric Sunshine
2024-05-22 19:00 ` Junio C Hamano
2024-05-22 19:11 ` Eric Sunshine
2024-05-27 19:48 ` John Paul Adrian Glaubitz
2024-05-27 20:12 ` Eric Sunshine
2024-05-20 19:01 ` [PATCH 3/3] chainlint.pl: latch CPU count directly reported by /proc/cpuinfo Eric Sunshine
2024-05-20 19:17 ` [PATCH 0/3] improve chainlint.pl CPU count computation John Paul Adrian Glaubitz
2024-05-20 19:19 ` Eric Sunshine
2024-05-20 19:23 ` John Paul Adrian Glaubitz
2024-05-21 14:28 ` John Paul Adrian Glaubitz
2024-05-21 16:18 ` Eric Sunshine
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=xmqqbk50jt1s.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=andreas@gaisler.com \
--cc=git@vger.kernel.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=sam@gentoo.org \
--cc=sunshine@sunshineco.com \
/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;
as well as URLs for NNTP newsgroup(s).