From: Chris Snook <csnook@redhat.com>
To: David Miller <davem@davemloft.net>
Cc: afleming@gmail.com, afleming@freescale.com, netdev@vger.kernel.org
Subject: Re: [PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS dependency
Date: Wed, 15 Oct 2008 12:48:56 -0400 [thread overview]
Message-ID: <48F61EF8.20202@redhat.com> (raw)
In-Reply-To: <20081014.221647.184282035.davem@davemloft.net>
David Miller wrote:
> From: Chris Snook <csnook@redhat.com>
> Date: Tue, 14 Oct 2008 20:07:55 -0400
>
>> But then it will be much more of a pain to exclude the vast swath of
>> irrelevant code in the kernel tree from your builds on these exotic
>> architectures. Have you ever built a kernel on s390?
>
> That's totally irrelevant.
>
> Does S390 have ethernet or ethernet-like devices? If so, the someday
> it might in fact might want to use something like phylib instead of
> adding yet another implementation of programming a particular PHY
> chip.
Last I checked, s390 doesn't have any hardware that can't be shared
between at least 64 guests. The most Linux will ever control on that
hardware is a software channel, be it a channel to a disk controller,
network controller, or application-specific offload engine. They don't
really have NICs, more like a built-in router which can optionally fake
layer 2 for the benefit of guests.
> So in fact, something like phylib should be possible to enable even on
> s390.
>
> And this current situation means s390 builds get less coverage, making
> allmodconfig test builds (which the s390 folks are obviously doing
> since they hit this originally reported build failure) less
> useful than they could be.
Currently, allmodconfig on s390 is cheap, because there's a miniscule
amount of device driver code that can be enabled in Kconfig. If you
enabled all those other drivers to build on s390, it would take *days*
to complete an allmodconfig build natively or in an emulator. Forcing
people to use cross-compilers to get things done at a reasonable pace
would mean treating s390 differently from other architectures in
multi-platform build systems, and would probably have the effect that
nobody outside of IBM would do any significant build testing on that
architecture.
> I would even be happy to make it such that SBUS drivers can be
> enabled for test building on x86, and in fact right now in
> Linus's tree that's very close to doable.
I have no objection to that. I have MIPS to burn on my x86 boxes. s390
MIPS cost a few orders of magnitude more.
-- Chris
prev parent reply other threads:[~2008-10-15 16:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-14 22:28 [PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS dependency Andy Fleming
2008-10-14 22:44 ` David Miller
2008-10-14 23:21 ` Andy Fleming
2008-10-14 23:33 ` David Miller
2008-10-14 23:43 ` Chris Snook
2008-10-14 23:52 ` David Miller
2008-10-15 0:07 ` Chris Snook
2008-10-15 5:16 ` David Miller
2008-10-15 16:48 ` Chris Snook [this message]
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=48F61EF8.20202@redhat.com \
--to=csnook@redhat.com \
--cc=afleming@freescale.com \
--cc=afleming@gmail.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/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.