From: Ben Dooks <ben-linux@fluff.org>
To: linux-arm-kernel@lists.infradead.org,
Linux Samsung SoC <linux-samsung-soc@vger.kernel.org>
Subject: Default machine include placements
Date: Mon, 25 Jan 2010 04:02:56 +0000 [thread overview]
Message-ID: <20100125040255.GN26562@trinity.fluff.org> (raw)
Currently in the s3c/s5p familt we're seeing quite a number of the
same things being repeated for items like entry-macro.S, hardware.h
and so on.
The first question is about adding include/mach directories to
eitehr plat-s5p or plat-samsung to mop up the files that keep
getting repeated (since the plat-* directories are processed after
the machine directory includes the mach-xxx are still free to overide
these as necessary)
The second question is whether some of these files should have defaults
in arch/arm/include? I think this might be less useful as build failures
for new ports ensure that at-least these files are thought about
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
WARNING: multiple messages have this Message-ID (diff)
From: ben-linux@fluff.org (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: Default machine include placements
Date: Mon, 25 Jan 2010 04:02:56 +0000 [thread overview]
Message-ID: <20100125040255.GN26562@trinity.fluff.org> (raw)
Currently in the s3c/s5p familt we're seeing quite a number of the
same things being repeated for items like entry-macro.S, hardware.h
and so on.
The first question is about adding include/mach directories to
eitehr plat-s5p or plat-samsung to mop up the files that keep
getting repeated (since the plat-* directories are processed after
the machine directory includes the mach-xxx are still free to overide
these as necessary)
The second question is whether some of these files should have defaults
in arch/arm/include? I think this might be less useful as build failures
for new ports ensure that at-least these files are thought about
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
next reply other threads:[~2010-01-25 4:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-25 4:02 Ben Dooks [this message]
2010-01-25 4:02 ` Default machine include placements Ben Dooks
2010-01-25 10:05 ` Russell King - ARM Linux
2010-01-25 10:05 ` Russell King - ARM Linux
2010-01-25 10:28 ` Ben Dooks
2010-01-25 10:28 ` Ben Dooks
2010-01-25 10:32 ` Daniel Silverstone
2010-01-25 10:44 ` Ben Dooks
2010-01-25 10:49 ` Daniel Silverstone
2010-01-25 10:55 ` Ben Dooks
2010-01-25 11:19 ` Russell King - ARM Linux
2010-01-25 11:53 ` Ben Dooks
2010-01-25 12:04 ` Russell King - ARM Linux
2010-01-25 13:54 ` Ben Dooks
2010-01-25 14:59 ` Russell King - ARM Linux
2010-01-25 21:48 ` Ben Dooks
2010-01-25 14:03 ` Ben Dooks
2010-01-25 10:57 ` Mark Brown
2010-01-25 10:49 ` Ben Dooks
2010-01-25 10:49 ` Ben Dooks
2010-01-25 11:01 ` Russell King - ARM Linux
2010-01-25 11:01 ` Russell King - ARM Linux
2010-01-25 11:44 ` Ben Dooks
2010-01-25 11:44 ` Ben Dooks
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=20100125040255.GN26562@trinity.fluff.org \
--to=ben-linux@fluff.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-samsung-soc@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.