Hi!
Commit
commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8
Author: Grant Likely <[email protected]>
Date: Tue Nov 27 16:29:11 2012 -0700
The current rules have the .dtb files build in a different
directory
from the .dts files. The only reason for this is that it was what
PowerPC has done historically. This patch changes ARM to use the
generic dtb rule which builds .dtb files in the same directory as the
source .dts.
--
Moves dtb files from arch/arm/boot/ to arch/arm/boot/dtb. That causes
several problems:
1) it is inconsistent with 3.8, making switching between 3.9-rc1 and
3.8 tricky
2) what is worse, it is very easy to do stuff like
make socfpga_cyclone5.dtb
and you end up with success, but stale file in arch/arm/boot, where
your scripts expect it.
(There are some attempts to rm stale files in Makefiles; they don't
work in above case).
3) it is now incosistent between powerpc and arm.
4) device tree _binary_ files are now output in device tree _source_
directory
(Sorry for noticing this earlier).
I believe the commit should be simply reverted. Reasons to move dtbs
around are not good enough.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Dear Pavel Machek,
On Wed, 6 Mar 2013 20:33:32 +0100, Pavel Machek wrote:
> Moves dtb files from arch/arm/boot/ to arch/arm/boot/dtb. That causes
> several problems:
>
> 1) it is inconsistent with 3.8, making switching between 3.9-rc1 and
> 3.8 tricky
The commit you're pointing to was part of 3.8, and so the dtb move to
arch/arm/boot/dts/ is already here since quite a bit of time. At least,
it's not something you introduced in 3.9-rc1.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On 03/06/2013 12:33 PM, Pavel Machek wrote:
> Hi!
>
> Commit
>
> commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8
> Author: Grant Likely <[email protected]>
> Date: Tue Nov 27 16:29:11 2012 -0700
>
> The current rules have the .dtb files build in a different
> directory
> from the .dts files. The only reason for this is that it was what
> PowerPC has done historically. This patch changes ARM to use the
> generic dtb rule which builds .dtb files in the same directory as the
> source .dts.
>
> --
>
> Moves dtb files from arch/arm/boot/ to arch/arm/boot/dtb. That causes
> several problems:
>
> 1) it is inconsistent with 3.8, making switching between 3.9-rc1 and
> 3.8 tricky
It's pretty easy to locate the DTB by automatically looking in
arch/*/boot/dts first, then if the file doesn't exist there, looking in
arch/*/boot instead as a legacy fallback.
> 2) what is worse, it is very easy to do stuff like
>
> make socfpga_cyclone5.dtb
>
> and you end up with success, but stale file in arch/arm/boot, where
> your scripts expect it.
>
> (There are some attempts to rm stale files in Makefiles; they don't
> work in above case).
I guess moving the rm into cmd_dtc rather than the "dtbs" rule would
solve that.
> 3) it is now incosistent between powerpc and arm.
True. PPC's DTB-handling is a little more complex than most, so wasn't
converted along with this patch. It'd be nice to finish the conversion
and make PPC pick up this change too.
> 4) device tree _binary_ files are now output in device tree _source_
> directory
Isn't that true for almost all object files? One of the motivators for
the move was that binaries were being built in a different directory to
the source, which is quite odd.
> (Sorry for noticing this earlier).
>
> I believe the commit should be simply reverted. Reasons to move dtbs
> around are not good enough.
> Pavel
>
On Wed 2013-03-06 20:45:57, Thomas Petazzoni wrote:
> Dear Pavel Machek,
>
> On Wed, 6 Mar 2013 20:33:32 +0100, Pavel Machek wrote:
>
> > Moves dtb files from arch/arm/boot/ to arch/arm/boot/dtb. That causes
> > several problems:
> >
> > 1) it is inconsistent with 3.8, making switching between 3.9-rc1 and
> > 3.8 tricky
>
> The commit you're pointing to was part of 3.8, and so the dtb move to
> arch/arm/boot/dts/ is already here since quite a bit of time. At least,
> it's not something you introduced in 3.9-rc1.
Aha, so I guess it changed between 3.7 and 3.8... Anyway, perhaps it
is best to revert it now and treat it as a bug than having everyone
learn that 3.7- has it one way and 3.8+ different?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> > commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8
> > Author: Grant Likely <[email protected]>
> > Date: Tue Nov 27 16:29:11 2012 -0700
...
> > 1) it is inconsistent with 3.8, making switching between 3.9-rc1 and
> > 3.8 tricky
>
> It's pretty easy to locate the DTB by automatically looking in
> arch/*/boot/dts first, then if the file doesn't exist there, looking in
> arch/*/boot instead as a legacy fallback.
Unfortunately, that does not work. See 2) below. Stale files even
survive "make clean".
3.9-rc1:
[pavel@pollux linux]$ ls -al arch/arm/boot/dts/socfpga_cyclone5.dtb
-rw-rw-r-- 1 pavel pavel 3335 Mar 6 14:55
arch/arm/boot/dts/socfpga_cyclone5.dtb
[pavel@pollux linux]$ cp arch/arm/boot/dts/socfpga_cyclone5.dtb
arch/arm/boot/socfpga_cyclone5.dtb
[pavel@pollux linux]$ ls -al arch/arm/boot/socfpga_cyclone5.dtb
-rw-rw-r-- 1 pavel pavel 3335 Mar 7 15:41
arch/arm/boot/socfpga_cyclone5.dtb
[pavel@pollux linux]$ make clean
CLEAN .
CLEAN drivers/tty/vt
CLEAN kernel
CLEAN lib
CLEAN .tmp_versions
[pavel@pollux linux]$ ls -al arch/arm/boot/socfpga_cyclone5.dtb
-rw-rw-r-- 1 pavel pavel 3335 Mar 7 15:41
arch/arm/boot/socfpga_cyclone5.dtb
[pavel@pollux linux]$ make socfpga_cyclone5.dtb
> > 2) what is worse, it is very easy to do stuff like
> >
> > make socfpga_cyclone5.dtb
> >
> > and you end up with success, but stale file in arch/arm/boot, where
> > your scripts expect it.
> >
> > (There are some attempts to rm stale files in Makefiles; they don't
> > work in above case).
>
> I guess moving the rm into cmd_dtc rather than the "dtbs" rule would
> solve that.
Yep, I guess something like that should be done.
> > 3) it is now incosistent between powerpc and arm.
>
> True. PPC's DTB-handling is a little more complex than most, so wasn't
> converted along with this patch. It'd be nice to finish the conversion
> and make PPC pick up this change too.
Why break people's build scripts? What is the advantage? Having
binaries in same directory... ok but not worth the breakage.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 03/07/2013 07:45 AM, Pavel Machek wrote:
> Hi!
>>> commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8
>>> Author: Grant Likely <[email protected]>
>>> Date: Tue Nov 27 16:29:11 2012 -0700
> ...
>>> 1) it is inconsistent with 3.8, making switching between 3.9-rc1 and
>>> 3.8 tricky
>>
>> It's pretty easy to locate the DTB by automatically looking in
>> arch/*/boot/dts first, then if the file doesn't exist there, looking in
>> arch/*/boot instead as a legacy fallback.
>
> Unfortunately, that does not work. See 2) below. Stale files even
> survive "make clean".
Oh right. I guess it works fine when having built 3.7 and then building
3.8, since you'd look in the new location first and only fall back to
the old location if missing. However, if you then switch back to 3.7 to
test something, I guess that doesn't work so well.
I tend to always build the dtbs target, so I wasn't affected by this.
And, often run "git clean -f -d -x" too.
Grant, what's your call on this issue; should I/you look into ways to
clean the files better, or do you want to revert this?
On Thu, Mar 07, 2013 at 01:50:54PM -0700, Stephen Warren wrote:
> On 03/07/2013 07:45 AM, Pavel Machek wrote:
> > Hi!
> >>> commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8
> >>> Author: Grant Likely <[email protected]>
> >>> Date: Tue Nov 27 16:29:11 2012 -0700
> > ...
> >>> 1) it is inconsistent with 3.8, making switching between 3.9-rc1 and
> >>> 3.8 tricky
> >>
> >> It's pretty easy to locate the DTB by automatically looking in
> >> arch/*/boot/dts first, then if the file doesn't exist there, looking in
> >> arch/*/boot instead as a legacy fallback.
> >
> > Unfortunately, that does not work. See 2) below. Stale files even
> > survive "make clean".
>
> Oh right. I guess it works fine when having built 3.7 and then building
> 3.8, since you'd look in the new location first and only fall back to
> the old location if missing. However, if you then switch back to 3.7 to
> test something, I guess that doesn't work so well.
>
> I tend to always build the dtbs target, so I wasn't affected by this.
> And, often run "git clean -f -d -x" too.
>
> Grant, what's your call on this issue; should I/you look into ways to
> clean the files better, or do you want to revert this?
I'm not Grant, but I think we're better off cleaning up the current situation
instead of reverting. Otherwise 3.8 will be the oddball weird release; it's
better to get people moved over to the new location.
-Olof
On Sun 2013-03-10 22:05:46, Olof Johansson wrote:
> On Thu, Mar 07, 2013 at 01:50:54PM -0700, Stephen Warren wrote:
> > On 03/07/2013 07:45 AM, Pavel Machek wrote:
> > > Hi!
> > >>> commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8
> > >>> Author: Grant Likely <[email protected]>
> > >>> Date: Tue Nov 27 16:29:11 2012 -0700
> > > ...
> > >>> 1) it is inconsistent with 3.8, making switching between 3.9-rc1 and
> > >>> 3.8 tricky
> > >>
> > >> It's pretty easy to locate the DTB by automatically looking in
> > >> arch/*/boot/dts first, then if the file doesn't exist there, looking in
> > >> arch/*/boot instead as a legacy fallback.
> > >
> > > Unfortunately, that does not work. See 2) below. Stale files even
> > > survive "make clean".
> >
> > Oh right. I guess it works fine when having built 3.7 and then building
> > 3.8, since you'd look in the new location first and only fall back to
> > the old location if missing. However, if you then switch back to 3.7 to
> > test something, I guess that doesn't work so well.
> >
> > I tend to always build the dtbs target, so I wasn't affected by this.
> > And, often run "git clean -f -d -x" too.
> >
> > Grant, what's your call on this issue; should I/you look into ways to
> > clean the files better, or do you want to revert this?
>
> I'm not Grant, but I think we're better off cleaning up the current situation
> instead of reverting. Otherwise 3.8 will be the oddball weird release; it's
> better to get people moved over to the new location.
Well... it seems that noone is willing to fix the patch, that new
location has no advantages, and that it is incompatible with
powerpc. Maybe oddball release is less evil here, and we can still fix
it up in -stable...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, Mar 11, 2013 at 1:05 PM, Olof Johansson <[email protected]> wrote:
> On Thu, Mar 07, 2013 at 01:50:54PM -0700, Stephen Warren wrote:
>> On 03/07/2013 07:45 AM, Pavel Machek wrote:
>> > Hi!
>> >>> commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8
>> >>> Author: Grant Likely <[email protected]>
>> >>> Date: Tue Nov 27 16:29:11 2012 -0700
>> > ...
>> >>> 1) it is inconsistent with 3.8, making switching between 3.9-rc1 and
>> >>> 3.8 tricky
>> >>
>> >> It's pretty easy to locate the DTB by automatically looking in
>> >> arch/*/boot/dts first, then if the file doesn't exist there, looking in
>> >> arch/*/boot instead as a legacy fallback.
>> >
>> > Unfortunately, that does not work. See 2) below. Stale files even
>> > survive "make clean".
>>
>> Oh right. I guess it works fine when having built 3.7 and then building
>> 3.8, since you'd look in the new location first and only fall back to
>> the old location if missing. However, if you then switch back to 3.7 to
>> test something, I guess that doesn't work so well.
>>
>> I tend to always build the dtbs target, so I wasn't affected by this.
>> And, often run "git clean -f -d -x" too.
>>
>> Grant, what's your call on this issue; should I/you look into ways to
>> clean the files better, or do you want to revert this?
>
> I'm not Grant, but I think we're better off cleaning up the current situation
> instead of reverting. Otherwise 3.8 will be the oddball weird release; it's
> better to get people moved over to the new location.
Don't revert. It needs to be fixed up. Pavel, if you're really choked
up about this we can symlink the files from the old location to the
new. I personally don't think it is that onerous a change though since
the files are easy to find and build systems can adapt.
g.
On Mon 2013-03-11 19:00:47, Grant Likely wrote:
> On Mon, Mar 11, 2013 at 1:05 PM, Olof Johansson <[email protected]> wrote:
> > On Thu, Mar 07, 2013 at 01:50:54PM -0700, Stephen Warren wrote:
> >> On 03/07/2013 07:45 AM, Pavel Machek wrote:
> >> > Hi!
> >> >>> commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8
> >> >>> Author: Grant Likely <[email protected]>
> >> >>> Date: Tue Nov 27 16:29:11 2012 -0700
> >> > ...
> >> >>> 1) it is inconsistent with 3.8, making switching between 3.9-rc1 and
> >> >>> 3.8 tricky
> >> >>
> >> >> It's pretty easy to locate the DTB by automatically looking in
> >> >> arch/*/boot/dts first, then if the file doesn't exist there, looking in
> >> >> arch/*/boot instead as a legacy fallback.
> >> >
> >> > Unfortunately, that does not work. See 2) below. Stale files even
> >> > survive "make clean".
> >>
> >> Oh right. I guess it works fine when having built 3.7 and then building
> >> 3.8, since you'd look in the new location first and only fall back to
> >> the old location if missing. However, if you then switch back to 3.7 to
> >> test something, I guess that doesn't work so well.
> >>
> >> I tend to always build the dtbs target, so I wasn't affected by this.
> >> And, often run "git clean -f -d -x" too.
> >>
> >> Grant, what's your call on this issue; should I/you look into ways to
> >> clean the files better, or do you want to revert this?
> >
> > I'm not Grant, but I think we're better off cleaning up the current situation
> > instead of reverting. Otherwise 3.8 will be the oddball weird release; it's
> > better to get people moved over to the new location.
>
> Don't revert. It needs to be fixed up. Pavel, if you're really choked
> up about this we can symlink the files from the old location to the
> new. I personally don't think it is that onerous a change though since
> the files are easy to find and build systems can adapt.
So... lets see.
There's change that makes it pretty much impossible to build dtbs
reliably between different kernel versions, because it leaves old dtbs
around, and they survive even make clean.
You don't want it reverted, yet noone fixes it.
What are supposed advantages of new location? (Besides disadvantages I
listed before)? Can we just revert the patch?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 03/28/2013 03:29 AM, Pavel Machek wrote:
...
> There's change that makes it pretty much impossible to build dtbs
> reliably between different kernel versions, because it leaves old dtbs
> around, and they survive even make clean.
One question here: Presumably the dtbs don't survive "make clean" if you
run that right after building the dtbs, but only if you check out a new
kernel version before running clean? Or is that not the case?
On Thu 2013-03-28 08:49:20, Stephen Warren wrote:
> On 03/28/2013 03:29 AM, Pavel Machek wrote:
> ...
> > There's change that makes it pretty much impossible to build dtbs
> > reliably between different kernel versions, because it leaves old dtbs
> > around, and they survive even make clean.
>
> One question here: Presumably the dtbs don't survive "make clean" if you
> run that right after building the dtbs, but only if you check out a new
> kernel version before running clean? Or is that not the case?
That was the case I seen, yes.
Have old kernel running, dtbs building. Apply a patch. It starts
behaving weird. You do make clean... but you still get old dtbs.
(It would be nice if make socfpga_cyclone5.dtb would magically remove
all the dtbs from old location; make dtbs does that if I understand
stuff correctly).
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thu, Mar 28, 2013 at 08:33:23PM +0100, Pavel Machek wrote:
> On Thu 2013-03-28 08:49:20, Stephen Warren wrote:
> > On 03/28/2013 03:29 AM, Pavel Machek wrote:
> > ...
> > > There's change that makes it pretty much impossible to build dtbs
> > > reliably between different kernel versions, because it leaves old dtbs
> > > around, and they survive even make clean.
> >
> > One question here: Presumably the dtbs don't survive "make clean" if you
> > run that right after building the dtbs, but only if you check out a new
> > kernel version before running clean? Or is that not the case?
>
> That was the case I seen, yes.
>
> Have old kernel running, dtbs building. Apply a patch. It starts
> behaving weird. You do make clean... but you still get old dtbs.
>
> (It would be nice if make socfpga_cyclone5.dtb would magically remove
> all the dtbs from old location; make dtbs does that if I understand
> stuff correctly).
This takes care of the "make dtbs" case (or just "make" case), but not
when you build a specific target.
ARM: dts: remove stale dtb files from arch/arm/boot
This will result in stale dtb files being removed from arch/arm/boot, which
can cause confusion when someone goes from an older kernel version to a newer
one without doing make clean on the old version (or git clean -f -d -x).
Signed-off-by: Olof Johansson <[email protected]>
index 84aa2ca..b1127b8 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -115,4 +115,5 @@ i:
$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
$(obj)/Image System.map "$(INSTALL_PATH)"
+clean-files := *.dtb
subdir- := bootp compressed dts
On 03/28/2013 01:54 PM, Olof Johansson wrote:
> On Thu, Mar 28, 2013 at 08:33:23PM +0100, Pavel Machek wrote:
>> On Thu 2013-03-28 08:49:20, Stephen Warren wrote:
>>> On 03/28/2013 03:29 AM, Pavel Machek wrote:
>>> ...
>>>> There's change that makes it pretty much impossible to build dtbs
>>>> reliably between different kernel versions, because it leaves old dtbs
>>>> around, and they survive even make clean.
>>>
>>> One question here: Presumably the dtbs don't survive "make clean" if you
>>> run that right after building the dtbs, but only if you check out a new
>>> kernel version before running clean? Or is that not the case?
>>
>> That was the case I seen, yes.
>>
>> Have old kernel running, dtbs building. Apply a patch. It starts
>> behaving weird. You do make clean... but you still get old dtbs.
>>
>> (It would be nice if make socfpga_cyclone5.dtb would magically remove
>> all the dtbs from old location; make dtbs does that if I understand
>> stuff correctly).
>
>
> This takes care of the "make dtbs" case (or just "make" case), but not
> when you build a specific target.
I guess to really solve this, we need the following changes:
In the all kernels:
For both arch/*/boot and arch/*/boot/dts: clean removes *.dtb
In kernels that build *.dtb in the new location:
make dtbs and make foo.dtb both rm ../*.dtb
In kernels that build *.dtb in the old location:
make dtbs and make foo.dtb both rm dts/*.dtb
Is that too much to retrofit into all the stable kernels?
> >> Have old kernel running, dtbs building. Apply a patch. It starts
> >> behaving weird. You do make clean... but you still get old dtbs.
> >>
> >> (It would be nice if make socfpga_cyclone5.dtb would magically remove
> >> all the dtbs from old location; make dtbs does that if I understand
> >> stuff correctly).
> >
> >
> > This takes care of the "make dtbs" case (or just "make" case), but not
> > when you build a specific target.
>
> I guess to really solve this, we need the following changes:
>
> In the all kernels:
>
> For both arch/*/boot and arch/*/boot/dts: clean removes *.dtb
...
> make dtbs and make foo.dtb both rm dts/*.dtb
>
> Is that too much to retrofit into all the stable kernels?
Well... since we need stable, anyway... what about:
Revert to good old location, fix 3.8 via stable tree, add "clean
removes *.dtb" to new kernels, so that people are not confused?
Yes, that means we keep old location, but arguably dtbs belong there,
and it is compatible with powerpc.... and we will not have to do so
much stable updates.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Fri, Mar 29, 2013 at 10:05 AM, Stephen Warren <[email protected]> wrote:
> On 03/28/2013 01:54 PM, Olof Johansson wrote:
>> On Thu, Mar 28, 2013 at 08:33:23PM +0100, Pavel Machek wrote:
>>> On Thu 2013-03-28 08:49:20, Stephen Warren wrote:
>>>> On 03/28/2013 03:29 AM, Pavel Machek wrote:
>>>> ...
>>>>> There's change that makes it pretty much impossible to build dtbs
>>>>> reliably between different kernel versions, because it leaves old dtbs
>>>>> around, and they survive even make clean.
>>>>
>>>> One question here: Presumably the dtbs don't survive "make clean" if you
>>>> run that right after building the dtbs, but only if you check out a new
>>>> kernel version before running clean? Or is that not the case?
>>>
>>> That was the case I seen, yes.
>>>
>>> Have old kernel running, dtbs building. Apply a patch. It starts
>>> behaving weird. You do make clean... but you still get old dtbs.
>>>
>>> (It would be nice if make socfpga_cyclone5.dtb would magically remove
>>> all the dtbs from old location; make dtbs does that if I understand
>>> stuff correctly).
>>
>>
>> This takes care of the "make dtbs" case (or just "make" case), but not
>> when you build a specific target.
>
> I guess to really solve this, we need the following changes:
>
> In the all kernels:
>
> For both arch/*/boot and arch/*/boot/dts: clean removes *.dtb
>
> In kernels that build *.dtb in the new location:
>
> make dtbs and make foo.dtb both rm ../*.dtb
I don't think this is useful. If you're building a specific dtb
target, there should be no expectation that other dtb files should
automatically be removed.
The original complaint was that make clean didn't remove the old dtb
files. That's been resolved with the provided patch.
I don't think it's worth the hassle of trying to remove ../foo.dtb.
> In kernels that build *.dtb in the old location:
>
> make dtbs and make foo.dtb both rm dts/*.dtb
>
> Is that too much to retrofit into all the stable kernels?
I also don't think this is worth the effort. If you're going to check
out old and new kernels in the same tree, you should probably get into
the habit of using git clean.
Perhaps we need a "dtb_install" target instead, so people stop copying
from the source directories.
-Olof
Hi!
> >> This takes care of the "make dtbs" case (or just "make" case), but not
> >> when you build a specific target.
> >
> > I guess to really solve this, we need the following changes:
> >
> > In the all kernels:
> >
> > For both arch/*/boot and arch/*/boot/dts: clean removes *.dtb
> >
> > In kernels that build *.dtb in the new location:
> >
> > make dtbs and make foo.dtb both rm ../*.dtb
>
> I don't think this is useful. If you're building a specific dtb
> target, there should be no expectation that other dtb files should
> automatically be removed.
So... how do the scripts find that script location changed?
You do make foo.dtb.
There's nice foo.dtb waiting in arch/arm/boot/, only that it is
outdated. You use it, and it does not work.
> The original complaint was that make clean didn't remove the old dtb
> files. That's been resolved with the provided patch.
No, original complaint was that it is very very easy to use stale
files. "make clean" not removing them is just a part of problem.
> > In kernels that build *.dtb in the old location:
> >
> > make dtbs and make foo.dtb both rm dts/*.dtb
> >
> > Is that too much to retrofit into all the stable kernels?
>
> I also don't think this is worth the effort. If you're going to check
> out old and new kernels in the same tree, you should probably get into
> the habit of using git clean.
Since when? make is expected to handle build dependencies. If you are
doing git bisect, make clean is going to slow you down, escpecially at
the end of cycle.
> Perhaps we need a "dtb_install" target instead, so people stop copying
> from the source directories.
dtb_install would be nice. But it will not help with current
problem...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html