From: Andrew Morton <akpm@linux-foundation.org>
To: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Cc: tzanussi@gmail.com, penberg@cs.helsinki.fi,
torvalds@linux-foundation.org, compudj@krystal.dyndns.org,
vegard.nossum@gmail.com, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org
Subject: Re: [PATCH 3/3] relay: Add buffer-only channels; useful for early logging.
Date: Fri, 4 Jul 2008 23:32:05 -0700 [thread overview]
Message-ID: <20080704233205.5cf6f04b.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080705071401.0fe75d9f@linux360.ro>
On Sat, 5 Jul 2008 07:14:01 +0300 Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> wrote:
> On Wed, 2 Jul 2008 23:06:36 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > This breaks on sparc64.
> >
> > > + err = smp_call_function_single(i,
> > > +
> > > __relay_set_buf_dentry,
> > > + &disp, 0,
> > > 1);
> >
> > Because that ain't implemented.
> >
> > There's a call in net/iucv/iucv.c, but that's s390-only.
> >
> > There's a call in virt/kvm/kvm_main.c.
> >
> > There's a call in kernel/time/tick-broadcast.c, so I assume that the
> > intersection between CONFIG_GENERIC_CLOCKEVENTS_BROADCAST and
> > non-smp_call_function_single() architectures is presently empty.
>
> Hi,
>
> I'm not sure what I should do.
Nothing, I'd suggest. I think that all architectures should implement
smp_call_function_single(). You can have a shot at doing that if you
like, but the implementations will need to be reviewed and merged by
the relevant architectures maintainers. (That's why I snuck linux-arch
into the cc list last time).
> Maybe disable relay_late_setup_files()
> on sparc64, with an empty inline?
>
> > I guess all SMP-capable architectures should now implement this,
> > please. It is presently defined on all architectures for CONFIG_SMP=n
> > and it is declared in include/linux/smp.h.
>
> sparc64 seems to have smp_call_function_mask(). If we have the generic
> kernel/smp.c in linux-next or -mmotm, then this will define
> smp_call_function_single() to call smp_call_function_mask().
>
> Is there anything I can do regarding this patch? Does it work since
> kernel/smp.c reappeared?
Nope:
y:/usr/src/25> grep USE_GENERIC_SMP_HELPERS arch/*/Kconfig
arch/alpha/Kconfig: select USE_GENERIC_SMP_HELPERS
arch/arm/Kconfig: select USE_GENERIC_SMP_HELPERS
arch/ia64/Kconfig: select USE_GENERIC_SMP_HELPERS
arch/m32r/Kconfig: select USE_GENERIC_SMP_HELPERS
arch/mips/Kconfig: select USE_GENERIC_SMP_HELPERS
arch/parisc/Kconfig: select USE_GENERIC_SMP_HELPERS
arch/powerpc/Kconfig: select USE_GENERIC_SMP_HELPERS if SMP
arch/sh/Kconfig: select USE_GENERIC_SMP_HELPERS
arch/x86/Kconfig: select USE_GENERIC_SMP_HELPERS
It would help if you could check to see which architectures need work
and then perhaps propose patches. If not, well, 2.6.27-rc1 will be
broken on some architectures on some configs and people will have a
couple of months to unbreak it. Not a big problem, I expect.
next prev parent reply other threads:[~2008-07-05 6:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-23 12:31 [PATCH 3/3] relay: Add buffer-only channels; useful for early logging Eduard - Gabriel Munteanu
2008-07-03 6:06 ` Andrew Morton
2008-07-05 4:14 ` Eduard - Gabriel Munteanu
2008-07-05 6:32 ` Andrew Morton [this message]
2008-08-06 17:32 ` Mathieu Desnoyers
-- strict thread matches above, loose matches on Subject: below --
2008-06-21 14:11 Eduard - Gabriel Munteanu
2008-06-22 19:24 ` Pekka Enberg
2008-06-22 19:29 ` Pekka Enberg
2008-06-22 20:51 ` Eduard - Gabriel Munteanu
2008-06-15 15:05 Eduard - Gabriel Munteanu
2008-06-17 14:35 ` Mathieu Desnoyers
2008-06-13 1:10 Eduard - Gabriel Munteanu
2008-06-13 7:04 ` Pekka Enberg
2008-06-13 15:54 ` Eduard - Gabriel Munteanu
2008-06-16 12:30 ` Mathieu Desnoyers
2008-06-16 13:37 ` Eduard - Gabriel Munteanu
2008-06-17 13:53 ` Mathieu Desnoyers
2008-06-14 16:10 ` Eduard - Gabriel Munteanu
2008-06-16 12:35 ` Mathieu Desnoyers
2008-06-16 13:30 ` Eduard - Gabriel Munteanu
2008-06-12 20:26 Eduard - Gabriel Munteanu
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=20080704233205.5cf6f04b.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=compudj@krystal.dyndns.org \
--cc=eduard.munteanu@linux360.ro \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=torvalds@linux-foundation.org \
--cc=tzanussi@gmail.com \
--cc=vegard.nossum@gmail.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.