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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.