Re: Allow aic7xx firmware to be built from BK tree.

Re: Allow aic7xx firmware to be built from BK tree.

[Pete Zaitcev]

> This patch removes the two generate files (that are also in the
> distributed kernel) before attempting to regenerate them.

It may be a cleaner solution to fix the assembler so that
it writes into a temporary file then renames it into the
file given by -o. This should avoid the BK problem with
444 permissions.

-- Pete

Allow aic7xx firmware to be built from BK tree.

[Peter Chubb]

This patch removes the two generate files (that are also in the
distributed kernel) before attempting to regenerate them.

The real question is, why are there generated files distributed with
the kernel source?

(Patch against 2.5.16)


===== drivers/scsi/aic7xxx/Makefile 1.8 vs edited =====
--- 1.8/drivers/scsi/aic7xxx/Makefile   Thu Apr 25 05:16:44 2002
+++ edited/drivers/scsi/aic7xxx/Makefile        Tue May 14 10:04:50 2002
@@ -26,6 +26,7 @@
 
 ifeq ($(CONFIG_AIC7XXX_BUILD_FIRMWARE),y)
 aic7xxx_seq.h aic7xxx_reg.h: aic7xxx.seq aic7xxx.reg aicasm/aicasm
+       -rm -f aic7xx_seq.h aic7xx_reg.h
        aicasm/aicasm -I. -r aic7xxx_reg.h -o aic7xxx_seq.h aic7xxx.seq
 endif
 

Re: Allow aic7xx firmware to be built from BK tree.

[Justin T. Gibbs]

>
>This patch removes the two generate files (that are also in the
>distributed kernel) before attempting to regenerate them.

Why is this necessary?

>The real question is, why are there generated files distributed with
>the kernel source?

Because, as I found out when I first contributed this driver,
not everyone has the tools necessary to build the assembler required
to generate these files.

--
Justin

Re: Allow aic7xx firmware to be built from BK tree.

[Kai Germaschewski]

On Mon, 20 May 2002, Justin T. Gibbs wrote:

> >This patch removes the two generate files (that are also in the
> >distributed kernel) before attempting to regenerate them.
> 
> Why is this necessary?

Well, I'll take Keith Owen's role and answer:

Some people are using source control management systems which
leave the managed files read-only.

If you rm the file first and then overwrite it with the generated file, it
will at least work, as opposed to trying to overwrite the read-only file.

It's still no good, because the SCM will notice that the file changed and
ask you to check in the new version, which you most likely don't want.

Some developers use bitkeeper these days, and it'll show exactly this
problem. I suppose the only reason that not more people complain about it
is that hardly anyone has set CONFIG_AIC7XXX_BUILD_FIRMWARE=y.

The correct way to fix this is to not overwrite the shipped files. The
appended patch is a suggestion on how to avoid the mentioned problems.

(I should pay credit to Keith Owens, since he proposed a similar solution
before)

Justin, do you have objections against this patch?

--Kai


-----------------------------------------------------------------------------
ChangeSet@1.581, 2002-05-20 23:33:06-05:00, kai@tp1.ruhr-uni-bochum.de
  kbuild: aic7xxx firmware build should not overwrite shipped files
  
  o Add dependencies on generated files explicitly to the
    aic7xxx Makefile - These cannot be figured out
    automatically
  
  o Rename the precompiled firmware files to 
    shipped_aic7xxx_{reg,seq}.h, so that we don't overwrite 
    shipped files when regenerating the firmware
   

 ----------------------------------------------------------------------------
 b/Makefile                                   |    2 
 b/drivers/scsi/aic7xxx/Makefile              |   13 
 b/drivers/scsi/aic7xxx/shipped_aic7xxx_reg.h |  716 ++++++++++++++
 b/drivers/scsi/aic7xxx/shipped_aic7xxx_seq.h | 1299 +++++++++++++++++++++++++++
 drivers/scsi/aic7xxx/aic7xxx_reg.h           |  716 --------------
 drivers/scsi/aic7xxx/aic7xxx_seq.h           | 1299 ---------------------------
 6 files changed, 2030 insertions(+), 2015 deletions(-)





=============================================================================
unified diffs follow for reference
=============================================================================


diff -Nru a/Makefile b/Makefile
--- a/Makefile	Mon May 20 23:36:18 2002
+++ b/Makefile	Mon May 20 23:36:18 2002
@@ -330,6 +330,8 @@
 	drivers/zorro/devlist.h drivers/zorro/gen-devlist \
 	sound/oss/bin2hex sound/oss/hex2hex \
 	drivers/atm/fore200e_mkfirm drivers/atm/{pca,sba}*{.bin,.bin1,.bin2} \
+	drivers/scsi/aic7xxx/aic7xxx_seq.h \
+	drivers/scsi/aic7xxx/aic7xxx_reg.h \
 	drivers/scsi/aic7xxx/aicasm/aicasm_gram.c \
 	drivers/scsi/aic7xxx/aicasm/aicasm_scan.c \
 	drivers/scsi/aic7xxx/aicasm/y.tab.h \
diff -Nru a/drivers/scsi/aic7xxx/Makefile b/drivers/scsi/aic7xxx/Makefile
--- a/drivers/scsi/aic7xxx/Makefile	Mon May 20 23:36:18 2002
+++ b/drivers/scsi/aic7xxx/Makefile	Mon May 20 23:36:18 2002
@@ -24,9 +24,22 @@
 
 include $(TOPDIR)/Rules.make
 
+# Dependencies for generated files need to be listed explicitly
+
+aic7xxx_core.o: aic7xxx_seq.h
+
+$(aic7xxx-objs): aic7xxx_reg.h
+
 ifeq ($(CONFIG_AIC7XXX_BUILD_FIRMWARE),y)
+
 aic7xxx_seq.h aic7xxx_reg.h: aic7xxx.seq aic7xxx.reg aicasm/aicasm
 	aicasm/aicasm -I. -r aic7xxx_reg.h -o aic7xxx_seq.h aic7xxx.seq
+
+else
+
+aic7xxx_seq.h aic7xxx_reg.h: %.h : shipped_%.h
+	ln -s $< $@
+
 endif
 
 aicasm/aicasm: aicasm/*.[chyl]

[skipped the 

	mv aic7xxx_reg.h shipped_aic7xxx_reg.h
	mv aic7xxx_seq.h shipped_aic7xxx_seq.h

 diff]

Re: Allow aic7xx firmware to be built from BK tree.

[Justin T. Gibbs]

>On Mon, 20 May 2002, Justin T. Gibbs wrote:
>
>> >This patch removes the two generate files (that are also in the
>> >distributed kernel) before attempting to regenerate them.
>> 
>> Why is this necessary?
>
>Well, I'll take Keith Owen's role and answer:
>
>Some people are using source control management systems which
>leave the managed files read-only.

These people shouldn't be rebuilding the firmware. 8-)

>Some developers use bitkeeper these days, and it'll show exactly this
>problem. I suppose the only reason that not more people complain about it
>is that hardly anyone has set CONFIG_AIC7XXX_BUILD_FIRMWARE=y.

Which is the default.  Those enabling this feature get what they get
as is documented in Configure.help (or at least was in 2.4.X).

>The correct way to fix this is to not overwrite the shipped files. The
>appended patch is a suggestion on how to avoid the mentioned problems.

>(I should pay credit to Keith Owens, since he proposed a similar solution
>before)

Only with lots of MD5 junk and other complicated rules.  I have no problem
with changing the name of the shipped files and using a link if that will
finally put this issue to rest.

--
Justin

Re: Allow aic7xx firmware to be built from BK tree.

[Kai Germaschewski]

On Mon, 20 May 2002, Justin T. Gibbs wrote:

> >Some people are using source control management systems which
> >leave the managed files read-only.
>
> These people shouldn't be rebuilding the firmware. 8-)

True, but some do anyway...

> Only with lots of MD5 junk and other complicated rules.  I have no problem
> with changing the name of the shipped files and using a link if that will
> finally put this issue to rest.

Okay, I'll take care of it. I think it should be done and over with, then.

--Kai

Re: Allow aic7xx firmware to be built from BK tree.

[Peter Chubb]

>>>>> "Kai" == Kai Germaschewski <kai-germaschewski@uiowa.edu> writes:

Kai> On Mon, 20 May 2002, Justin T. Gibbs wrote:
>> >Some people are using source control management systems which
>> >leave the managed files read-only.
>> 
>> These people shouldn't be rebuilding the firmware. 8-)

Kai> True, but some do anyway...

Or so as I do, and have a single source tree that's read-only, and
trees of links to the source tree that I build different
configurations from.

(The `touch' that   make depend   does really hurts here)

>> Only with lots of MD5 junk and other complicated rules.  I have no
>> problem with changing the name of the shipped files and using a
>> link if that will finally put this issue to rest.

Kai> Okay, I'll take care of it. I think it should be done and over
Kai> with, then.

Personally, I'd prefer a rule like:

aic7xxx_seq.h aic7xxx_reg.h: %.h : shipped_%.h
	cp $< $@

otherwise an attempt to build with CONFIG_AIC7XXX_BUILD_FIRMWARE yes
after a build with no will fail.

Peter C