All of lore.kernel.org
 help / color / mirror / Atom feed
* On patch "Remove all #inclusions of asm/system.h"
@ 2012-03-29 13:34 Stefan Richter
  2012-03-31 19:31 ` David Howells
  0 siblings, 1 reply; 4+ messages in thread
From: Stefan Richter @ 2012-03-29 13:34 UTC (permalink / raw)
  To: David Howells; +Cc: linux-kernel

Hi David,

commit 9ffc93f2 "Remove all #inclusions of asm/system.h" removes a lot of
includes while its parent commit 96f951ed "Add #includes needed to permit
the removal of asm/system.h" adds only a few.  Some of the files modified
by commit 9ffc93f2 now only work due to indirect inclusion, don't they?

For example, drivers/firewire/{core-device,core-topology,ohci,sbp2}.c use
smp_rmb()¹ and used to include asm/system.h.  Now they do not include
asm/barrier.h.  Is this by mistake or on purpose?

(I only noticed the commit come in; I did not get any build error yet.
The mentioned files now get asm/barrier.h via linux/spinlock.h and
certainly via other ways as well.)

--------
¹) so does drivers/firewire/net.c but it missed to include asm/system.h
-- 
Stefan Richter
-=====-===-- --== ===-=
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: On patch "Remove all #inclusions of asm/system.h"
  2012-03-29 13:34 On patch "Remove all #inclusions of asm/system.h" Stefan Richter
@ 2012-03-31 19:31 ` David Howells
  2012-03-31 20:44   ` Stefan Richter
  2012-04-01  1:46   ` David Howells
  0 siblings, 2 replies; 4+ messages in thread
From: David Howells @ 2012-03-31 19:31 UTC (permalink / raw)
  To: Stefan Richter; +Cc: dhowells, linux-kernel

Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> commit 9ffc93f2 "Remove all #inclusions of asm/system.h" removes a lot of
> includes while its parent commit 96f951ed "Add #includes needed to permit
> the removal of asm/system.h" adds only a few.  Some of the files modified
> by commit 9ffc93f2 now only work due to indirect inclusion, don't they?
> 
> For example, drivers/firewire/{core-device,core-topology,ohci,sbp2}.c use
> smp_rmb()¹ and used to include asm/system.h.  Now they do not include
> asm/barrier.h.  Is this by mistake or on purpose?

I tried to make sure allyesconfig worked for x86_64 and a bunch of defconfigs
worked.  I can't guarantee that that got 100% coverage.  I also knew there
would be some breakage from the base Linux kernel having moved on by the time
Linus pulled myu patches - though I don't know if this is the case here (I
suspect not).

David

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: On patch "Remove all #inclusions of asm/system.h"
  2012-03-31 19:31 ` David Howells
@ 2012-03-31 20:44   ` Stefan Richter
  2012-04-01  1:46   ` David Howells
  1 sibling, 0 replies; 4+ messages in thread
From: Stefan Richter @ 2012-03-31 20:44 UTC (permalink / raw)
  To: David Howells; +Cc: linux-kernel

On Mar 31 David Howells wrote:
> Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> > For example, drivers/firewire/{core-device,core-topology,ohci,sbp2}.c use
> > smp_rmb()¹ and used to include asm/system.h.  Now they do not include
> > asm/barrier.h.  Is this by mistake or on purpose?
> 
> I tried to make sure allyesconfig worked for x86_64 and a bunch of defconfigs
> worked.  I can't guarantee that that got 100% coverage.  I also knew there
> would be some breakage from the base Linux kernel having moved on by the time
> Linus pulled myu patches - though I don't know if this is the case here (I
> suspect not).

It's not a problem; they now get barrier.h via spinlock.h.  I just
wondered whether absence of #include <asm/barrier.h> in those files had a
deeper non-obvious meaning.  Since it doesn't I will just put that include
in them next time around when I do some housekeeping there.
-- 
Stefan Richter
-=====-===-- --== =====
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: On patch "Remove all #inclusions of asm/system.h"
  2012-03-31 19:31 ` David Howells
  2012-03-31 20:44   ` Stefan Richter
@ 2012-04-01  1:46   ` David Howells
  1 sibling, 0 replies; 4+ messages in thread
From: David Howells @ 2012-04-01  1:46 UTC (permalink / raw)
  To: Stefan Richter; +Cc: dhowells, linux-kernel

Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> It's not a problem; they now get barrier.h via spinlock.h.  I just
> wondered whether absence of #include <asm/barrier.h> in those files had a
> deeper non-obvious meaning.  Since it doesn't I will just put that include
> in them next time around when I do some housekeeping there.

I suspect they should #include asm/barrier.h directly rather than relying on
spinlock.h.  There's no guarantee that on every arch spinlock.h will pull in
asm/barrier.h, I think...

David

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-04-01  1:46 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-29 13:34 On patch "Remove all #inclusions of asm/system.h" Stefan Richter
2012-03-31 19:31 ` David Howells
2012-03-31 20:44   ` Stefan Richter
2012-04-01  1:46   ` David Howells

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.