sh updates for 2.6.35-rc1
in [Kernel]
|
Prev: [PATCH] x86,perf: P4 PMU -- fix misprint in unflagged nmi handling
Next: perf probe: Don't compile CFI related code if elfutils is old
From: Magnus Damm on 18 May 2010 07:20 Hi Jaswinder, On Tue, May 18, 2010 at 8:16 PM, Jaswinder Singh Rajput <jaswinderlinux(a)gmail.com> wrote: > I am looking at the future, where multiple architecture will use each > other files. > > I am just worried about the file count. Currently : > > $ ls include/linux/ | wc -l > 1029 > > If other architecture will also start adding the files in > include/linux like you did then ? > > So better make another directory in include. Perhaps we can deal with that whenever it becomes an issue. Thank you. / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jaswinder Singh Rajput on 18 May 2010 07:30 Hello magnus, On Tue, May 18, 2010 at 4:35 PM, Magnus Damm <magnus.damm(a)gmail.com> wrote: > Hi Jaswinder, > > On Tue, May 18, 2010 at 7:51 PM, Jaswinder Singh Rajput > <jaswinderlinux(a)gmail.com> wrote: >> Hmm, so still it is between ARM and SH, so better option will be : >> >> include/linux/sh_clk.h -> include/sh/clk.h >> include/linux/sh_dma.h -> include/sh/dma.h >> include/linux/sh_intc.h -> include/sh/intc.h >> >> So when arm files will come then, then we can make it like this : >> >> include/arm/clk.h >> include/arm/dma.h >> include/arm/intc.h >> >> So user will program like this : >> >> #include <arm/dma.h> >> #include <sh/dma.h> > > Right now the SH code does > > #include <linux/sh_intc.h> > > and the ARM code does > > #include <linux/sh_intc.h> > > Hope this clarifies! > I am looking at the future, where multiple architecture will use each other files. I am just worried about the file count. Currently : $ ls include/linux/ | wc -l 1029 If other architecture will also start adding the files in include/linux like you did then ? So better make another directory in include. Thanks, -- Jaswinder Singh. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul Mundt on 18 May 2010 18:10
On Tue, May 18, 2010 at 04:46:12PM +0530, Jaswinder Singh Rajput wrote: > I am looking at the future, where multiple architecture will use each > other files. > > I am just worried about the file count. Currently : > > $ ls include/linux/ | wc -l > 1029 > > If other architecture will also start adding the files in > include/linux like you did then ? > > So better make another directory in include. > I think you're still missing the point here, this "future" case you speak of has been commonplace for years already now, and it's certainly not going to change (we've had mixed architecture multi-cores under Linux for almost 10 years now, so your future case has been going on for some time now). All of this started out with the header for the serial block being moved over, which is now used by 3 in-tree architectures and a 4th architecture under development. Things like interrupt and clock controllers are not the first things that come to mind when people think of architecture independent drivers, but that's really what it has come down to at this point. The driver model and so on have helped a lot in this regard, and between that and the early platform extensions we implemented for the platform bus it's been possible to do things like move all of our clocksources/clockevents out in to the driver model and permit different architectures to tie in to them as necessary. There has been a lot of behind the scenes prep work that we've been doing to make as much of this stuff completely architecture independent as possible, so it's not like we've simply been lazily shuffling headers around based on some idea of what might possible pop up in the future. Each one of these headers has been explicitly placed for a reason and has (or will have in a subsequent merge) multiple architecture users. While we could try to encapsulate some of this in some sort of pseudo architecture abstraction, that really doesn't accomplish anything, and it also suggests an architectural relationship where there simply isn't one. Sure, most of these drivers and IP blocks began life inside an SH core, but given that we now use them across a wide range of architectures, this continued relationship simply doesn't make any sense. Having said that, I do realize that include/linux is rather cluttered with hardware-related stuff these days, and that at least is perhaps something that we may wish to change some day. Having some sort of hw/ abstraction for that stuff would make it easier to see what's hardware related and what isn't, but that's an entirely different discussion and one that needs a lot of thinking and consensus. asm/ certainly isn't the place for these things however, given that at the end of the day they really have nothing to do with any specific architecture. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |