All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.