3.9-rc1 regression in arm dtb build

3.9-rc1 regression in arm dtb build

[Pavel Machek]

Hi!

Commit

commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8
Author: Grant Likely <grant.likely@secretlab.ca>
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

3.9-rc1 regression in arm dtb build

[Thomas Petazzoni]

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

3.9-rc1 regression in arm dtb build

[Stephen Warren]

On 03/06/2013 12:33 PM, Pavel Machek wrote:
> Hi!
> 
> Commit
> 
> commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8
> Author: Grant Likely <grant.likely@secretlab.ca>
> 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
> 

3.9-rc1 regression in arm dtb build

[Pavel Machek]

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

3.9-rc1 regression in arm dtb build

[Pavel Machek]

Hi!
> > commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8
> > Author: Grant Likely <grant.likely@secretlab.ca>
> > 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 at 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 at pollux linux]$ cp arch/arm/boot/dts/socfpga_cyclone5.dtb
arch/arm/boot/socfpga_cyclone5.dtb 
[pavel at 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 at pollux linux]$ make clean
  CLEAN   .
  CLEAN   drivers/tty/vt
  CLEAN   kernel
  CLEAN   lib
  CLEAN   .tmp_versions
[pavel at 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 at 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

3.9-rc1 regression in arm dtb build

[Stephen Warren]

On 03/07/2013 07:45 AM, Pavel Machek wrote:
> Hi!
>>> commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8
>>> Author: Grant Likely <grant.likely@secretlab.ca>
>>> 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?

3.9-rc1 regression in arm dtb build

[Olof Johansson]

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 <grant.likely@secretlab.ca>
> >>> 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

3.9-rc1 regression in arm dtb build

[Pavel Machek]

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 <grant.likely@secretlab.ca>
> > >>> 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

3.9-rc1 regression in arm dtb build

[Grant Likely]

On Mon, Mar 11, 2013 at 1:05 PM, Olof Johansson <olof@lixom.net> 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 <grant.likely@secretlab.ca>
>> >>> 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.

3.9-rc1 regression in arm dtb build

[Pavel Machek]

On Mon 2013-03-11 19:00:47, Grant Likely wrote:
> On Mon, Mar 11, 2013 at 1:05 PM, Olof Johansson <olof@lixom.net> 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 <grant.likely@secretlab.ca>
> >> >>> 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

3.9-rc1 regression in arm dtb build

[Stephen Warren]

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?

3.9-rc1 regression in arm dtb build

[Pavel Machek]

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

3.9-rc1 regression in arm dtb build

[Olof Johansson]

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 <olof@lixom.net>

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

3.9-rc1 regression in arm dtb build

[Stephen Warren]

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?

3.9-rc1 regression in arm dtb build

[Pavel Machek]

> >> 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

3.9-rc1 regression in arm dtb build

[Olof Johansson]

On Fri, Mar 29, 2013 at 10:05 AM, Stephen Warren <swarren@wwwdotorg.org> 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

3.9-rc1 regression in arm dtb build

[Pavel Machek]

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