Cleanup kbuild for aic7xxx

Cleanup kbuild for aic7xxx

[Keith Owens]

The existing build process for aic7xxx on Linux has several problems.

* Users have to manually select "rebuild firmware".  Relying on users
  to perform any action other than make *config is unacceptable.  It is
  far too error prone.

* Rebuilding the firmware requires lex, yacc and libdb.  Not everybody
  has these installed.

* The check for which libdb to use assumes that the presence of a db.h
  is enough, but the overlap between glibc-devel and dbx-devel packages
  means that finding a db.h is not enough, you have to confirm that the
  corresponding libdb exists.

* It checks if the firmware is up to date by comparing the timestamps
  on aic7xxx_seq.h and aic7xxx_reg.h against aic7xxx.seq and
  aic7xxx.reg.  Alas, when a patch hits those files there is no
  guarantee which order the files are listed in the patch so the final
  timestamp order is unreliable.  diff lists files in alphabetical
  order but other source repository systems can generate patches in any
  order.  This is a problem for all generated files, not just aic7xxx.

* Shipping files which are also overwritten by users causes problems
  for source control systems and can cause spurious differences when
  generating patches.  This is a problem for all generated files, not
  just aic7xxx.

The patch below fixes all of the above issues.  It does not touch the
aic7xxx code nor sequencer input, just the generated files and the
kbuild related files.  The patch is approx 100Kb but most of it is the
rename of aic7xxx_{seq,reg}.h to aic7xxx_{seq,reg}.h_shipped.

After applying this patch, normal users will not have to worry about
generating aic7xxx firmware.  In particular they will not have to
select "rebuild firmware" nor will they need lex, yacc or libdb.  Only
people who change one of these files

  aic7xxx_reg.h_shipped
  aic7xxx_seq.h_shipped
  aicasm/Makefile
  aicasm/aicasm.c
  aicasm/aicasm.h
  aicasm/aicasm_gram.y
  aicasm/aicasm_insformat.h
  aicasm/aicasm_scan.l
  aicasm/aicasm_symbol.c
  aicasm/aicasm_symbol.h

will need the extra tools.  Rebuilding firmware is required if any of
those files are changed, i.e. you are working on aic7xxx firmware.

aic7xxx_{seq,reg}.h need to be added to "don't diff" lists.  Now they
are always generated, instead of being partially supplied and partially
generated.

One extra action is required by anybody shipping patches to aic7xxx
firmware.  Before generating a patch for new firmware, just

  cd drivers/scsi/aic7xxx
  sh make_sequencer ship

to generate new versions of aic7xxx_{seq,reg}.h_shipped and the related
files.

Patch is against 2.4.5-ac17 but will fit 2.4.6-pre5 with one reject.
2.4.6-pre5 has no help text for CONFIG_AIC7XXX_BUILD_FIRMWARE so the
removal fails but the rest of the patch will work.

begin 644 patch-2.4.5-ac17-aic7xxx.gz
M'XL(").!,SL``VMA;P#5O6MW&[FQ*/I9^A6])[-V[+$E]9M-SYF<H4A*8DR1
M,DF-/=G)XFHVFS;O2)2V*&7LDYW_?@$4T%V%!YN6<\Y:F8<ML0I`5:'>0#<'
MFV7Y^8V7',?^R?)A_??R87NR+;;KD\O\MW*UOBD/CXZ.=H"]R[O-:R^(O<O\
MBQ?Z?N`%P9LH?!-EWJO`]WWOM_QNZ[VX66^>/A^%Q_')]<GB)`KFU?C@.#B.
MCQ,OC>.7AZ]>O>)KA8ZUIOGC:R^,O#\_;6`MGRT4O0E:7[56"FO]_+-WU`I>
ML['B3_;KW>+_._K^17<\.AN<SZ?=Z6#>N>@$2?CAY<&KG[S\4\Y^_GQ\=^A"
MC,,:,0[=B*W8KQ#9SQQQO2K_VWNAH0ZZK0\?/KQ\_>7EX9%E)@D6,ZV+UN?/
MGT_DW_/EP]_9K*^^;M#MW9*34FZ6ZY65=!@['P][>/S\[F9IYW5P-7UYP#'7
M]UN&,4"J9FI7M4EG#VNVR6&]R8'_)LG>^&W')L].BI/$IYL<'@>)^"L\;A\'
MXM^XI:G8L[5JWP6S6L_B('F=>J_X7T+3BILRW[PYR!^*3^+'0^_@X=8[6GE,
M@,-^9S0_&PS[TY?RXX?Z\]Y@(C[^_L5EYVW_I7?4]7IWQ=-MN7G,']=WFQ/V
MV^G=W6^PPN$KC$AL2FZ>Q/,.O=N'^X>[^_+A#7SD<=K49VS!U7JS](Z]O[[P
MCK;K_U-ZOG=TYQUM\MO2.UZ6]TQIO+^R51Z_W)?>RCNZ?UAO'KW_\3[G#Q^W
MGN"-[#\ENGNW6:T_/CV4QY_*F_M:)W9A>>_+)=LV'^E)],9OO0E\Q[;]A6U;
MX,_K6>3&9>S_5.Y9%&A*LI."KU6<O2@(:ZU)XRAY'03>*_%#RA5'FI<RQ4E_
MVI_->_UAY]?YY91OH^?URE7^=//XQ@L23L2+(/&V97&W66Z9XAP>G3ZM;Y9>
M9YG?/Y8/WMGZX?;W_*'T?E\_?O+>E@^;\L83*(='VEJGUX-ACRGFY/)]9](_
M/&)+39G/_]5[O/,>V`*W]]P8'C^5;+G_?BHW!9M^Q:;GLZ_N'@0$EBT\/B?3
M/IB$N0J/T??X<'=S4SX<'QX=>N.*Q`K7VS[=W]\]/!YZ#I_$>6>4C0:C<V_V
M:;V5^NZQGY@Z,R?%?E9:+T$YTUH&WMQY-W>;C^R#)Z:B#T11;4;#_\ZWMTTA
MTH$-BAND)&+&\9LD<*C-EY/E28;=3<@U95?`=*UL*BS7UC>)2V&M*T=(07GT
M3,&E]?I7%[W)5(2%Y>+XTZ%WWA_!)U^.'W/V20TY]*:3[O2G@^__P7#XC__T
MOO]'5_S`U(X[.N'_?O((@ISOGVR^NZ?'^Z?'PU?[XWJWC(MYI9GSQW++5.D/
MWIA)[6&]++TEF(WW&]A`]VS8.9\>>Z!*7(>\IVWY<,-5)K^_/S[D>MF97LX!
M\<U/WM'@Y&G[<++>%#=/;+ZCP;%W=+-<''J_"@R&L!1"B_S7`4N.V%]L)]@'
M,MY^_^)J,CY_^8;]P)EXR?Z6(@5_KY;K<@A9^V4UA+ED.0V3\:L_,%?`;/QV
MO6'F_6E=?/)NUHOE@MLK8\7[5'(/Y,V8(-:;CY6)WC^46RXB[V[%[4:RPV<3
M.B#,Y9$1???T\=-K/H*9]RW3Y$7);<SC2LA<Y98/YYO-,/)';WDG1MWFCXJ*
MUWS&[9U7?"J+W[SU(W,A^<W-%P;<_+8]/GQUJ+3ES>'1P<_KE?=?WE'I?8=%
M?+)<1.S_>9`EQY^^\_[V(Z=F<W#P5S;BH"P^W7G?_4'MQO_"N'_ZSON3FOY'
M@>Z5-ZXEPJ]8(GS>$E^QPO,6V'=VV]1J[FUY`/^@L3_\\(,WV&P?V<ZQS68F
M]/?RYNZ>QTN^R0_YP[K<?B>I6ZU9-O(S9#G*$;`/N-HQ"MC_'FP14QF\5QY(
MM?JA^C10GP;X4_4A_DS\(7_[T?LK6Y6I(__+\U[H,OC^>_;CG[[[T1.`/_(D
MYC9?;U[\_6Z]?.G]@TW$\J'-B^^^>^WYU7\O?V3:^_CTL'G!?_SG'U_*V3V6
M`'W_XF(\G7&K/6+)EO`(W$PMWL@[\L(_G3`9GFR>F#S_\S\]!W'U[G"D!3.<
MWRJ^-F4M99O'>R5MZ3]85EG-\C<YG.N&^`&V=\3]1+Y@1L]H_E3F2XB8)VS'
M8'>_,*?!(B9S(K_>/3''<;=@V%^\35DNN9-92\W(*]WP[O/BM_PC<SL_RG4^
M,\L/Y&],0UAD@-183X@A'ZZ\6V.$WC,T?U-,#F-:`^P9E)]==]C71/EB+)+%
M^'7&P@J/;16F\NU#/E>5!(G$"TADX>P//#D<SV>=R7E_YKVIRSNH)8\.CV[6
MV\>C6Q8CUP<(#%7CT9X5JD1_95M(@O@\MWR%[U\H+![.&#]7-_DC8^76F]Z7
MQ7JU+ECZ>E-N12B&+/#TSU.OGE"([OB._CZ_+]9L&2ZO('W-ZLQ70?0Z:/-(
M3*9!-#/-+N0TK98_O^&T=.]8W+,M7X]#*XLUJ]_:4?$YK2?DQ?/A$4I%[IX>
M/":,)VYYY7;]N!'5Q^'1Y;C'<OWIC!6!'A?/EE4A-U[!ZK)C[@EJX5_TAT-N
M++/Q%<-]R?3O87W_N#VYSQ\_+>]^WQQO/[T$07_A>R/RB8J#ESSX\J7D#B%^
M^#8H;U3//F&$;H^YM^%\D-U\4_',_!!D@.*WA_(C^TU?]XBE.<,>)YP5&A.>
MV[SD;HIG-3^;1*JY/I:;\B%_+)=8*RW+,;9>59SP-,N80-1'6B?&7OU`3V;'
M8A7CQPQ8_<Q`GLS)X2_&,OD=LL8'34Y'=W:^^-R'1SPT/X\6MCJ$F/?YPX;E
M@*^]2A25DUBI`I$[DFV5Z;&$FB=X#/4__KKYCA$ADMA7-J&^8:Y]^\D[/J'Q
M2.I*S?L;)9H?CO^K^/3EYF]"'ZKNA138*QD?7E7QP;*-K\R!LM'1&#B@.#]>
M;QHB1X7WO-"1S.L)OB)VU(.>%3S,55'TB'B'*GJ=<$\H<H3OOG=4VM]Y__&3
M]]T7ED_RFGL',B!NJL13H/,1+*WR_N@QD7U>WS[=>INGVP5++IA&S;KOO.+N
M]I;E&5OOGGW&\H9U4?Y1;WQT+WO3^55_POSA+X-NWPN32)]\L%D_KO,;;_&T
M]7A-PZJ0\H;M$>/]=GUSLSZ271%C;MI4@3:*Z%2P?Q9W=S=B]GW;*,;L6AN%
M3\H3'_;_/FV'VL;GVT_K^_MRV=Q\,,=8&P%A\L:GO;,]V@M[S=VDF>5)&,[K
MR;S*&+A:^J\Y4:^#,.6:>?CJY(?#5Y[W@]<;>Z/QS.OW!C.6.8LJ716H^=/C
M'2LUF=WSBK+R"\=BX,GAJRUOYQ7>$].4;/[(VU4LPG_\K[^Q4/</YCO\SXN0
M9?6??1_]F;T6D%6+_Q8$_,\PQ!#`2Q/^9QGS/Y,V'N.+,3X9LUJ),;F8+<:0
M&*T-/Z=JG4Q0($9&I?C9;QH#Z\!G42$@?M-L*<RV$"-#/!O,LQ)4!P+24K0)
M'N,E_[,0,T<^EDY<H#$^'A.U^9]Y:(X!Z;0%)"GQF`1V`;@*"$1(/"^E/`"R
MK&=KI03BU[.5@L)D::YCXP>H7I9$H@*R6$ALQ&D1U!3DN<G/0NQ"B\H@J'>N
M59J<M@4D\\TQ*\'C,K;,)B31AOU3&E(:<LM,"C198XV'_<DLNN,3#<EJ&009
MV87,L"R+)OIDMAA!0*M2:7,9@A0%'A,BK0J('@`$*$ABK/%D3.8:0ZG.XWJ,
MGYJ<1HHJ#(&U?5/?2D0!\*/&Q$BBR]347@F!,7+GLNS;9@M3/-L*9"!LH943
MW5G5$@-^*`3^M$(2"P2T;XG6L7BQ5HQW.W./"6K(,C,M"R!1B"$!:%4DY`+[
MUS9MP0?;)IJ8"HGE&;&%H(;8*``(I2!&LV4IUE%)M46K,-4+:HU.JDNT#NQ"
M8!D#LR5RG>5R_S'Q-\C@.;OPG'4P)"^P->)(ZI9UGNXG:XMTE.=S1PRQ*D2F
M"#1>40U>:%%3;:,`-%&M`SJ:H9W3O#^R4QH!I:\"WZOB'/)\<8Q]");;HL2T
MA<CO)#D>@ZD&2!Q@&7S=&)QQ@1[X%@CH@8*T]]IMD$1JV5/8'T5!D,NYO6JO
M_/W\Z/\-;[G,\2ZXO:4[:F)."\(IAF14>Q$$XG9LB:<E[.\WQ&"9K8/<B$2!
MTX60=4DT46I5@L:0B"'WM"2V$-2S!0326M40G^YIH$/H;)"!%`0BJ184KHAM
M9_X^5$N=B,UU*,2MHR`=H`"R&N5[81>L8\1OBZ7DWJ#`"LEVSR:S0>+]W766
M_`S\6X'7<5=ZL5OCW1DQRN-M.?D"V;8&`3LD489$#/"VMNS6QS(HG;Y7ZH[%
M6X9(JT(B46QS-@^;1Q:(X"=7>0;B)T#KR)C52+4[9F'?"W5EY7M1?IUF!!+7
MD*PDD+"&M&,"07E5$F*J<49LK5R36A()H0#BMJRJJ;>T5;L-E2O4FEKEBBB`
M/55>>4==LE>&0G?!O7,ABII)1N06.K4J=D*">K<!DA*KMW5DW-T5#)$RR,P]
M;='^@7M/L=QB+)UL+[UV9ZI:Q@40,8\UAP7M)CELLJ@A,%LH.87>1(JB3$!E
M4)@42+F),1#16\3FFOQUBV;KB.J,V,)^GMPF`]^2QV.J:5V"(2WB0X`"DO-9
MLFB:V4%$R(-:=U0O#;0"(&X]`%_%O$)#%ET@3V'34?!%U'[*)JO_JBPZ0+:=
M4V^)/!)H4*QR"MQ94/D%UH.VN:=!@<;X9`S*W+3>AE]#<IH?X-P?QA!-;`OO
M0GL;X'&D#W%2K=6GB.H%E6CN7`?GRN!=:*\3=M8G=HK\J/1\"<D&04-4?H<S
M?%OO"5>A(:$:(J"E!EP@^P'M9;D-ID!`VI`G1C+^(`A4/`I2($A)QI0(`G&E
M13)(:X7LK$MV]/"Q=R&=TQVQQ.VK(+<7LH8>L>8M00=)IW'AY(=0D&+M#4*#
M`M_4$-_FR1%$4;U<.?EQQD8\6TOQ9D"T^C2KO0=T'0/B0W*Q<S'P2ZP$^BJ0
M\VD0L1>QH"U,\#HE]$-*23OV%`*R(OM#/`61-9ZMDJXY)L8RR%"N#!2DB@(T
M&_C'5NBB6HT!?2DA8@L9E'1,Z1J#_6BFY);4NP#VERE.HWH7"MH7:QO22?`N
MD(I%2@=L"M8!Z62DEH&<F^Z/Y!2J:DN=!1!:(>-J%ZQ$>23I1Y/:L@++F(#F
M%"&B('=1$*<$@F2P`C]*HDQNJ>LQ;;(RRLG.6>IZK%41\;U2+QMZ`2O"J=P%
M2V1RZS7,EEGR1)!!AOK^6LQ"N5AFR<6H'@`D6]:V36T.*CD*`>T%VH#JMJT+
M"J=>J9F/MDCU;LD@+3FYK><-%`3$OV%^`N+?,#]@VY47$RL$L<46P$[]>ATK
MA'8CG.<_.<H<P%/8ZOJ<=K)P[@)[(3U2CM:AE6NK[8+('O&JWH64V$*T,,>0
M+)KFU]CS@=^1TB'U:8[7P1`M1X+ST<*R"Y`W1:8_<)^UY2A/!-U15.>1:\S"
M@-BR=>A.*M^[$IJ&(RW->T%'M3U%]J/I#LZK;!H2UWK2<N\</;42D)#*#?)]
MR$!(#BL[/]"KH3Y>4-TNI;VC/84^+)E-4M!^1@;I]N0DUE/:&KPRCDS-WM_M
MR=T2)=$YQ1HB;PS`N0R1&^XTYL3#XEV0_IK83SLRQX`,K/5/6%,`V8::39[Q
MPSEM069#NQ"3LQS,*8Q1'@G/5A!.=T@'5T8YG@VD`U0O"=52#^(:0F,6SFYI
M7+!EMQ*"LUL%06<!U+9QW-9L.T944WTS--&6X<<T(T:VO8HQISMV&^IMD$YI
M4O#_"@+[LPI-"$@'>JJVV31.G1&0C"'K!+YKMF7+D)OJQV<U9$6T%_8'\D#I
M-1:F1P)(BT!\5,LH"-Y3.@8J_J_SY$U^A]S?69C>19XS$=I`!H"EQF!9^R4>
M@V5-QQ1.6<O9H"M%>@$1VH6`R!IV0697O@72=D)R%R12F;4A`VLV&-1C;+6,
M/,\BM8P[0PE0]E1`3D&R#5B']KA(+X"<J)%^(GBYR%++T-W>R\>#W-1LN':6
M6=RB41/QF(QHE=`06Q4J^P=M:>^&9>4H&VR^>96[98W&:/W$I:&]C?U$-P5$
MHI;[ENV&:I=FG3OJX&?GEC`F(;;MKNNQ?\M('H(A*=UM\$A%+8.6Q2-E-):@
MK).N0V108!E@VX;S8,I/A&IG*AU?G;]Y>N9@[;+!&*2CM&/FH_.%T%+QNRT8
MSDLJFXMTVF@5:H4$#1!$M09!5%>G/,(6%J@7W=P?W=$Y12?%!3FK7F&_0F6-
M(A,]W\9:U:8QRWF:M-^]&JW:A;L$J.?0[/TQ9$4]+)Z-VBF>S7)?V38&:U7@
M/*<-:&\]JF>#&*RZ*[A/`3?)D@CO`NEZJ)-O5&]KWM(Y!FLOE>@.3XYHLT5-
MX(=Z\FCII`W7,B1J$KDI.S=BB39;47.JW79,7&,B)\0]&T1QZQAG5;!C'>QW
M0.,M-;H&<5<?H&/"CJ'^L66=2TL>`MI`Q^!J%\8TYY8X@RQ]"P4VC_1L?R`S
M':K7SMD"U'^C)\4!TFOM#!EB%FB\I1\B,ZY"4HAF6Z#L-I5]98C\"S0;[0WB
M^V\IJ4M(IX3<&URHKJTG(A>B&M-FRT/H66B.I"-/M"4_852O(^L6V^WG/6?#
MY^A`M3I'7R%.Y8[$YCH1&4/NLM&.YC?*0%;(T7[K@(9`A\/6BZ9GU6X=39%_
MBXB'Q>?.LO>D=CNN(?(>BI(;.I/(<@)!_,1T3(36\3$D1!"9WY$[C2FJ911D
MQSUOYR[@&^`%^"I;3D[T0.:]0$&*;2%!%$06'R)OK*5$WW!M%IJ6!3FYY%1"
MXKTXA3&*:JC`\!T,FW_3GG1J\&]@IPGQ![F;-LAJ0"XIT:H003("0=))B`QD
M-T_=;L9RB^O94DLN]G5W`-WKM)R<@@5+;;!XI*;;W#)#"4S:X#904NPWQKH.
M\E6Y)>M<V6HFT-O2`D&V#3GYDF1I((/<<A,&9FNK+-O(B.E='+FG('\5W0U.
MP2<J3G',DCD%J21`HC89N.\1P]UCJ8_-N^"T+'PZ1BLC#(DM>AT@6[#=VM,L
M&.Z'`(7./'[O?I5S'9*MTR?>G#X$[L@TW0ZD7DS>44YJJD/:.86^/N$43F!3
M=&\](%F-#8+]]5+Y<T0!5!J0(U5W08U[D-5M("R#W%S'1G6$M8I4;22:@9Y(
M#2F11PK)TS>6^P=4!@WKP,XE\;]F'2J#<C\*RF_E=+G7.O)YS6_@%-_\I=X%
MQLAGI&E68T0,6^;@?G)8]G(2/&:!.EG:$]=E/:9EN74$57E";GBYG[1MRARL
M]R`MLY4H(X9*+U6TA:XQ\JFET!RS(Q=SRGJ__$W;A=A%F]R%MG,7A`\)8\)I
MUC!;PY[2V0+WSJ%X"F-:*M]9U)`6Z8>0&A"J=R(=B/_6N^YY;0N^109:/$6W
M@:BLR8U<Y[U;G_3)<:9*XRFY"THS8G<6[;22Z!DY^?.[!+A7HR)3MA<%T%.B
MGL)JP:C;*D^3R&V@JLY%>@`6#%5=B[S_`-NVO),?F/P4A4D!V#:-P1:J*222
M4D:TQ8BV@G86</5.JNH8QQ];A@*Q`JJVQ!PC(;8G`8A/=,>2?Q%$69:JABHK
MH7><H9LGGP9?6J1#]P>-@=RR\B'F;6YRBS="]UW4[=K0T-XXM6B(Q;M`-0S6
MV")Z'5O\-?%(SDX)>!=E)3!&/I%H60<\7VZQ'QACB]M0?;34?2:<'XC/X#ER
MN@[,9K,2Z7MS$P*SV9ZP!.VUO0]%WOR%,18*X#DC:G.RB[/ONV>^XCTRU%>E
MZ*[UU[W7`["L[_6@%26&P&SJB1#G:<5^ZVCGSCBWI#?`$:?:\UG[/;%#_+7E
MB1V+;6OG&+!G>YV)*SO=$7]0+%E0GXABR<(92^C3A98H8^E%TW,F<LH#4=5R
MZAM8I&,]80<(W#VV]`_DW6-+9$K1?3'MMOV_"T3R(\_:XMH:51V<H#,4^K0D
MUAW8167;8>F:+4T;9D.T:=5[6(_1/!(:$UHR56NLMXRQ0&)3$_=^!Q'JNRSI
MK63DXTMJI_B.F2\M`O8'K4/]6^B$!$N=`@6!W\"[K%0/QMA3L#GE#]SK6#PL
MH0VZ2<_Q?)#A*!D$SG42/`;X:::Z[9I-/H%4UOY`S18XQRSQF!2/<3]A&>`Q
M4(%9GFO3GIMRQRRGOF$9V&*6]7XBTD2HG15MI#=(3B))3TC=#C!S,8BGEEHF
M)#OWG)B5.ZW1[0_D634ZFU*<XAN2$=D?T$N`@%_Z)HC(K^4S0\3S2:^,NFPV
MW^N6=4(ZZ/B45*ZC/%_BG`V=$$*>V$K-=2+B*5;N^Z/HC#\A6B5G`Q_O[.9E
M3MU)OQV"[O/9HN:_#<22H5C?X?7O`DE,^\E(;-Q/WS*B;SNJ:M1+@\P[)1HB
M3W5)G45N!]IN]?LU!5'L'$/J1E@G)_$'5\CPKDH%63JS=>+YP%\3#;%5U9;J
MD&:0>YVYTDHO=E:N<AU+?@VT[7C'IZURA5AB>]O%GMV5PU?__)&_&%V^$I>_
M.SG_5,SO^1>UA.%\];0I7FP?'YX*^'Q[MWHLO!_8CR^U88>O]AQW^(J_8Q>^
M+\-[\8)]=/2GQ=/'K?>?7N>B.Y]V3[L7G='\^FHX[O3FI]?G+_E+I'V^WC^=
ME`;/I'3G.!NEJS)GOY:*VNYE;\[)?>G]U$BC_TP:=X[;@\9WU_WK_GS2YU\4
MU$AET'X>E;O'[4'E^T&OO\=.!]DSZ=LYSDK?38Z5<GXZF^U#7^N9].T<UV`S
M5]W!/)P';(]GDU_W-)D@?2:A.\<U"7)V.>[UQ5Z/>_L:=Y`\D]*=XQI$VKF>
MC<^&U].+?8F,GTGDSG%[V,WU<#;IA/M8=O1,"G>.VT,S+]\/:B'R[RD12/?%
M>E[DQ:=2?)MDLWR?&8MVC]M7OOLHP#-#T.YQ>Q!X,9U?=@;#T_&'?:A\9A#:
M/6X/*B^9'`?SV:"W!Y'/#$'?&H'J6-Y(X3.#T#?%H,%H,!MT9N/)9#S<)U(^
M,Q!]=1PB[EU\8]">!#XS`'U]_*';W)OMX2R?&7*^.N*0)*//,K515WRGR7Y!
MYYDQY^M##J+RJG/>9^G0=`_RGAEPOCK>[,AWFRN'9R;EWTCC[/U@'S_SW)CR
M+\HI&NE[9C3YBF!2K\^_67I9K@0!8A8QR?S1L\S#!\E/!:KX6A<\Z."'^C>&
M>\"_"B8*V>>+\N-ZP[^Z\0WT"P\.MK^M[^?\JPP?M,]@YC=!R"F$=<IM]24R
M_]!W\;7'2FY6M0?>/U]3>"CAZ6LOW`5O.\9'$L[/#-A_H8'@*X30L4*L$)*F
M&5('#8E$"%U+*"+#5L,2_!T'UB52B1"YY-A2"&P)WAD)390,H5CG:*N]8N.C
M763R8_/(-D.@,'CC>R>G221D%9E3((3=,S2I5.+2*<5GDC4MX=(Z-4/:1&3J
M(E+-T&J:H=4X0Y-2M5Q*%2A99TV"R)H$T6XBHNTB0FEEP&\<L65BIT8$?MQD
MH7[2H!,!/X/9Z6@";N:Q55R5)_$;?4W@T.X08S3,$3:8>L"?MHIWS^$R]:`F
MI.T02,5NU$AJU$AJ%#F$6F'P8TW>[F^['73J6J8BM>7:?Z6G0=9D;T'69'!!
MNW&.=M,<(3]S3'>&`JZ'Z2Z+"?D-8'ZV;$ZB!!(Z?7V%$3<95<C#06A=):Q0
M7*&QXI=[Z\@:5"I*^(%Q8.4XJ`)HQOG9:9V1'SC(]2N,2(0OTSK;&&.G4"+N
MBW::3>0W.=7(;_*J41`U8J1-W'(-L4M,235RNIH@KE`2AT=K8XS=_(8N+:FR
MFT97$SE=325W?NN9JVS@[\BB@!LSUK0PQLYX%3EUOJ(U=AI?4J$T)GQI2[@!
M2Z*48)1D)R4\R]B-P6\!\MN;0;)#3[*@*?O,(I>OJ!AJ]*]1YI1;M8[3P=;$
M\K/R]BZ-C?E)YNX\5WJ*':DRKSMV^O$X8-QD.TF-PZ:P%3=6#K&S=%`RBZ.F
MW8N=QI55&"[7F5883?$DCAJYC5RF58N,!S9KMMC&&+N7B5T^O"(UAEQPAPY)
M+["#7>X%[,5256X%#CJJC4G`?G>LDC3EU[$H9D3ZZRZZXK31)%(@98=(4I</
MJ.=(FD3"<X'=<_`K^%:_V,88#7/$371DC71D4+:TW'1P#,9P:JZ2893=6I2Y
M,@$T25,`CK.FD!5SUVM-%BK[YJ^,W:TA;M]<8;A,4ZV2^(W]`]\ID*J\Y\_T
MM&PHRHLD:6,'('7E:&&%TFKRFHFHX46T<;>?$F?M4G5$LJ;,-G%J2=WRB!T.
MO$KUDLQ%2+V,2TLJ94S:KJ*A[JTXH[R:).6I/"^43&J3"B5R1->J`\,C=-M&
M234';PU:YU`B2<,F=4S#1OM,PZ;(F(:NQEM-B$MH%3/./*#"<.8!-8:+F8J.
MJ&E[T\C5:*E7<9E6A1&[+*O&<!I-)?;8M4R-DKC6J?AUAE?EL=*TJ71)G>T+
M%>93X2>L%7!%"'\>2_2?G";>"IK:0JW`9;_5'+P]M7N.T!7#E41:3CT+@PJ%
MS["S+]1RID\5K3RQX;:5N7>XU=BH;3D[M95C;/%8L%LHO,YJ6?M^(4;9F<JU
M>+]V9UK:XFZ>7YFT>/%*;MP!\WW>T=0-FM0^<R;B-4:K(1W(8K]I#LY*`!S#
ME4QY?%5LQ6G2TWR]>63UHSR@^I%\5&Z6X@BJ>%@_KHO\9KXMB\?UW08?1HFS
MH4H[N&I'56]`&%3+KZ""(49S]3LG+HM;]>],";*DXB;CR7N61(KT@BW]*,[I
M-D^W<X,J1A._\W.W>F&`7A[RT[4#[T1A_&"B_'@XV"S+SV^\Y#CV3Y8/Z[^7
M#]N3;;%=G^3KHO7Y\V?U]_RA_'C\:;[]M+Z_+Y>'1T='7SO&F^:/HECX\].&
MN1P_\/SH39B\\7WO%4MF?.^W_&[KO6!DOWK%YPZ_;>[P312]"5ID[IOUYNGS
M47@<GWPY*4_":%Y/Y@7'`?/M\<O#GW_VCOS7G*C7+3_U?O[Y\-7)#X>O/.\'
MKS?V1N.9U^\-9MZ1-_NTWGJK]4WIL;_SI\>[VUR(]^:+]['<E`_Y8[D\%@-/
M^)GK'Y;E:KTI#Z;=Z6#:?^>I?P[$'>@:?C#K\XM]7HW`[ZTC.)]@,IV-$=P/
MR`H?SB;=V=`G*P1HAM[9>.1Y[A5Z9U?]#U<$'F/X66<Z"WT"#S&\.V3T=4<S
M!`\(!U>#<7]$QOL9X;!SJ<-C.G_W0H.'%@D$1`(AFN%T,#N][K[MS^H9J(S?
M3SI7B`1=`M/9X+(_[0\QAYB#_DA@3%P<=+JS4?^\7D"G;SJ[>J]+(#"T:'!>
M*P''B+",>F,/_Z-S.!@;<,+AY?1\K,')'G=F(QU.][@_U.%DCT^GOQIP+*%)
M_YT!#XD$WQIPFX0&3@E=S7N=66<PFO=F:H;4-^#CZYE$L$A@H%&@2T"'ZQ(P
MX)H$#+@F`0-N2&#2F56NY$!?@=\=_G!&M)1:`3,C;8663[2\<SKLS[N3;@6G
M5C(8G3-XOW?>MTMH?#;5.5AIZ\L+-!A..1STT`3BF30*'Y^=396=ZW!!@;9"
MRUB!J<&0K)!:,"X(1HM@8%^H,#*,,;Z:#<:CVNT?Z+K"KU#SK50^0=\I#F?Z
M4+D,?2>8KEZ>7XYF:#S1Y=/KZ=FDWY_T?ZG@9*=8.+BZZ$Q9Y)M6.T$]-HAI
M/K@47DW7M)K!>:]_UF$2G^KFR%F8<Z_##:YOJCM;FH.YO5YWAERG#(7G5R:9
M,E;2%F+,,0:/3(/1C(;&A1:Z^L,>#JZQ'MH8?(#@1NAC=C]2SE,7)(.SV#<A
M@2'3QO/8LPO.HN>D]VL-IZ%O.NO,<&S6.81[I<3H,LUMD=!A&#5FWR(!PKY%
M`H0]"X=$/#95ZXU'?0V.58V(Q[/HT66'S&!HD=01FCP4QA[S^#ZV2I#!272T
MZ1#D<`.7#DE[=.L`&W^EY&1)CX2Q=B_.K1)@<!Y;1H-9/7]@Z%#%OT4"G'U-
M1S+-W7`U<^L09M\B`4'^Y6"*X('%7;EU!(O'(B$B'HN$B'B<$@HU"2VQP_N%
M+7]-$DAJ91>_=(8H=!D2.M-B!I,`#HW,(<]9$CGXI=81ZF<F7;9`+0)#AR;=
M_JA'X3&%,R%0.+$BYH-%8)\#CEU"D2:A4MLCS"-_J!)SP.(V$8$C^-?1^\#$
M&/"(XQ,::%@;46^G[P+`!Q@>&G#D[<SYJ3?3=X&-)][0`C=\54SAQ-OIN\2V
MF'@[<Y>$A&I3%Q(*=`Z9JT,<9EH*2&S=(D&P=:<$J:V;$J2V;I$0L7530M36
M30E16[<FT8P$D@`&H06#)(!!1#`N.KT>BFD"(R88$$\F!`/QR24\Z`U&+CC+
M,3OG_10MH4=E#D\(/##@,8'[QOP1A<<Z/*3P4(<'%!YH$L"9/'#8UO**WORR
M,WU;S4#]Q:A_.M#\14;WJ7/9K3-Y6"'7=*ES61>NEK@N$8!2(\EF62W;1><>
M],Z&LQGU^70/V.3#7X88[D=Z?JN7.\&"\,C<01<[%(F!"QX<V<VXQ.`^A<<Z
MO'O9PX4&X9$9V_QTTJOD;!;%_:O)F,B(VC,%FT4Q!GH6/1,2N,*9`]4S3%PE
M(1RY&0*K9%I."0$\Q?#8A"<8'IKP&,,##3Z=G7J[X#T<674)<@9Q56V!]W#N
MHDN8P2?OM?$&'-7,^@Z`@`,RWH3[!!X8_*.P;GJ*OKF#.+/H?V"&<LK*8<<.
M`GQ2]6#-"J=_J4E0JW#ZN,"PZ?C.'>#PMQH\IG"]`J,ZSN!:!:9)Z'3XUO!T
M.'OL#3KGK(3&5DP;P``?.]L)ZHENV0\PHWKG-*8-8DT"0Q8Q3YUP/EYK,&L2
M&O+>E5-"'[J_Z(TKS0M<3W^53UA.E80P!QPT1_TS!4<RGG0NYZ<LM4`RIAA"
M@^<L@4$8$5J#N='IX"]]1L;IL(_@-0:3;G?>J^4D,$CN0>9@?PZ&`H?D%OR9
M\4E_.N`I>S4+B8PC9A'PJ%^/OYX!,-IDCNGY?'R-DG6.03HK+-&\ZC"93#$&
MCCQ7DSY_"XE3Y^2+#/">&36CUA*G5LDHT."!"2=>@<`OS/%$)R_,\03>&TR8
M7QI@FR$Z>S8X`YMQZ"R'LVWJNS/1_KOYV;!S3B2,JW(FP-%L</;K?`I]0EW"
MH._BV>S!E"G+^7F_ITNY)])EMY2%8?`9KEAMP2H?H^Z\A!D0G$J)0"V6;8%C
M*8W&<VX5X]&("=LJI<XO0HM58UA(:6EB#*OB7&"4&&/8F<ZP'`0&]I]7\\L^
M;T4B*95&_X+FJA0^Y]7Q-<Y2"M^8OS:X`_Z*.@+OCB\O.Z->#:>9*HD/)EP=
M?;AL;3`VQNN'0_K1`^W?S,VJ+3#6)_SYQ/.][PQF;/^Y-[I0.Q`;OA&T`)S6
MA4`AJL`)J&90DU#W.;Z\&O9G%9;`("GW!7]=#:K>!$:L%7<31@)G2"`*#.)>
MW_8GH_YPSLK,J_%4S5%@C`J$5R%*^XX)"Z,(C-*RRDS-)3!(.V2F+<,Q$B)4
M;MRD.N`8:.,F_=GU9#0/7'#FHT8]WJ5W*9Z`3WE3P:Y8`C[I_]FE6/)\H.H9
M&.V"#X,97W\^'(^O/--),Y4QX+$.A^#?GTZ9,S_0^^L<ANI<$$%HB"C4X=2[
M$!EQ#-HO@"L"\UF?J2=+0`2&UO<AQZNZ&*$OY;;/_FA"$`PQCL2!4M7$MN1G
M`!_4\-@&OZKA1`;"6KKC:R9M$?,%APG&J%[1P0.5DE)JC8<ADF.+9`RG<Q:T
M,9=F;X?M^!G9"=P1F/4GERB#,]19Q&L1;)S[<-6]>(LIH-7R>WJ">:`=@%YH
M!YP'^M'B8#3K]2OZ)0<X)Q`MVMED@/ISA(-?F`,=X]:4WD.]&$]GAHR(:[KH
MS,-6/#\=C*?=V60(&)@+#F'NFJ>HJF^"\V`!QU=>=#A_D0QW;:?SJ\G@LC/Y
M]<!H[?3?&24A/<OO3R;C2:\Z43`"8N>Z/MRT;.09RZP1V-A(?B-&8T$KVM]V
M>I-!=0!K%$2S/CX3LQ0\[W!N:*1%/+-FR3<9KR>/&`X2TC%X^")'HVEHP2#>
M/XTHE0)!93X&%9UN]QKW;\0,-)H.1KW^!PTCH8'?@D$<0V<X'(_Z-,ZE;0WC
M+_U)'0H%!BEG1O20T8*!4_$*`Q<\?`5]3\DQ7&<R^56#![HL!EK;."UT61@8
MQ#C/KD>B*`DP!LD;6"9*NQ$<@^8-/.:A:Q0<HT7RAE-B?8"1T?M.1)K6@G](
MRPXJB]Y49KR^8X5NIWO1GUVX6QJL.D47),R4UH33D/EA-NF_&SK+1V;;+-Y,
M1'O8QB&#7.E-(4S_-7\1$"OEH["&$VT9C`F%AH18QLV/$.@>X+LNIVP+M3T@
M#?13>BG0#`5LA>F5UG[.4BSCL]G%I#X(,<H:"9^W$OL>36>4Q@-H5!`XIM$(
MA_7[VQP4\FB&4709"#C*D\W\]1U9P9!1CP7\`2KN7#*:![Z/981XZ(YX%*52
MQFG-U?C]I$<;%32'?C\PCHZ)ID[>Z>U-HJDB%FKPF&IZ7]\%HJD7@ZOZP,\L
M_B2\\CJ&)FNG92"!3)>1IV,4-+4[O9IIGK'M:ZD3WR>*06L9I@>SNHKGNH+A
MO!`9G\TGG1%<;^-%/H:/QG-5@:KQ2S(_2T]9#7/9F74OE"9@.(.QG*2NI!E\
M0>!O>2'#,Y,JK<K)+5^>8Z-["#I_/">:]UCURTMHJ>ND$=_ID38%]_J!84ND
MEDHQ'/<<Y7A2*P[.1^+MI;PYJ?18DU\E&PF/-+CH>"%X:-2BK):$1A'804#U
M6/29L)Z2M%7E;`X[$;DYO<!`:\G+7I?5;\Z<C<N7=)DT.P']HW:F7U2B"'R'
MM8L^+&:02QSZ933"I%$MPT6C:A&#P^&$,4DEI*U/F#`X$%FYMXL#$?4(!S1O
M[PX8L+9C6U37+F"$>E:@P6G3^!U%T"4T8*GF5;=._`U?.1Q.L3?3)<3@%SJ<
MYCUG-!P("4440^LE<@QRV0D:[_/.+\Q56&3(EH#<J::!UCZ#L_&[][W^95W,
MTYX,RXLT.](:Z^:%/=(2YA&Q/\5V;C;.KX?8CQB-\XHXNPS?DX@B)$1KBK.)
MB=&B&+T.":H<HZU%G*YAC;B9P!!X5P33J3W7P2<@\28@N06S),XK76&A89@T
MT$XCBUIX$H%!*@9^@78\XB\>#0A&;9,3!I_VG9DV7#WK7KRM:]U8@S-M(?!0
M@S.-(G"B3_*6+[^^IN(:T:?Z%G`-CW49D)MGG$-:$_$[1=H!0)M<7A,F5[MO
M@P<H5BH$G0<>-@<C,I[P(,_;\'AB$R*VHU.&`Y]>IA9PM(!N,Y`;U`N8M:<H
M'#5-PM&Q,V2J2CL>F:_9`SX?%3/D!D:W=SI7B9K"P'"51(C^.MLT&PZ?8SH;
M3_J..>2Y%[.>L8.*:I7I.2-&X,0Z#M<)E0\)C,S&BZ!C?M7I"13=00@N"+MZ
MTJKXK#`6Q$6P9(MWCZ?]<RQT#+\8G%^(<XCYZ4!<LM>?9S@%)M&N+&(ZA9#&
M7-Y/U36/IYS,&0.21;,XB:P`FH^DQS8UBTL*'$Q-@6Z_HJMZ:O<O_.0']60-
M_S+KG,\U.(U7;_GIVK1S[K@Z*\[M:=-7.^BM3YZ0?R%Y/:=A]NM59=N139M4
M8U=(`%]UFY&;<&:5RM]X.^]>C(8."0GXC+25R7,[8W-^_6KM*3H@E13B6#:T
M4&C,`(U[-,/"9C%#Y>8YAF$.^!DF@;&T8:CFE,`H=0Q^O8'085":QO,I3_04
M!JW(X<+1/,SDE1:%47O[:0VT:43WK0DGWGALPJG-0+BA%)!KNN+:W'QV5L]`
M+ZT-QM,Y?5Z1],<[/00$.+E2U1LT40A2/)VA1V^61(K=[H618Y4ZAI&]E!G%
MF)Z3-C?':.L8)*'F&+F.H5^.*LDC0`P!IZQ&?L/@.Y]>91ZRS^I6IG?]'G,1
M1E7$F=AUT8,AB$XBH;`P,+13Z7)I8'3I<VME2:GHGM*KX?01CLE$OWI.LSC>
MOJ9/R`:^/C^%T]I2K#\@E4^LPY&8[%+"#QES#G7+/M5U8>4;<Z`^D<"@O:@1
MU^QW55M28-#<P(9!#RI[%@RBUQPV9[O%[+S&T&J'JGZS[080P4+JD#=\S)@'
M)!"X=O68$<C;SV@W]*-4`9^'22KAA,<>8P`W?P4'V*K>3^:D/:S'I!K.,MH/
M.^%MWS,]&()G"<`3![R56"2(X&D$\,@!3^3ZH0,>)A9[F/0,_HF$:WC%OPNN
M^/=3.USQ3YYT17#%/[U8W3/X)Q4%@BO^Z2-3/8-_TLW"_`WD$Z*N_4=P9$7G
M<]&GF/.G*<;O0</(0VGGD/>J`EI:69WU]'I5XFSS."2SMG"HX'/I%\T8J"B\
MJC.)E?#;-$Z2JPV:G%&](FHTYB$U22(,4;Q--4DR[9&'=?(.M:P!+/`@936"
MYIA/69Z1S>7GVHU8>7E0=#4Y;RB>R`P%OB^"%PC</C(#SN_=:@LB>C*Y[(J2
M$X6*'K0=*M!S:]%B%\M\F9(,SF;:#HOR:OQ^)+IAPIFEL6;F^'S(.8<J4`1+
M.EE,/N>3\36_H=?KUU,DE')^>9@1SK1IJCD*D7JK`DJFU4C!.-GC,TV$!F.:
M<T*G5C5%YM[*IH&F;ZK-K]'"-R9(U<9H^BF_<!"1PO\]^<'KW?V^N;G+E^72
MZ_(WV^2;1Z_'QZWA=3;\52EJHL&(A2I^NT\8E=@O;MJZP9QS<X.$JS)_S3D2
MG"$_=U!(:%M49TPJHR8B/`5O0U"M,"E$*B';=FC>H/FU.[?Y;^5\6_[W4[DI
MRH>&]^U0Y'_1BW;VF#1HO4EVOF$GGM>S>,%Q:+QA)\O$"W;^\!\GB_7F9/N)
M_<C^@U?K;(N']?VCM][>W>2/Y=;+;VZ\QT^EM\FWCU^\XFY9LE_S1V]9%NLE
M@W^Z^]U[O/,63^N;I4"4G/`):SZ6^6/NY9NE]U#>WOV=#>.8M^5VZZT>[F[%
M;[^5#YOR1D[$7_"S/99TO2W7CY^\\>\E4]7_Q3G^^:[8'A=WM\?YTY^\WV#$
M;;[>/++_RX?77%HE?(^'+VP$F"O9XO_]M&84E!O.H+>Z>_!*1M/3EFV#]_NG
M.R]_8(S>/7K%IWSS<;WYR$C^\OB)__!0<G$L.:N,6,H<^RR_^3W_LN4S"5[4
M"Y(^E<SH'@0C+#*-[KQ-R3[EZ]Z4GU][7W+^M=<WZ\5RX96/18UV_W"WN"EO
M&5&<\^5ZM2H?.-%<7X3%WJW8JG<W6]N03^4&@!4[_+M?V#Z*%R/IA`#SC(7;
M?/,D7J/T6+(MEU)EGZNW*N'-9?OS</L[FUY,.+I[N,UOY$Q\DXWM?&#J^XBT
M2["U843G#_EM^2A%Q.<:;Q@%]8:(C2@]1B<AHY;]>G/_]+@%=ABQ?*'M/5/-
M_(;/QH3RD:VP/?:\KMI2;2S[L[AY6DJ5_"[?;LM;)LB'[[R<D<!%D6_5EC_<
M/3TR#=N"!3#BY7:C46REV1T7;`$@J0'"1+@"<GDPDV9T\@D-F=S=<X_L_5%,
M\$>8C').-8N+FT]4Y#?%$]=0)HG?O=MELGVZW8IEZ+Q\^!]?,]&NBT_>^O;^
M9LVX4:LA2Q%VSKAZNE7<?KE[\C[E?R_5Y&"XYZ-KIB^?'YE<;KB4!QM!Y=/F
M9OU;>?.%3U?^G6MN-0?724;6AF\%HRAG>E<P"RL%G4R^]71"E?B0(M\P+>9S
M2446:]SGQ6_YQ_(UV]!'IDN<II\")N2;N]^YW+@5\,&_K_D66LV3ST@<S>CN
ML7S#HJ4P&F;Q7SB%?,#CFLGA,;^]%Y8GC>"XJ)1=[0K,)E9_*,'6^#]@A]['
M)Z;NF\>2>]4%9Q6VX>YAR9T(FX8/W^1<Y$`UFS/G:LJD)-ZU5\^XO4.2(:02
M4I@XN)S%8/;9HF0[+:PI7S&C0P0JCACMW-M4.K=5WPHEJ+BY_Y0O2O&Z-4GU
M@G&QO;MER]X],1VJ9WPH[^^VZ\>[!ZY@2R%1-O=[N<=Y+8NEG$G,?Z.6>ZU,
M#OY!\N>R?-HPCM<Y,SB0->.="8!M,3>S;5EZZQ5?0KT.3KTNKI[OZ9YC+KF]
MK(5M<LW(F;<IB]^8(AWSO$FJE'_PAUJ[V+R5';`-!5-@V,*`?F*)"Y?^3R+Q
M8JC_Y7WW??"=]Y/WG8!_Y_WM\!5CBUG^`0Q@L>F`C5@QW5ZMM2%\)N>(>_X#
M'R('?0\.1WP]:3T$G.>2XS)Q"3S@Q(7H<\0MD_L!<.8='?%O/WO:>D>%=]E+
MIM>74X3^_?^F1,C//3HY-\\C/F=Q>^\=;96N\?0$O4J0?.K]S_]XQ?T^F.:T
M]`V%Y%-MVAV8;-KR\_K1\Q6#EYVW_9^^_P?_Z\T1SZ[^>?A*W-'NLD_AAS='
M'XL"OF=.<EP6+()]S\=X1UV^0+Z]K8?!WSJ<?[OL7]GR\-N)_/!H<.P=/6C<
M'-UI4E-6S'ZK-X7SI^_W[=^UJ>ROFR2(9`FZ);6^[!8MW4?.)663.U3\^YS'
M[N,O]$-&A#F2?[O=BF<ACT`C@FR9CSR^L8W9?KE=W-T8B\J/Z3*7;,N%%_E3
M;0>@&5)/&DL+-6QW32&Q_D7%Q*[9&JN(9*Z&VTJ(P!<EQ&(9A-$B+MIA'*?Y
M<K6(EVG27D7ML&C'1;3R7*JUR+,H6V51TL[*=I:669)DRS)OY7G;]UN1[[E4
M+5LN\CCQ2W_1*A:Y7T2M51+Z:9)E:;N(T\S3U*4X?+7TVZUV66:+O%Q&JR(K
MDBA8Y$60MY=IN%JM/*O:';[RD[@(P\A?Q,$J3H,H:+6C1=9*\ZA8AJTBT9=B
M;J/(%D&P+!914/K+UJ*,RR`)PV21!JO(CUE.Y3GUEM&9K?RBM6HM5RU&7AIG
M:>&O6JT@2$N_;!6Y/AA4^_!5'F3MQ`_3,@KR,DH21FD61U&Z\/VL'?BQ,4XJ
M/ANY2-KQJBC\+"FY8L0E)SF/XF)1K)+27%':!ANY\AF-[59<KHHH3(.L#/,T
M6H9YR,241[5,E>4@"VEXQRPX]OW>=0M>Z7VYY*_<]BY9!B#T.PC>Q/&;)'#J
M]_*D/:_GX*^A/:Y>1;O?FW!AY7WME%L.,YHP3;Q7W(*8[1R=_'!X]-SWVQZ)
M]]L>R>\FY=_]F<T?>6G#*Q[YTN0C?NC*BF#>4D%_9J\%9-7BO_&7*ON?PQ!#
M`(]_NX?_N8SYGTD;C_'%&)^,6:W$F%S,%F-(C-:&GU.U3B8H$".C4OSL-XV!
M=>"SJ!`0OVFV%&9;B)$AG@WF60FJ`P%I*=H$C_&2_UF(F2,?2R<NT!@?C^'O
MP_<_YZ$Y!J33%I"DQ&,2V`7@*B`0(?&\E/(`R+*>K942B%_/5@H*DZ6YCHT?
MH'I9$HD*R&(AL1&G15!3D.<F/PNQ"RTJ@Z#>N59I<MH6D,PWQZP$C\O8,IN0
M1!OV3VE(:<@M,RG09(TU'O8GL^B.3S0DJV409&07,L.R+)KHD]EB!`&M2J7-
M90A2%'A,B+0J('H`$*`@B;'&DS&9:PRE.H_K,7YJ<AHIJC`$UO9-?2L1!<"/
M&A,CB2Y34WLE!,;(G<NR;YLM3/%L*Y"!L(563G1G54L,^*$0^-,*22P0T+XE
M6L?BQ5HQWNW,/2:H(<O,M"R`1"&&!*!5D9`+[%_;M`4?;)MH8BHDEF?$%H(:
M8J,`()2"&,V6I5A')=46K<)4+Z@U.JDNT3JP"X%E#,R6R'66R_W'Q-\@@^?L
MPG/6P9"\P-:((ZE;UGFZGZPMTE&>SQTQQ*H0F2+0>$4U>*%%3;6-`M!$M0[H
M:(9V3O/^R$YI!)2^"GROBG/(\\4Q]B%8;HL2TQ8BOY/D>`RF&B!Q@&7P=6-P
MQ@5ZX%L@H`<*TMYKMT$2J65/87\4!4$NY_:JO?+W\Z/_-[SE,L>[X/:6[JB)
M.2T(IQB24>U%$(C;L26>EK"_WQ"#9;8.<B,2!4X70M8ET42I50D:0R*&W-.2
MV$)0SQ802&M50WRZIX$.H;-!!E(0B*1:4+@BMIWY^U`M=2(VUZ$0MXZ"=(`"
MR&J4[X5=L(X1ORV6DGN#`BLDVSV;S`:)]W?76?(S\&\%7L==Z<5NC7=GQ"B/
MM^7D"V3;&@3LD$09$C'`V]JR6Q_+H'3Z7JD[%F\9(JT*B42QS=D\;!Y9((*?
M7.49B)\`K2-C5B/5[IB%?2_4E97O1?EUFA%(7$.RDD#"&M*."03E54F(J<89
ML;5R36I))(0"B-NRJJ;>TE;M-E2N4&MJE2NB`/94>>4==<E>&0K=!??.A2AJ
M)AF16^C4JM@)">K=!DA*K-[6D7%W5S!$RB`S][1%^P?N/<5RB[%TLKWTVIVI
M:AD70,0\UAP6M)ODL,FBAL!LH>04>A,IBC(!E4%A4B#E)L9`1&\1FVORURV:
MK2.J,V(+^WERFPQ\2QZ/J:9U"8:TB`\!"DC.9\FB:68'$2$/:MU1O330"H"X
M]0!\%?,*#5ET@3R%34?!%U'[*9NL_JNRZ`#9=DZ])?)(H$&QRBEP9T'E%U@/
MVN:>!@4:XY,Q*'/3>AM^#<EI?H!S?QA#-+$MO`OM;8#'D3[$2;56GR*J%U2B
MN7,=G"N#=Z&]3MA9G]@I\J/2\R4D&P0-4?D=SO!MO2=<A8:$:HB`EAIP@>P'
MM)?E-I@"`6E#GAC)^(,@4/$H2($@)1E3(@C$E1;)(*T5LK,NV='#Q]Z%=$YW
MQ!*WKX+<7L@:>L2:MP0=))W&A9,?0D&*M3<(#0I\4T-\FR='$$7U<N7DQQD;
M\6PMQ9L!T>K3K/8>T'4,B`_)Q<[%P"^Q$NBK0,ZG0<1>Q(*V,,'KE-`/*27M
MV%,(R(KL#_$41-9XMDJZYI@8RR!#N3)0D"H*T&S@'UNABVHU!O2EA(@M9%#2
M,:5K#/:CF9);4N\"V%^F.(WJ72AH7ZQM2"?!NT`J%BD=L"E8!Z23D5H&<FZZ
M/Y)3J*HM=19`:(6,JUVP$N61I!]-:LL*+&,"FE.$B(+<14&<$@B2P0K\*(DR
MN:6NQ[3)RB@G.V>IZ[%61<3W2KULZ`6L"*=R%RR1R:W7,%MFR1-!!AGJ^VLQ
M"^5BF247HWH`D&Q9VS:U.:CD*`2T%V@#JMNV+BB<>J5F/MHBU;LE@[3DY+:>
M-U`0$/^&^0F(?\/\@&U77DRL$,066P`[]>MUK!#:C7">_^0H<P!/8:OK<]K)
MPKD+[(7T2#E:AU:NK;8+(GO$JWH74F(+T<(<0[)HFE]CSP=^1TJ'U*<Y7@=#
MM!P)SD<+RRY`WA29_L!]UI:C/!%T1U&=1ZXQ"P-BR]:A.ZE\[TIH&HZT-.\%
M'=7V%-F/ICLXK[)I2%SK2<N]<_342D!"*C?(]R$#(3FL[/Q`KX;Z>$%UNY3V
MCO84^K!D-DE!^QD9I-N3DUA/:6OPRC@R-7M_MR=W2Y1$YQ1KB+PQ`.<R1&ZX
MTY@3#XMW0?IK8C_MR!P#,K#6/V%-`60;:C9YQ@_GM`69#>U"3,YR,*<P1GDD
M/%M!.-TA'5P9Y7@VD`Y0O2142SV(:PB-63B[I7'!EMU*",YN%02=!5#;QG%;
ML^T844WUS=!$6X8?TXP8V?8JQISNV&VHMT$ZI4G!_RL([,\J-"$@'>BIVF;3
M.'5&0#*&K!/XKMF6+4-NJA^?U9`5T5[8'\@#I==8F!X)("T"\5$MHR!X3^D8
MJ/B_SI,W^1UR?V=A>A=YSD1H`QD`EAJ#9>V7>`R6-1U3.&4M9X.N%.D%1&@7
M`B)KV`697?D62-L)R5V02&76A@RLV6!0C['5,O(\B]0R[@PE0-E3`3D%R39@
M'=KC(KT`<J)&^HG@Y2)++4-W>R\?#W)3L^':669QBT9-Q&,RHE5"0VQ5J.P?
MM*6]&Y:5HVRP^>95[I8U&J/U$Y>&]C;V$]T4$(E:[ENV&ZI=FG7NJ(.?G5O"
MF(38MKNNQ_XM(WD(AJ1TM\$C%;4,6A:/E-%8@K).N@Z108%E@&T;SH,I/Q&J
MG:ET?'7^YNF9@[7+!F.0CM*.F8_.%T)+Q>^V8#@OJ6PNTFFC5:@5$C1`$-4:
M!%%=G?((6UB@7G1S?W1'YQ2=%!?DK'J%_0J5-8I,]'P;:U6;QBSG:=)^]VJT
M:A?N$J">0[/WQY`5];!X-FJG>#;+?67;&*Q5@?.<-J"]]:B>#6*PZJ[@/@7<
M)$LBO`NDZZ%.OE&]K7E+YQBLO52B.SPYHLT6-8$?ZLFCI9,V7,N0J$GDINS<
MB"7:;$7-J7;;,7&-B9P0]VP0Q:UCG%7!CG6PWP&-M]3H&L1=?8"."3N&^L>6
M=2XM>0AH`QV#JUT8TYQ;X@RR]"T4V#S2L_V!S'2H7CMG"U#_C9X4!TBOM3-D
MB%F@\99^B,RX"DDAFFV!LMM4]I4A\B_0;+0WB.^_I:0N(9T2<F]PH;JVGHA<
MB&I,FRT/H6>A.9*./-&6_(11O8ZL6VRWG_><#9^C`]7J''V%.)4[$IOK1&0,
MN<M&.YK?*`-9(4?[K0,:`AT.6R^:GE6[=31%_BTB'A:?.\O>D]KMN(;(>RA*
M;NA,(LL)!/$3TS$16L?'D!!!9'Y'[C2FJ)91D!WWO)V[@&^`%^"K;#DYT0.9
M]P(%*;:%!%$067R(O+&6$GW#M5EH6A;DY))3"8GWXA3&**JA`L-W,&S^37O2
MJ<&_@9TFQ!_D;MH@JP&YI$2K0@3)"`1))R$RD-T\=;L9RRVN9TLMN=C7W0%T
MK]-R<@H6++7!XI&:;G/+#"4P:8/;0$FQWQCK.LA7Y9:L<V6KF4!O2PL$V3;D
MY$N2I8$,<LM-&)BMK;)L(R.F=W'DGH+\570W.`6?J#C%,4OF%*22`(G:9."^
M1PQWCZ4^-N^"T[+PZ1BMC#`DMNAU@&S!=FM/LV"X'P(4.O/XO?M5SG5(MDZ?
M>'/Z$+@CTW0[D'HQ>4<YJ:D.:><4^OJ$4SB!3=&]]8!D-38(]M=+Y<\1!5!I
M0(Y4W04U[D%6MX&P#')S'1O5$=8J4K61:`9Z(C6D1!XI)$_?6.X?4!DTK`,[
ME\3_FG6H#,K]*"B_E=/E7NO(YS6_@5-\\Y=Z%Q@CGY&F68T1,6R9@_O)8=G+
M2?"8!>ID:4]<E_68EN76$53E";GAY7[2MBESL-Z#M,Q6HHP8*KU4T1:ZQLBG
MED)SS(Y<S"GK_?(W;1=B%VUR%]K.71`^)(P)IUG#;`U[2F<+W#N'XBF,::E\
M9U%#6J0?0FI`J-Z)="#^6^^ZY[4M^!89:/$4W0:BLB8W<IWW;GW2)\>9*HVG
MY"XHS8C=6;332J)GY.3/[Q+@7HV*3-E>%$!/B7H*JP6C;JL\32*W@:HZ%^D!
M6#!4=2WR_@-LV_).?F#R4Q0F!6#;-`9;J*:02$H9T18CV@K:6<#5.ZFJ8QQ_
M;!D*Q`JHVA)SC(38G@0@/M$=2_Y%$&59JAJJK(3><89NGGP:?&F1#MT?-`9R
MR\J'F+>YR2W>"-UW4;=K0T-[X]2B(1;O`M4P6&.+Z'5L\=?$(SD[)>!=E)7`
M&/E$HF4=\'RYQ7Y@C"UN0_714O>9<'X@/H/GR.DZ,)O-2J3OS4T(S&9[PA*T
MU_8^%'GS%\98*(#GC*C-R2[.ON^>^8KWR%!?E:*[UE_W7@_`LK[7@U:4&`*S
MJ2="G*<5^ZVCG3OCW)+>`$><:L]G[??$#O'7EB=V++:MG6/`GNUU)J[L=$?\
M0;%D07TBBB4+9RRA3Q=:HHRE%TW/F<@I#T15RZEO8)&.]80=('#WV-(_D'>/
M+9$I1??%M-OV_RX0R8\\:XMK:U1U<(+.4.C3DEAW8!>5;8>E:[8T;9@-T:95
M[V$]1O-(:$QHR52ML=XRQ@*)34W<^QU$J.^RI+>2D8\OJ9WB.V:^M`C8'[0.
M]6^A$Q(L=0H4!'X#[[)2/1AC3\'FE#]PKV/QL(0VZ"8]Q_-!AJ-D$#C72?`8
MX*>9ZK9K-OD$4EG[`S5;X!RSQ&-2/,;]A&6`QT`%9GFN37MNRAVSG/J&96"+
M6=;[B4@3H796M)'>(#F))#TA=3O`S,4@GEIJF9#LW'-B5NZT1K<_D&?5Z&Q*
M<8IO2$9D?T`O`0)^Z9L@(K^6SPP1SR>],NJRV7RO6]8)Z:#C4U*YCO)\B7,V
M=$((>6(K-=>)B*=8N>^/HC/^A&B5G`U\O+.;ESEU)_UV"+K/9XN:_S802X9B
M?8?7OPLD,>TG([%Q/WW+B+[MJ*I1+PTR[Y1HB#S5)746N1UHN]7OUQ1$L7,,
MJ1MAG9S$'UPAP[LJ%63IS-:)YP-_333$5E5;JD.:0>YUYDHKO=A9N<IU+/DU
MT+;C'9^VRA5BB>UM%WMV5PZ/_OGCX5'U2MSUYM'+/Q5S\7T"83A?/6V*%]O'
MAZ<"/M_>K1X+[P?VXTMMV.'1GN,.C_@[=A_*QZ>'C??B!?OHZ$^+IX];[S^]
MSD67?Y-N]Z(S4M_*='I]_E*\AYVO]T\GI<$S*=TYSD;IJLS9KZ6B5GS#&"/W
MI?=3(XW^,VG<.6X/&N%KSB;]\^D>5`;MYU&Y>]P>5+X?]/I[['20/9.^G>.L
M]-WD6"GYM\7N0U_KF?3M'-=@,U?=P3R<!VR/9Y-?]S29('TFH3O'-0ERQK^%
M7>PU_X+#/2E-GDGISG$-(NU<S\9GP^OIQ;Y$QL\D<N>X/>P&OC9Q'\N.GDGA
MSG%[:.;E^T$M1/Y%'0+IOEC/BYQ_:<WZ_Y1[R/>9L6CWN'WENX\"/#,$[1ZW
M!X$74_5UB?M0^<P@M'O<'E1>,CD.^->\[T'D,T/0MT:@.I8W4OC,(/1-,:CZ
M(M;)>+A/I'QF(/KJ.$3<N_ANSCT)?&8`^OKX0[>Y-]O#63XSY'QUQ"%)1I]E
M:J-N?S+O]?<+.L^,.5\?<A"55YWS/DN'IGN0]\R`\]7Q9D>^VUPY/#,I_T8:
M9^\'^_B9Y\:4?U%.T4C?,Z/)5P23>OW'+_?ELEP)`L0L8I+YHV>9AP^2GPI4
M\;4N>-#!#_5O#/>`?Q5,%++/%^7']>;`\[PWT"\\.-C^MK[G7SCT^*!]!C._
M"4).H?H&ONI+9/ZA[^)KCY7<K&H/O'^^IO!0PM/77K@+WG:,CR2<GQFP_T(#
MP5<(H6.%6"$D33.D#AH2B1"ZEE!$AJV&)?@[#JQ+I!(A<LFQI1#8$KPS$IHH
M&4*QSM%6>\7&1[O(Y,?FD6V&0&'PQO=.3I-(R"HRIT`(NV=H4JG$I5.*SR1K
M6L*E=6J&M(G(U$6DFJ'5-$.K<88FI6JYE"I0LLZ:!)$U":+=1$3;1832RH#?
M.&++Q$Z-"/RXR4+]I$$G`GX&L]/1!-S,8ZNX*D_B-_J:P*'=(<9HF"-L,/6`
M/VT5[Y[#9>I!34C;(9"*W:B1U*B1U"AR"+7"X,>:O-W?=COHU+5,16K+M?]*
M3X.LR=Z"K,G@@G;C'.VF.4)^YICN#`5<#]-=%A/R&\#\;-F<1`DD=/KZ"B-N
M,JJ0AX/0NDI8H;A"8\4O]]:1-:A4E/`#X\#*<5`%T(SSL],Z(S]PD.M7&)$(
M7Z9UMC'&3J%$W!?M-)O(;W*JD=_D5:,@:L1(F[CE&F*7F))JY'0U05RA)`Z/
MUL88N_D-75I293>-KB9RNII*[OS6,U?9P-^110$W9JQI88R=\2IRZGQ%:^PT
MOJ1":4SXTI9P`Y9$*<$HR4Y*>):Q&X/?`N2W-X-DAYYD05/VF44N7U$QU.A?
MH\PIMVH=IX.MB>5GY>U=&AOSD\S=>:[T%#M295YW[/3C<<"XR7:2&H=-82MN
MK!QB9^F@9!9'3;L7.XTKJS!<KC.M,)KB21PU<ANY3*L6&0]LUFRQC3%V+Q.[
M?'A%:@RYX`X=DEY@![O<"]B+I:K<"AQT5!N3@/WN6"5IRJ]C4<R(]-===,5I
MHTFD0,H.D:0N'U#/D32)A.<"N^?@5_"M?K&-,1KFB)OHR!KIR*!L:;GIX!B,
MX=1<)<,HN[4H<V4":)*F`!QG32$KYJ[7FBQ4]LU?&;M;0]R^N<)PF:9:)?$;
M^P>^4R!5><^?Z6G94)072=+&#D#JRM'""J75Y#434<.+:.-N/R7.VJ7JB&1-
MF6WBU)*ZY1$[''B5ZB69BY!Z&9>65,J8M%U%0]U;<49Y-4G*4WE>*)G4)A5*
MY(BN50>&1^BVC9)J#MX:M,ZA1)*&3>J8AHWVF89-D3$-78VWFA"7T"IFG'E`
MA>',`VH,%S,5'5'3]J:1J]%2K^(RK0HC=EE6C>$TFDKLL6N9&B5QK5/QZPRO
MRF.E:5/IDCK;%RK,I\)/6"O@BA#^/);H/SE-O!4TM85:@<M^JSEX>VKW'*$K
MABN)M)QZ%@85"I]A9U^HY4R?*EIY8L-M*W/O<*NQ4=MR=FHKQ]CBL6"W4'B=
MU;+V_4*,LC.5:_%^[<ZTM,7=/+\R:?'BE=RX`^;[O*.I&S2I?>9,Q&N,5D,Z
MD,5^TQR<E0`XABN9\OBJV(K3I*?Y>O/(ZD=Y0/4C^:C<+,415/&P?EP7^<U\
M6Q:/Z[L-/HP29T.5=G#5CJK>@#"HEE]!!4.,YNIW3EP6M^K?F1)D2<5-QI/W
M+(D4Z05;^E&<TVV>;N<&58PF?N?G;O7"`+T\Y*=K!]Z)POC!1/GQ<+!9EI_?
M>,EQ')XL']9_+Q^V)]MBNS[)UT7K\^?/ZN_Y0_GQ^-/AT=$1Q_7WP/7>ETON
M?KS+_`MS,7[`Y/8FCM\P7E^QY,7W?LOOMMZ+F_7FZ?-1>!R??#E9G@3^O)[$
M"X[%O\SGQB\/7[UZM2^9WC1_%'7)GY\VL+0?O0F3-VQ1O/3+PY]_]HZ"URT_
M]5[YKWWOYY\/CTY^.#SRO!^\WM@;C6=>OS>8>4?>[--ZZZW6-Z7'_LZ?'N]N
M<R'*FR_>QW)3/N2/Y?)8##SAYZM_6):K]:8\F':G@VG_G:?^.1#WG6OXP:S/
M+_%Y-0*_HX[@?(+)=#9&<#\@*WPXFW1G0Y^L$*`9>F?CD>>Y5^B=7?4_7!%X
MC.%GG>DL]`D\Q/#ND-'7'<T0/"`<7`W&_1$9[V>$P\ZE#H_I_-T+#1Y:)!`0
M"81HAM/![/2Z^[8_JV>@,GX_Z5PA$G0)3&>#R_ZT/\0<8@[Z(X$Q<7'0Z<Y&
M_?-Z`9V^Z>SJO2Z!P-"BP7FM!!PCPC+JC3W\C\[A8&S`"8>7T_.Q!B=[W)F-
M=#C=X_Y0AY,]/IW^:L"QA";]=P8\)!)\:\!M$AHX)70U[W5FG<%HWINI&5+?
M@(^O9Q+!(H&!1H$N`1VN2\"`:Q(PX)H$#+@A@4EG5KF2`WT%?D_XPQG14FH%
MS(RT%5H^T?+.Z;`_[TZZ%9Q:R6!TSN#]WGG?+J'QV53G8*6M+R_+8#CE<-!#
M$XCGSRA\?'8V57:NPP4%V@HM8P6F!D.R0FK!N"`8+8*!?:'"R##&^&HV&(]J
MMW^@ZPJ_+LVW4OD$?:<XG.E#Y3+TG6"Z>GE^.9JA\4273Z^G9Y-^?]+_I8*3
MG6+AX.JB,V61;UKM!/78(*;YX%)X-5W3:@;GO?Y9ATE\JILC9V'.O0XWN+ZI
M[FQI#N;V>MT9<ITR%)Y?CV3*6$E;B#''&#PR#48S&AH76NCJ#WLXN,9Z:&/P
M`8(;H8_9_4@Y3UV0#,YBWX0$ADP;SV//+CB+GI/>KS6<AK[IK#/#L5GG$.Z0
M$J/+-+=%0H=AU)A]BP0(^Q8)$/8L'!+QV%2M-Q[U-3A6-2(>SZ)'EQTR@Z%%
M4D=H\E`8>\SC^]@J008GT=&F0Y###5PZ).W1K0-L_)62DR4]$L;:O3BW2H#!
M>6P9#6;U_(&A0Q7_%@EP]C4=R31WP]7,K4.8?8L$!/F7@RF"!Q9WY=81+!Z+
MA(AX+!(BXG%**-0DM,0.[Q>V_#5)(*F57?S2&:+094CH3(L93`(X-#*'/&=)
MY."76D>HGYETV0*U"`P=FG3[HQZ%QQ3.A$#AQ(J8#Q:!?0XX=@E%FH1*;8\P
MC_P!2LP!B]M$!([@7T?O`Q-CP"..3VB@86U$O9V^"P`?8'AHP)&W,^>GWDS?
M!3:>>$,+W/!5,843;Z?O$MMBXNW,71(2JDU=2"C0.62N#G&8:2D@L76+!,'6
MG1*DMFY*D-JZ14+$UDT)45LW)41MW9I$,Q)(`AB$%@R2``81P;CH]'HHI@F,
MF&!`/)D0#,0GE_"@-QBYX"S'[)SW4[2$'I4Y/"'PP(#'!.X;\T<4'NOPD,)#
M'1Y0>*!)`&?RP&%;RRMZ\\O.]&TU`_47H_[I0/,7&=VGSF6WSN1AA5S3I<YE
M7;A:XKI$`$J-))MEM6P7G7O0.QO.9M3GTSU@DP]_&6*X'^GYK5[N!`O"(W,'
M7>Q0)`8N>'!D-^,2@_L4'NOP[F4/%QJ$1V9L\]-)KY*S613WKR9C(B-JSQ1L
M%L48Z%GT3$C@"F<.5,\P<96$<.1F"*R2:3DE!/`4PV,3GF!X:,)C#`\T^'1V
MZNV"]W!DU27(&<15M07>P[F++F$&G[S7QAMP5#/K.P`"#LAX$^X3>&#PC\*Z
MZ2GZY@[BS*+_@1G**2N''3L(\$G5@S4KG/ZE)D&MPNGC`L.FXSMW@,/?:O"8
MPO4*C.HX@VL5F":AT^%;P]/A[+$WZ)RS$AI;,6T``WSL;">HI[=E/\",ZIW3
MF#:(-0D,6<0\=<+Y>*W!K$EHR'M73@E]Z/ZB-ZXT+W`]_54^33E5$L(<<-`<
M]<\4',EXTKF<G[+4`LF88@@-GK,$!F%$:`WF1J>#O_09&:?#/H+7&$RZW7FO
MEI/`(+D'F8/].1@*'));\.?#)_WI@*?LU2PD,HZ81<!C?3W^*@;`:),YIN?S
M\35*UCD&Z:RP1/.JPV0RQ1@X\EQ-^OR-(TZ=DR\MP'MFU(Q:2YQ:):-`@P<F
MG'@%`K\PQQ.=O##'$WAO,&%^:8!MANCLV>`,;,:ALQS.MJGOSD3[[^9GP\XY
MD3"NRID`1[/!V:_S*?0)=0F#OHOGL`=3IBSGY_V>+N6>2)?=4A:&P6>X8K4%
MJWR,NO,29D!P*B4"M5BV!8ZE-!K/N56,1R,F;*N4.K\(+5:-82&EI8DQK(IS
M@5%BC&%G.L-R$!C8?U[-+_N\%8FD5!K]"YJK4OB<5\?7.$LI?&/^VN`.^.OH
M"+P[OKSLC'HUG&:J)#Z8<'7TX;*UP=@8KQ\.Z4</M'\S-ZNVP%B?\.<3S_>^
M,YBQ_>?>Z$+M0&SX1M`"<%H7`H6H`B>@FD%-0MWG^/)JV)]56`*#I-P7_-4T
MJ'H3&+%6W$T8"9PA@2@PB'M]VY^,^L,Y*S.OQE,U1X$Q*A!>A2CM.R8LC"(P
M2LLJ,S67P"#MD)FV#,=(B%"Y<9/J@&.@C9OT9]>3T3QPP9F/&O5XE]ZE>`(^
MY4T%NV()^*3_9Y=BR?.!JF=@M`L^#&9\_?EP/+[R3"?-5,:`QSH<@G]_.F7.
M_$#OKW,8JG-!!*$AHE"'4^]"9,0Q:+\`K@C,9WVFGBP!$1A:WX<<K^IBA+Z4
MVS[[HPE!,,0X$@=*51/;DI\!?%##8QO\JH83&0AKZ8ZOF;1%S!<<)ABC>AT'
M#U1*2JDU'H9(CBV2,9S.6=#&7)J]';;C9V0G<$=@UI]<H@S.4&<1KT6P<>[#
M5??B+::`5LOOZ0GF@78`>J$=<![H1XN#T:S7K^B7'."<0+1H9Y,!ZL\1#GYA
M#G2,6U-Z#_5B/)T9,B*NZ:(S#UOQ_'0PGG9GDR%@8"XXA+EKGJ*JO@G.@P4<
M7WG1X?RE,=RUG<ZO)H/+SN37`Z.UTW]GE(3T++\_F8PGO>I$P0B(G>OZ<-.R
MD6<LLT9@8R/YC1B-!:UH?]OI30;5`:Q1$,WZ^$S,4O"\P[FAD1;QS)HEWV2\
MGCQB.$A(Q^#ABQR-IJ$%@WC_-*)4"@25^1A4=+K=:]R_$3/0:#H8]?H?-(R$
M!GX+!G$,G>%P/.K3.)>V-8R_]"=U*!08I)P9T4-&"P9.Q2L,7/#P%?0])<=P
MG<GD5PT>Z+(8:&WCM-!E86`0XSR['HFB),`8)&]@F2CM1G`,FC?PF(>N47",
M%LD;3HGU`49&[SL1:5H+_B$M.Z@L>E.9\?J.%;J=[D5_=N%N:;#J%%V0,%-:
M$TY#YH?9I/]NZ"P?F6VS>#,1[6$;APQRI3>%,/W7_*4_K)2/PAI.M&4P)A0:
M$F(9-S]"H'N`[[J<LBW4]H`TT$_II4`S%+`5IE=:^SE+L8S/9A>3^B#$*&LD
M?-Y*['LTG5$:#Z!10>"81B,<UN]J<U#(HQE&T64@X"A/-O/7=V0%0T8]%O`'
MJ+ASR6@>^#Z6$>*A.^)1E$H9IS57X_>3'FU4T!SZ_<`X.B::.GFGMS>)IHI8
MJ,%CJNE]?1>(IEX,KNH#/[/XD_#*ZQB:K)V6@00R74:>CE'0U.[T:J9YQK:O
MI4Y\GR@&K668'LSJ*I[K"H;S0F1\-I]T1G"]C1?Y&#X:SU4%JL8OR?PL/64U
MS&5GUKU0FH#A#,9RDKJ29O`%@;_EA0S/3*JT*B>W?'F.C>XAZ/SQG&C>8]4O
M+Z&EKI-&?*='VA3<ZP>&+9%:*L5PW'.4XTFM.#@?B3>5\N:DTF--?I5L)#S2
MX*+CA>"A48NR6A(:16`'`=5CT6?">DK25I6S.>Q$Y.;T`@.M)2][75:_.7,V
M+E_29=+L!/2/VIE^48DB\!W6+OJPF$$N<>B7T0B31K4,%XVJ10P.AQ/&))60
MMCYAPN!`9.7>+@Y$U",<T+R].V#`VHYM45V[@!'J68$&ITWC=Q1!E]"`I9I7
MW3KQ-WSE<#C%WDR7$(-?Z'":]YS1<"`D%%$,K9?(,<AE)VB\SSN_,%=AD2%;
M`G*GF@9:^PS.QN_>]_J7=3%/>S(L+]+L2&NLFQ?V2$N81\3^%-NYV3B_'F(_
M8C3.*^+L,GQ/(HJ0$*TISB8F1HMB]#HDJ'*,MA9QNH8UXF8"0^!=$4RG]EP'
MGX#$FX#D%LR2.*]TA86&8=)`.XTL:N%)!`:I&/@%VO&(OV0T(!BU34X8?-IW
M9MIP]:Q[\;:N=6,-SK2%P$,-SC2*P(D^R5N^_/J:BFM$G^I;P#4\UF5`;IYQ
M#FE-Q.\4:0<`;7)Y39A<[;X-'J!8J1!T'GC8'(S(>,*#/&_#XXE-B-B.3AD.
M?'J96L#1`KK-0&Y0+V#6GJ)PU#0)1\?.D*DJ[7ADOF8/^'Q4S)`;&-W>Z5PE
M:@H#PU42(?KK;--L.'R.Z6P\Z3OFD.=>S'K&#BJJ5:;GC!B!$^LX7"=4/B0P
M,ALO@H[Y5:<G4'0'(;@@[.I)J^*SPE@0%\&2+=X]GO;/L=`Q_&)P?B'.(>:G
M`W')7G^>X1281+NRB.D40AIS>3]5USR><C)G#$@6S>(DL@)H/I(>V]0L+BEP
M,#4%NOV*KNJIW;_PDQ_4DS7\RZQS/M?@-%Z]Y:=KT\ZYX^JL.+>G35_MH+<^
M>4+^A>3UG(;9KU>5;4<V;5*-72$!?-5M1F["F54J?[OMO'LQ&CHD).`STE8F
MS^V,S?GUJ[6GZ(!44HACV=!"H3$#-.[1#`N;Q0R5F^<8ACG@9Y@$QM*&H9I3
M`J/4,?CU!D*'06D:SZ<\T5,8M"*'"T?S,)-76A1&[>VG-="F$=VW)IQXX[$)
MIS8#X8920*[IBFMS\]E9/0.]M#883^?T>472'^_T$!#@Y$I5;]!$(4CQ=(8>
MO5D2*7:[%T:.5>H81O929A1C>D[:W!RCK6.0A)ICY#J&?CFJ)(\`,02<LAKY
M#8/O?'J5><@^JUN9WO5[S$4851%G8M=%#X8@.HF$PL+`T$ZERZ6!T:7/K94E
MI:)[2J^&TT<X)A/]ZCG-XGC[FCXA&_CZ_!1.:TNQ_H!4/K$.1V*R2PD_9,PY
MU"W[5->%E6_,@?I$`H/VHD9<L]]5;4F!07,#&P8]J.Q9,(A><]B<[1:S\QI#
MJQVJ^LVV&T`$"ZE#WO`Q8QZ00.#:U6-&(&\_H]W0CU(%?!XFJ803'GN,`=S\
M%1Q@JWH_F9/VL!Z3:CC+:#_LA+=]S_1@")XE`$\<\%9BD2""IQ'`(P<\D>N'
M#GB86.QATC/X)Q*NX17_+KCBWT_M<,4_>=(5P17_]&)US^"?5!0(KOBGCTSU
M#/Y)-POS-Y!/B+KV'\&1%9W/19]BSI^F&+\'#2,/I9U#WJL*:&EE==;3ZU6)
ML\WCD,S:PJ&"SZ5?-&.@HO"JSB16PF_3.$FN-FAR1O6*J-&8A]0DB3!$\3;5
M),FT1Q[6R3O4L@:PP(.4U0B:8SYE>48VEY]K-V+EY4'1U>2\H7@B,Q3X;@A>
M('#[R`PXOW>K+8CHR>2R*TI.%"IZT':H0,^M18M=+/-E2C(XFVD[+,JK\?N1
MZ(8)9Y;&FIGC\R'G'*I`$2SI9#'YG$_&U_R&7J]?3Y%0ROGE848XTZ:IYBA$
MZJT**)E6(P7C9(_/-!$:C&G."9U:U129>RN;!IJ^J3:_1@O?F"!5&Z/II_QR
M040*__?D!Z]W]_OFYBY?EDNOR]]BDV\>O1X?MX97U_!7I:B)!B,6JOCM/F%4
M8K^X:>L&<\[-#1*NROPUYTAPAOS<02&A;5&=,:F,FHCP%+P-0;7"I!"IA&S;
.H7F#P_\?+^F)IQV\`0``
`
end

Re: Cleanup kbuild for aic7xxx

[Justin T. Gibbs]

>The existing build process for aic7xxx on Linux has several problems.
>
>* Users have to manually select "rebuild firmware".  Relying on users
>  to perform any action other than make *config is unacceptable.  It is
>  far too error prone.

Users don't have to manually select "rebuild firmware".  They can
rely on the generated files already in the aic7xxx directory.  This
is why the option defaults to off.

>* Rebuilding the firmware requires lex, yacc and libdb.  Not everybody
>  has these installed.

Then they shouldn't check the box "rebuild firmware".

>* The check for which libdb to use assumes that the presence of a db.h
>  is enough, but the overlap between glibc-devel and dbx-devel packages
>  means that finding a db.h is not enough, you have to confirm that the
>  corresponding libdb exists.

Such is Linux.  Those who understand what it means to rebuild the
firmware will have the necessary tools, check the box in config,
and have it work.

>* It checks if the firmware is up to date by comparing the timestamps
>  on aic7xxx_seq.h and aic7xxx_reg.h against aic7xxx.seq and
>  aic7xxx.reg.  Alas, when a patch hits those files there is no
>  guarantee which order the files are listed in the patch so the final
>  timestamp order is unreliable.  diff lists files in alphabetical
>  order but other source repository systems can generate patches in any
>  order.  This is a problem for all generated files, not just aic7xxx.

So you might get a harmless warning if you haven't checked the box.  This
is not fatal and I have yet to hear one complaint about it.

>* Shipping files which are also overwritten by users causes problems
>  for source control systems and can cause spurious differences when
>  generating patches.  This is a problem for all generated files, not
>  just aic7xxx.

Those using revision control should know how to use revision control.
The driver is developed under revision control and the current setup
causes me no grief.  Of course, I don't keep the generated files in
revision control because there is no benefit in doing so.  For those
that decide to keep the generated files in revision control, they
should pull any update to the generated files from the vendor (they
are always provided in my patches) and *never check the box*.

>The patch below fixes all of the above issues.  It does not touch the
>aic7xxx code nor sequencer input, just the generated files and the
>kbuild related files.  The patch is approx 100Kb but most of it is the
>rename of aic7xxx_{seq,reg}.h to aic7xxx_{seq,reg}.h_shipped.

I don't see this as an improvement.

>After applying this patch, normal users will not have to worry about
>generating aic7xxx firmware.

This is already true today.

>In particular they will not have to
>select "rebuild firmware" nor will they need lex, yacc or libdb.

Already true today.

>Only people who change one of these files

Today, this only applies to those that *check the rebuild firmware*
box.

What again are you trying to fix?  It looks to me like you are simply
trying to make it harder for people actually working on the aic7xxx
driver to have proper dependencies.

--
Justin

Re: Cleanup kbuild for aic7xxx

[Keith Owens]

On Fri, 22 Jun 2001 13:39:45 -0600, 
"Justin T. Gibbs" <gibbs@scsiguy.com> wrote:
>>The existing build process for aic7xxx on Linux has several problems.
>>
>>* Users have to manually select "rebuild firmware".  Relying on users
>>  to perform any action other than make *config is unacceptable.  It is
>>  far too error prone.
>
>Users don't have to manually select "rebuild firmware".  They can
>rely on the generated files already in the aic7xxx directory.  This
>is why the option defaults to off.

You rely on a timestamp check to tell the users "suggest you rebuild
firmware".  That timestamp check is inherently unreliable when files
are both generated and shipped.

>>* Rebuilding the firmware requires lex, yacc and libdb.  Not everybody
>>  has these installed.
>
>Then they shouldn't check the box "rebuild firmware".

See above.  Users think they need to turn on the firmware build, then
complain when it breaks.

>>* The check for which libdb to use assumes that the presence of a db.h
>>  is enough, but the overlap between glibc-devel and dbx-devel packages
>>  means that finding a db.h is not enough, you have to confirm that the
>>  corresponding libdb exists.
>
>Such is Linux.  Those who understand what it means to rebuild the
>firmware will have the necessary tools, check the box in config,
>and have it work.

Wrong.  Such is the way it _used_ to be.  As the use of Linux expands,
more and more people are building their own kernels without knowing all
the internals.  This is good, we get more users.  But kernel build code
can no longer assume that anybody building a kernel is automatically an
expert.

>>* It checks if the firmware is up to date by comparing the timestamps
>>  on aic7xxx_seq.h and aic7xxx_reg.h against aic7xxx.seq and
>>  aic7xxx.reg.  Alas, when a patch hits those files there is no
>>  guarantee which order the files are listed in the patch so the final
>>  timestamp order is unreliable.  diff lists files in alphabetical
>>  order but other source repository systems can generate patches in any
>>  order.  This is a problem for all generated files, not just aic7xxx.
>
>So you might get a harmless warning if you haven't checked the box.  This
>is not fatal and I have yet to hear one complaint about it.

http://marc.theaimsgroup.com/?l=linux-kernel&m=99124017310488&w=2
was fatal, you even replied to it.

>>* Shipping files which are also overwritten by users causes problems
>>  for source control systems and can cause spurious differences when
>>  generating patches.  This is a problem for all generated files, not
>>  just aic7xxx.
>
>Those using revision control should know how to use revision control.
>The driver is developed under revision control and the current setup
>causes me no grief.  Of course, I don't keep the generated files in
>revision control because there is no benefit in doing so.

Users take patches from Linus or Alan Cox which include the generated
patches and add the patches to local source repositories.  That
includes the generated files.  If it comes from Linus or AC it is a
"master" copy.  End users do not have the luxury of excluding the
generated files from revision control because it is not their input.
And if they do exclude the files then their users are forced to
generate the firmware.  Excluding the aic7xxx generated files from
source revision works for you because you always generate the firmware,
it does not work for anybody else.

>For those
>that decide to keep the generated files in revision control, they
>should pull any update to the generated files from the vendor (they
>are always provided in my patches) and *never check the box*.

Users must not be forced to go hunting for files from a vendor when the
rst of the code is in the kernel.  Especially when that vendor is not
listed in MAINTAINERS and there is no contact data in the aic7xxx
directory.

>>The patch below fixes all of the above issues.  It does not touch the
>>aic7xxx code nor sequencer input, just the generated files and the
>>kbuild related files.  The patch is approx 100Kb but most of it is the
>>rename of aic7xxx_{seq,reg}.h to aic7xxx_{seq,reg}.h_shipped.
>
>I don't see this as an improvement.

I do, and I am the kernel build maintainer.  I don't tell you how to
code aic7xxx drivers, but I can and will fix kbuild problems.  The
current aic7xxx kbuild is a problem.

>>After applying this patch, normal users will not have to worry about
>>generating aic7xxx firmware.
>
>This is already true today.

Not true, the timestamp check produces spurious prompts.

>>In particular they will not have to
>>select "rebuild firmware" nor will they need lex, yacc or libdb.
>
>Already true today.

Wrong.  See
http://marc.theaimsgroup.com/?l=linux-kernel&m=99323170127833&w=2

>>Only people who change one of these files
>
>Today, this only applies to those that *check the rebuild firmware*
>box.

Which the broken timestamp check encourages people to do.

>What again are you trying to fix?  It looks to me like you are simply
>trying to make it harder for people actually working on the aic7xxx
>driver to have proper dependencies.

The patch still works for anybody changing the aic7xxx firmware or the
aicasm code.  Any change to the generated files or the aicasm files now
forces a rebuild, the option is not required.  Only people changing
aic7xxx firmware are affected, instead of everybody.

Bottom line: the current method relies on unreliable timestamps,
produces spurious warning messages and causes problems for everybody
using source control except for you.  The new method is clean.  And as
kbuild maintainer, that is the way I want it to be done.

Re: Cleanup kbuild for aic7xxx

[J . A . Magallon]

On 20010623 Keith Owens wrote:
>
>>What again are you trying to fix?  It looks to me like you are simply
>>trying to make it harder for people actually working on the aic7xxx
>>driver to have proper dependencies.
>
>The patch still works for anybody changing the aic7xxx firmware or the
>aicasm code.  Any change to the generated files or the aicasm files now
>forces a rebuild, the option is not required.  Only people changing
>aic7xxx firmware are affected, instead of everybody.
>

It is easier than that. Nobody should be rebuilding the firmware apart
from driver mantainers. If driver version in 2.4.5 is 6.1.13, that version
includes a certain firmware in .h format and that is all. Apart from
this, the author (Justin) can make available in his web page one other
package for driver testers or developers including aicasm and firmware
source. But that should not be in the kernel tree.
If there are updates to the firmware, just send the patch for .h files
to kernel mantainers and/or lkml, as everybody does.

This is easier, doesn't it ?

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac17 #2 SMP Fri Jun 22 01:36:07 CEST 2001 i686

Re: Cleanup kbuild for aic7xxx

[David Ford]

Well let me put it this way, I have in no way selected 'rebuild 
firmware' and several of my freshly untarred/patched to kernels are 
broken in that they won't compile, why?  lex not found.

Currently I'm pretty bothered because for any of numerous reasons now, I 
can't get the blasted aic7xxx support in any 2.4 kernel to work.  I'm a 
little tweaked because my distro is based on 2.4 functionality and I'm 
stuck on square 0 just trying to boot.

Several people have made reports about 2.4 and aic7xxx wrt to OOPSes, 
failure to boot, and hanging and there's very little response to this. 
 To this point I have two machines stuck in 2.2 which desperately need 
upgraded but I can't upgrade the kernel because the aic code is tragic.

Pardon my frustration,
David

[much snippage]

Re: Cleanup kbuild for aic7xxx

[Keith Owens]

On Sat, 23 Jun 2001 03:20:47 +0200, 
"J . A . Magallon" <jamagallon@able.es> wrote:
>On 20010623 Keith Owens wrote:
>>Justin Gibbs wrote
>>
>>>What again are you trying to fix?  It looks to me like you are simply
>>>trying to make it harder for people actually working on the aic7xxx
>>>driver to have proper dependencies.
>>
>>The patch still works for anybody changing the aic7xxx firmware or the
>>aicasm code.  Any change to the generated files or the aicasm files now
>>forces a rebuild, the option is not required.  Only people changing
>>aic7xxx firmware are affected, instead of everybody.
>
>It is easier than that. Nobody should be rebuilding the firmware apart
>from driver mantainers ...
>If there are updates to the firmware, just send the patch for .h files
>to kernel mantainers and/or lkml, as everybody does.
>This is easier, doesn't it ?

Much easier but

(a) against the spirit of the GPL, no source code to generate the headers
(b) it makes it harder for people other than Justin to work on the
    firmware.

IMNSHO the kernel should not contain generated files without the
support to regenerate them.  If that means a little more work for the
kbuild maintainers then so be it, I have done that extra work.

Re: Cleanup kbuild for aic7xxx

[Justin T. Gibbs]

>On Fri, 22 Jun 2001 13:39:45 -0600, 
>"Justin T. Gibbs" <gibbs@scsiguy.com> wrote:
>>>The existing build process for aic7xxx on Linux has several problems.
>>>
>>>* Users have to manually select "rebuild firmware".  Relying on users
>>>  to perform any action other than make *config is unacceptable.  It is
>>>  far too error prone.
>>
>>Users don't have to manually select "rebuild firmware".  They can
>>rely on the generated files already in the aic7xxx directory.  This
>>is why the option defaults to off.
>
>You rely on a timestamp check to tell the users "suggest you rebuild
>firmware".  That timestamp check is inherently unreliable when files
>are both generated and shipped.

Files are only shipped unless the user decides to build the firmware.
When I send patches to distributers or Linus, or Alan, the firmware
is always "shipped" from me the vendor.

>>>* Rebuilding the firmware requires lex, yacc and libdb.  Not everybody
>>>  has these installed.
>>
>>Then they shouldn't check the box "rebuild firmware".
>
>See above.  Users think they need to turn on the firmware build, then
>complain when it breaks.

Then kill the warning.  As you note below, most people ignore it even
when it properly indicates pilot error.

>>>* The check for which libdb to use assumes that the presence of a db.h
>>>  is enough, but the overlap between glibc-devel and dbx-devel packages
>>>  means that finding a db.h is not enough, you have to confirm that the
>>>  corresponding libdb exists.
>>
>>Such is Linux.  Those who understand what it means to rebuild the
>>firmware will have the necessary tools, check the box in config,
>>and have it work.
>
>Wrong.  Such is the way it _used_ to be.  As the use of Linux expands,
>more and more people are building their own kernels without knowing all
>the internals.  This is good, we get more users.  But kernel build code
>can no longer assume that anybody building a kernel is automatically an
>expert.

I disagree.  Users that don't understand about patches and build
dependencies should either rely on prebuilt binaries, or be willing
to learn as they experiment with their system.  I spend enough of my
time dealing with people who don't understand SCSI concepts such
as termination to not have any spare to explain to them why their
distribution is deficient or what a patch file does.

>>>* It checks if the firmware is up to date by comparing the timestamps
>>>  on aic7xxx_seq.h and aic7xxx_reg.h against aic7xxx.seq and
>>>  aic7xxx.reg.  Alas, when a patch hits those files there is no
>>>  guarantee which order the files are listed in the patch so the final
>>>  timestamp order is unreliable.  diff lists files in alphabetical
>>>  order but other source repository systems can generate patches in any
>>>  order.  This is a problem for all generated files, not just aic7xxx.
>>
>>So you might get a harmless warning if you haven't checked the box.  This
>>is not fatal and I have yet to hear one complaint about it.
>
>http://marc.theaimsgroup.com/?l=linux-kernel&m=99124017310488&w=2
>was fatal, you even replied to it.

And this particular problem was pilot error (improperly patched or
corrupted system).  Tell me again how your scheme deals with that?

>>>* Shipping files which are also overwritten by users causes problems
>>>  for source control systems and can cause spurious differences when
>>>  generating patches.  This is a problem for all generated files, not
>>>  just aic7xxx.
>>
>>Those using revision control should know how to use revision control.
>>The driver is developed under revision control and the current setup
>>causes me no grief.  Of course, I don't keep the generated files in
>>revision control because there is no benefit in doing so.
>
>Users take patches from Linus or Alan Cox which include the generated
>patches and add the patches to local source repositories.  That
>includes the generated files.  If it comes from Linus or AC it is a
>"master" copy.  End users do not have the luxury of excluding the
>generated files from revision control because it is not their input.
>And if they do exclude the files then their users are forced to
>generate the firmware.  Excluding the aic7xxx generated files from
>source revision works for you because you always generate the firmware,
>it does not work for anybody else.
>
>>For those
>>that decide to keep the generated files in revision control, they
>>should pull any update to the generated files from the vendor (they
>>are always provided in my patches) and *never check the box*.
>
>Users must not be forced to go hunting for files from a vendor when the
>rst of the code is in the kernel.  Especially when that vendor is not
>listed in MAINTAINERS and there is no contact data in the aic7xxx
>directory.

You seem to completely misunderstand what I said above.  Either you
decide to take the generated firmware, included in both the AC and
Linus kernels, as is, or you are a developer that wants to regenerate
it.  In the first case, you treat the generated files like any other.
In the later, as a developer, you may or may not exclude the files
from revision control depending on what works for you.  My assumption
is that 99% of the people using Linux will never want to hack
the firmware or rebuild it.  They can put the generated files in revision
control and never know the difference.

My comment above about getting the firmware from the vendor applies to
people like Alan, Linus, Red Hat, SuSE, and anyone else that chooses to
update the driver by pulling it from my site.  I am the vendor.

>>>The patch below fixes all of the above issues.  It does not touch the
>>>aic7xxx code nor sequencer input, just the generated files and the
>>>kbuild related files.  The patch is approx 100Kb but most of it is the
>>>rename of aic7xxx_{seq,reg}.h to aic7xxx_{seq,reg}.h_shipped.
>>
>>I don't see this as an improvement.
>
>I do, and I am the kernel build maintainer.  I don't tell you how to
>code aic7xxx drivers, but I can and will fix kbuild problems.  The
>current aic7xxx kbuild is a problem.

How is it a problem?  Remove the dependency checks from the current
setup (i.e. can never give a warning unless you check the box) and you
have the *exact same thing*.  All you have done additionally is move
the generated file to another name and obfuscated how to build the
firmware.

>>>After applying this patch, normal users will not have to worry about
>>>generating aic7xxx firmware.
>>
>>This is already true today.
>
>Not true, the timestamp check produces spurious prompts.

Then remove them.

>>>In particular they will not have to
>>>select "rebuild firmware" nor will they need lex, yacc or libdb.
>>
>>Already true today.
>
>Wrong.  See
>http://marc.theaimsgroup.com/?l=linux-kernel&m=99323170127833&w=2

An improperly patched kernel will not function for any of a number
of reasons.  This was no different.  The file is, after all, just
a header file and a header file out of sync with the code that depends
on it can be fatal.

>>>Only people who change one of these files
>>
>>Today, this only applies to those that *check the rebuild firmware*
>>box.
>
>Which the broken timestamp check encourages people to do.

Remove the check.

>>What again are you trying to fix?  It looks to me like you are simply
>>trying to make it harder for people actually working on the aic7xxx
>>driver to have proper dependencies.
>
>The patch still works for anybody changing the aic7xxx firmware or the
>aicasm code.

No, it removes the ability to include dependency checks to build the
firmware in a standard build.  No longer can a developer check the
box in their config, forget about it, and merily go on doing a straight
build from the top level.  They now have to either remember the new
manual step, or add their own script or alias to remember it for them.
If the build system is going to support the firmware at all, it should
do it in a documented and easy to find way.

>Any change to the generated files or the aicasm files now
>forces a rebuild, the option is not required.  Only people changing
>aic7xxx firmware are affected, instead of everybody.

What about a change to the firmware source?  This changes much more
rapidly than the tools that build it and who would manually touch the
generated file other than to perform a vendor update?  This makes the
dependencies that you leave intact useless.

>Bottom line: the current method relies on unreliable timestamps,

Only in the case of generating a warning.  I have no problem with
simply removing all dependency checks unless you check the rebuild
firmware box.

>The new method is clean.

Its your code and your idea.  Of course it's clean.

>And as kbuild maintainer, that is the way I want it to be done.

Well, if nothing about the build is open for discussion, you should
have just said so up front.  I wouldn't have wasted so much time
responding to you.

--
Justin

Re: Cleanup kbuild for aic7xxx

[Justin T. Gibbs]

>It is easier than that. Nobody should be rebuilding the firmware apart
>from driver mantainers.

The aic7xxx driver used to be this way.  It hid the fact that the
aic7xxx driver was completely open source and that anyone could
take the code, improve it, or build custom behavior from it.  Firmware
tweaks are often the only way to achieve certain behavior.  For
example, a real time system may want to embed certain types of
recovery behavior in the firmware to reduce recovery latencies.
The power of Linux and OpenSource systems in is that everything
is provided so you can make the system what you need, not what
was spoon fed to you.

--
Justin

Re: Cleanup kbuild for aic7xxx

[Justin T. Gibbs]

>Well let me put it this way, I have in no way selected 'rebuild 
>firmware' and several of my freshly untarred/patched to kernels are 
>broken in that they won't compile, why?  lex not found.

Prior to Linus' 2.4.5 release, aic7xxx version 6.1.5 was embedded
in the kernel.  Although corrected almost immediately after its release,
this version attempted to build the firmware at all times.  Although
a lofty goal from an aesthetic standpoint (why should you have generated
files when you have all the source to build them?), it simply doesn't
work on the miriad of distributions out there.   It took a while
for Linus to pick up the change that added the "rebuild firmware"
config option, so you may have a kernel that still has this broken
behavior.  Updates to most recent kernels to the latest aic7xxx driver
can be found here:

http://people.FreeBSD.org/~gibbs/linux/

>Currently I'm pretty bothered because for any of numerous reasons now, I 
>can't get the blasted aic7xxx support in any 2.4 kernel to work.  I'm a 
>little tweaked because my distro is based on 2.4 functionality and I'm 
>stuck on square 0 just trying to boot.

You could always choose to use the older aic7xxx driver.  To this day,
it is still available in the 2.4.X kernels.  I don't have enough details
about your particular problems to know if this will help your situation.

>Several people have made reports about 2.4 and aic7xxx wrt to OOPSes, 
>failure to boot, and hanging and there's very little response to this. 

Perhaps I've missed the reports then.  I've made every effort to repond
to the reports that I've seen, have worked to correct those issues,
and expect to release 6.1.14 early next week.  Unfortunately even
working for Adaptec, our testing resources (number/type of machines)
are limited, so there will always be some bugs left for the userbase
to find.

> To this point I have two machines stuck in 2.2 which desperately need 
>upgraded but I can't upgrade the kernel because the aic code is tragic.
>
>Pardon my frustration,
>David

Can you provide information about your system and how it fails?  I will
need to know driver revision, type of card, and any messages you can
copy down during a failure with "aic7xxx=verbose" set either in LILO
for a statically compiled driver or used when loading the module.  A
dmesg from a system booted with the 2.2 kernel should give me most of
the system information I need.

--
Justin

Re: Cleanup kbuild for aic7xxx

[David Ford]

I am mixed between packing to move to the east coast right now but I 
will definitely be providing you some information.  I have to get this 
system up and running inside the next four days.  I realize this is a 
bit rude/forward of me, but I would greatly appreciate your help and 
please tolerate my rushedness :)

Justin T. Gibbs wrote:

>>Well let me put it this way, I have in no way selected 'rebuild 
>>firmware' and several of my freshly untarred/patched to kernels are 
>>broken in that they won't compile, why?  lex not found.
>>
>
>Prior to Linus' 2.4.5 release, aic7xxx version 6.1.5 was embedded
>in the kernel.  Although corrected almost immediately after its release,
>this version attempted to build the firmware at all times.  Although
>a lofty goal from an aesthetic standpoint (why should you have generated
>files when you have all the source to build them?), it simply doesn't
>work on the miriad of distributions out there.   It took a while
>for Linus to pick up the change that added the "rebuild firmware"
>config option, so you may have a kernel that still has this broken
>behavior.  Updates to most recent kernels to the latest aic7xxx driver
>can be found here:
>
>http://people.FreeBSD.org/~gibbs/linux/
>

I agree with the above except for the usage of external library headers 
such as db.h.  I tried numerous sleepycat builds but they all returned 
errors with the particular db.h.

I will shortly visit that URL and see what I can do.

>>Currently I'm pretty bothered because for any of numerous reasons now, I 
>>can't get the blasted aic7xxx support in any 2.4 kernel to work.  I'm a 
>>little tweaked because my distro is based on 2.4 functionality and I'm 
>>stuck on square 0 just trying to boot.
>>
>
>You could always choose to use the older aic7xxx driver.  To this day,
>it is still available in the 2.4.X kernels.  I don't have enough details
>about your particular problems to know if this will help your situation.
>

How does one go about choosing the older driver?  I didn't see a config 
option for it.

>>Several people have made reports about 2.4 and aic7xxx wrt to OOPSes, 
>>failure to boot, and hanging and there's very little response to this. 
>>
>
>Perhaps I've missed the reports then.  I've made every effort to repond
>to the reports that I've seen, have worked to correct those issues,
>and expect to release 6.1.14 early next week.  Unfortunately even
>working for Adaptec, our testing resources (number/type of machines)
>are limited, so there will always be some bugs left for the userbase
>to find.
>

Understandable.

>>To this point I have two machines stuck in 2.2 which desperately need 
>>upgraded but I can't upgrade the kernel because the aic code is tragic.
>>
>>Pardon my frustration,
>>David
>>
>
>Can you provide information about your system and how it fails?  I will
>need to know driver revision, type of card, and any messages you can
>copy down during a failure with "aic7xxx=verbose" set either in LILO
>for a statically compiled driver or used when loading the module.  A
>dmesg from a system booted with the 2.2 kernel should give me most of
>the system information I need.
>

I will dig out a serial cable and update the boot floppy I'm using.  Do 
you suggest I start these proceedings again with a 2.4.5+ kernel?  What 
is your recommendation on this, -preN or -acN etc?  I'll build a 2.2 and 
log the info.

David

Re: Cleanup kbuild for aic7xxx

[Justin T. Gibbs]

>I am mixed between packing to move to the east coast right now but I 
>will definitely be providing you some information.  I have to get this 
>system up and running inside the next four days.  I realize this is a 
>bit rude/forward of me, but I would greatly appreciate your help and 
>please tolerate my rushedness :)

Everyone gets frustrated when their system doesn't work.  I even
get frustrated when those using my driver have systems that don't
work. 8-)

>>Prior to Linus' 2.4.5 release, aic7xxx version 6.1.5 was embedded
>>in the kernel.  Although corrected almost immediately after its release,
>>this version attempted to build the firmware at all times.  Although
>>a lofty goal from an aesthetic standpoint (why should you have generated
>>files when you have all the source to build them?), it simply doesn't
>>work on the miriad of distributions out there.   It took a while
>>for Linus to pick up the change that added the "rebuild firmware"
>>config option, so you may have a kernel that still has this broken
>>behavior.  Updates to most recent kernels to the latest aic7xxx driver
>>can be found here:
>>
>>http://people.FreeBSD.org/~gibbs/linux/
>>
>
>I agree with the above except for the usage of external library headers 
>such as db.h.  I tried numerous sleepycat builds but they all returned 
>errors with the particular db.h.

The assembler is a userland utility, so it relies on userland headers.
In systems where the kernel and userland are maintained by the same
people, this isn't much of a problem.  However, Linux doesn't work this
way.

Hopefully you will never have to rebuild the firmware manually.

>>You could always choose to use the older aic7xxx driver.  To this day,
>>it is still available in the 2.4.X kernels.  I don't have enough details
>>about your particular problems to know if this will help your situation.
>>
>
>How does one go about choosing the older driver?  I didn't see a config 
>option for it.

In the SCSI driver's section, there should be two drivers listed.  Perhaps
your distro chose to change that, but at least SuSE and Red Hat have kept
to this policy.

>>Can you provide information about your system and how it fails?  I will
>>need to know driver revision, type of card, and any messages you can
>>copy down during a failure with "aic7xxx=verbose" set either in LILO
>>for a statically compiled driver or used when loading the module.  A
>>dmesg from a system booted with the 2.2 kernel should give me most of
>>the system information I need.
>>
>
>I will dig out a serial cable and update the boot floppy I'm using.  Do 
>you suggest I start these proceedings again with a 2.4.5+ kernel?  What 
>is your recommendation on this, -preN or -acN etc?  I'll build a 2.2 and 
>log the info.

I don't usually keep up with the various "pre" or "ac" kernels, so I
can't give you pointers about which ones are more stable, etc.  As
far as the aic7xxx driver is concerned, they should all work the same.
I primarally provide patches for release kernels, so that may limit
what kernels you can use to get up to the latest aic7xxx driver.

--
Justin

Re: Cleanup kbuild for aic7xxx

[David Ford]

>
>
>I don't usually keep up with the various "pre" or "ac" kernels, so I
>can't give you pointers about which ones are more stable, etc.  As
>far as the aic7xxx driver is concerned, they should all work the same.
>I primarally provide patches for release kernels, so that may limit
>what kernels you can use to get up to the latest aic7xxx driver.
>

Ok, here's the relevant output from 2.2.19.  In future emails, would 
like all the information posted to the list or would you like URLs to 
the text docs?

Linux version 2.2.19 (root@James) (gcc version 2.95.3 20010315 
(release)) #1 Fri
 Jun 22 20:17:08 PDT 2001
...
(scsi0) <Adaptec AIC-7896/7 Ultra2 SCSI host adapter> found at PCI 0/12/1
(scsi0) Wide Channel B, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 393 instructions downloaded
(scsi1) <Adaptec AIC-7896/7 Ultra2 SCSI host adapter> found at PCI 0/12/0
(scsi1) Wide Channel A, SCSI ID=7, 32/255 SCBs
(scsi1) Downloading sequencer code... 393 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.33/3.2.4
       <Adaptec AIC-7896/7 Ultra2 SCSI host adapter>
scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.33/3.2.4
       <Adaptec AIC-7896/7 Ultra2 SCSI host adapter>
scsi : 2 hosts.
  Vendor: SEAGATE   Model: ST318436LW        Rev: 0005
  Type:   Direct-Access                      ANSI SCSI revision: 03
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
(scsi0:0:0:2) Synchronous at 40.0 Mbyte/sec, offset 31.
scsi : detected 1 SCSI generic 1 SCSI disk total.
SCSI device sda: hdwr sector= 512 bytes. Sectors= 35885168 [17522 MB] 
[17.5 GB]


David

Re: Cleanup kbuild for aic7xxx

[D. Stimits]

Keith Owens wrote:
> 
> On Fri, 22 Jun 2001 13:39:45 -0600,
> "Justin T. Gibbs" <gibbs@scsiguy.com> wrote:
> >>The existing build process for aic7xxx on Linux has several problems.
> >>
> >>* Users have to manually select "rebuild firmware".  Relying on users
> >>  to perform any action other than make *config is unacceptable.  It is
> >>  far too error prone.
> >
> >Users don't have to manually select "rebuild firmware".  They can
> >rely on the generated files already in the aic7xxx directory.  This
> >is why the option defaults to off.

For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have
had to manually select this for a 7892 controller. Without manually
selecting it, it guarantees boot failure. I don't know if this is due to
the SGI modifications or not. The real problem I found is that during
boot failure, there was no meaningful debug message.

> 
> You rely on a timestamp check to tell the users "suggest you rebuild
> firmware".  That timestamp check is inherently unreliable when files
> are both generated and shipped.
> 
> >>* Rebuilding the firmware requires lex, yacc and libdb.  Not everybody
> >>  has these installed.
> >
> >Then they shouldn't check the box "rebuild firmware".
> 
> See above.  Users think they need to turn on the firmware build, then
> complain when it breaks.
> 
> >>* The check for which libdb to use assumes that the presence of a db.h
> >>  is enough, but the overlap between glibc-devel and dbx-devel packages
> >>  means that finding a db.h is not enough, you have to confirm that the
> >>  corresponding libdb exists.
> >
> >Such is Linux.  Those who understand what it means to rebuild the
> >firmware will have the necessary tools, check the box in config,
> >and have it work.

But there is insufficient menu dialog associated with rebuild firmware.

> 
> Wrong.  Such is the way it _used_ to be.  As the use of Linux expands,
> more and more people are building their own kernels without knowing all
> the internals.  This is good, we get more users.  But kernel build code
> can no longer assume that anybody building a kernel is automatically an
> expert.
> 
> >>* It checks if the firmware is up to date by comparing the timestamps
> >>  on aic7xxx_seq.h and aic7xxx_reg.h against aic7xxx.seq and
> >>  aic7xxx.reg.  Alas, when a patch hits those files there is no
> >>  guarantee which order the files are listed in the patch so the final
> >>  timestamp order is unreliable.  diff lists files in alphabetical
> >>  order but other source repository systems can generate patches in any
> >>  order.  This is a problem for all generated files, not just aic7xxx.
> >
> >So you might get a harmless warning if you haven't checked the box.  This
> >is not fatal and I have yet to hear one complaint about it.

Missing firmware rebuild is fatal for my system, SMP x86 with integrated
7892. Messages and config menu information is inadequate, it requires a
bit of pounding the head on the wall to figure it out.

> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=99124017310488&w=2
> was fatal, you even replied to it.
> 
> >>* Shipping files which are also overwritten by users causes problems
> >>  for source control systems and can cause spurious differences when
> >>  generating patches.  This is a problem for all generated files, not
> >>  just aic7xxx.
> >
> >Those using revision control should know how to use revision control.
> >The driver is developed under revision control and the current setup
> >causes me no grief.  Of course, I don't keep the generated files in
> >revision control because there is no benefit in doing so.
> 
> Users take patches from Linus or Alan Cox which include the generated
> patches and add the patches to local source repositories.  That
> includes the generated files.  If it comes from Linus or AC it is a
> "master" copy.  End users do not have the luxury of excluding the
> generated files from revision control because it is not their input.
> And if they do exclude the files then their users are forced to
> generate the firmware.  Excluding the aic7xxx generated files from
> source revision works for you because you always generate the firmware,
> it does not work for anybody else.
> 
> >For those
> >that decide to keep the generated files in revision control, they
> >should pull any update to the generated files from the vendor (they
> >are always provided in my patches) and *never check the box*.
> 
> Users must not be forced to go hunting for files from a vendor when the
> rst of the code is in the kernel.  Especially when that vendor is not
> listed in MAINTAINERS and there is no contact data in the aic7xxx
> directory.
> 
> >>The patch below fixes all of the above issues.  It does not touch the
> >>aic7xxx code nor sequencer input, just the generated files and the
> >>kbuild related files.  The patch is approx 100Kb but most of it is the
> >>rename of aic7xxx_{seq,reg}.h to aic7xxx_{seq,reg}.h_shipped.
> >
> >I don't see this as an improvement.
> 
> I do, and I am the kernel build maintainer.  I don't tell you how to
> code aic7xxx drivers, but I can and will fix kbuild problems.  The
> current aic7xxx kbuild is a problem.
> 
> >>After applying this patch, normal users will not have to worry about
> >>generating aic7xxx firmware.
> >
> >This is already true today.
> 
> Not true, the timestamp check produces spurious prompts.
> 
> >>In particular they will not have to
> >>select "rebuild firmware" nor will they need lex, yacc or libdb.
> >
> >Already true today.
> 
> Wrong.  See
> http://marc.theaimsgroup.com/?l=linux-kernel&m=99323170127833&w=2
> 
> >>Only people who change one of these files
> >
> >Today, this only applies to those that *check the rebuild firmware*
> >box.
> 
> Which the broken timestamp check encourages people to do.
> 
> >What again are you trying to fix?  It looks to me like you are simply
> >trying to make it harder for people actually working on the aic7xxx
> >driver to have proper dependencies.
> 
> The patch still works for anybody changing the aic7xxx firmware or the
> aicasm code.  Any change to the generated files or the aicasm files now
> forces a rebuild, the option is not required.  Only people changing
> aic7xxx firmware are affected, instead of everybody.
> 
> Bottom line: the current method relies on unreliable timestamps,
> produces spurious warning messages and causes problems for everybody
> using source control except for you.  The new method is clean.  And as
> kbuild maintainer, that is the way I want it to be done.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Cleanup kbuild for aic7xxx

[D. Stimits]

"J . A . Magallon" wrote:
> 
> On 20010623 Keith Owens wrote:
> >
> >>What again are you trying to fix?  It looks to me like you are simply
> >>trying to make it harder for people actually working on the aic7xxx
> >>driver to have proper dependencies.
> >
> >The patch still works for anybody changing the aic7xxx firmware or the
> >aicasm code.  Any change to the generated files or the aicasm files now
> >forces a rebuild, the option is not required.  Only people changing
> >aic7xxx firmware are affected, instead of everybody.
> >
> 
> It is easier than that. Nobody should be rebuilding the firmware apart
> from driver mantainers. If driver version in 2.4.5 is 6.1.13, that version
> includes a certain firmware in .h format and that is all. Apart from
> this, the author (Justin) can make available in his web page one other
> package for driver testers or developers including aicasm and firmware
> source. But that should not be in the kernel tree.
> If there are updates to the firmware, just send the patch for .h files
> to kernel mantainers and/or lkml, as everybody does.
> 
> This is easier, doesn't it ?

It would cause problems for me. Perhaps it is an issue of XFS filesystem
patches, rather than the regular kernel, I don't know what it modifies
relative to aic7xxx. But so far all of my recent test kernels will fail
to complete boot correctly if rebuild firmware is not used.

D. Stimits, stimits@idcomm.com

> 
> --
> J.A. Magallon                           #  Let the source be with you...
> mailto:jamagallon@able.es
> Mandrake Linux release 8.1 (Cooker) for i586
> Linux werewolf 2.4.5-ac17 #2 SMP Fri Jun 22 01:36:07 CEST 2001 i686
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Cleanup kbuild for aic7xxx

[David Ford]

Here is the output of a plain jane 2.4.5 compile with the 'new' adaptec 
compiled in:

Linux version 2.4.5 (root@James) (gcc version 2.95.3 20010315 (release)) 
#3 Fri
Jun 22 21:23:04 PDT 2001
...
Kernel command line: BOOT_IMAGE=test ro root=801 BOOT_FILE=/boot/test 
aic7xxx=verbose nmi_watchdog=1 console=ttyS0,38400 console=tty0 
serial=0,38400n8
...
ahc_pci:0:12:0: Reading SEEPROM...done.
ahc_pci:0:12:0: Manual LVD Termination
ahc_pci:0:12:0: BIOS eeprom not present
ahc_pci:0:12:0: Secondary High byte termination Enabled
ahc_pci:0:12:0: Primary Low Byte termination Enabled
ahc_pci:0:12:0: Primary High Byte termination Enabled
ahc_pci:0:12:0: Downloading Sequencer Program... 416 instructions downloaded
PCI: Found IRQ 10 for device 00:0c.1
PCI: The same IRQ used for device 00:0c.0
ahc_pci:0:12:1: Reading SEEPROM...done.
ahc_pci:0:12:1: Manual LVD Termination
ahc_pci:0:12:1: BIOS eeprom not present
ahc_pci:0:12:1: Secondary High byte termination Enabled
ahc_pci:0:12:1: Primary Low Byte termination Enabled
ahc_pci:0:12:1: Primary High Byte termination Enabled
ahc_pci:0:12:1: Downloading Sequencer Program... 416 instructions downloaded
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13
        <Adaptec aic7896/97 Ultra2 SCSI adapter>
        aic7896/97: Ultra2 Wide Channel B, SCSI Id=7, 32/255 SCBs

scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13
        <Adaptec aic7896/97 Ultra2 SCSI adapter>
        aic7896/97: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs

Now it breaks

scsi0:0:0:0: Attempting to queue an ABORT message
scsi0: Dumping Card State while idle, at SEQADDR 0x8
SCSISEQ = 0x12, SBLKCTL = 0x6
 DFCNTRL = 0x0, DFSTATUS = 0x89
LASTPHASE = 0x1, SCSISIGI = 0x0, SXFRCTL0 = 0x80
SSTAT0 = 0x0, SSTAT1 = 0xa
STACK == 0x3, 0x108, 0x15f, 0x0
SCB count = 4
Kernel NEXTQSCB = 2
Card NEXTQSCB = 2
QINFIFO entries:
Waiting Queue entries:
Disconnected Queue entries:
QOUTFIFO entries:
Sequencer Free SCB List: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 
19 20 21 22 23 24 25 26 27 28 29 30 31
Pending list:
Kernel Free SCB list: 3 1 0
DevQ(0:0:0): 0 waiting
scsi0:0:0:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:0:0: Attempting to queue an ABORT message
(scsi0:A:0:0): Sending PPR bus_width 1, period c, offset 7f, ppr_options 0
scsi0: Dumping Card State in Message-out phase, at SEQADDR 0x168
SCSISEQ = 0x12, SBLKCTL = 0x6
 DFCNTRL = 0x0, DFSTATUS = 0x89
LASTPHASE = 0xa0, SCSISIGI = 0xb6, SXFRCTL0 = 0x88
SSTAT0 = 0x2, SSTAT1 = 0x3
STACK == 0x175, 0x15f, 0x0, 0xe7
SCB count = 4
Kernel NEXTQSCB = 3
Card NEXTQSCB = 3
QINFIFO entries:
Waiting Queue entries:
Disconnected Queue entries:
QOUTFIFO entries:
Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 
20 21 22 23 24 25 26 27 28 29 30 31
Pending list: 2
Kernel Free SCB list: 1 0
Untagged Q(0): 2
DevQ(0:0:0): 0 waiting
scsi0:0:0:0: Device is active, asserting ATN
Recovery code sleeping
Recovery code awake
Timer Expired
aic7xxx_abort returns 8195
scsi0:0:0:0: Attempting to queue a TARGET RESET message
aic7xxx_dev_reset returns 8195
Recovery SCB completes
scsi0: SCSI bus reset delivered. 1 SCBs aborted.
scsi0:0:0:0: Attempting to queue an ABORT message
ahc_intr: HOST_MSG_LOOP bad phase 0x0
scsi0: Dumping Card State in Message-out phase, at SEQADDR 0x45
SCSISEQ = 0x12, SBLKCTL = 0x6
DFCNTRL = 0x0, DFSTATUS = 0x89
LASTPHASE = 0xa0, SCSISIGI = 0x0, SXFRCTL0 = 0x88
SSTAT0 = 0x0, SSTAT1 = 0x0
STACK == 0x15f, 0x0, 0xe6, 0x3
SCB count = 4
Kernel NEXTQSCB = 2
Card NEXTQSCB = 3
QINFIFO entries: 3
Waiting Queue entries:
Disconnected Queue entries:
QOUTFIFO entries:
Sequencer Free SCB List: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 
19 20 21 22 23 24 25 26 27 28 29 30 31
Pending list: 3
Kernel Free SCB list: 1 0
Untagged Q(0): 3
DevQ(0:0:0): 0 waiting
scsi0:0:0:0: Cmd aborted from QINFIFO
aic7xxx_abort returns 8194
scsi: device set offline - not ready or command retry failed after bus 
reset: host 0 channel 0 id 0 lun 0

(repeated for each ID on each channel)

David

Re: Cleanup kbuild for aic7xxx

[Keith Owens]

On Fri, 22 Jun 2001 22:17:12 -0600, 
"D. Stimits" <stimits@idcomm.com> wrote:
> On Fri, 22 Jun 2001 13:39:45 -0600,
>> "Justin T. Gibbs" <gibbs@scsiguy.com> wrote:
>> Users don't have to manually select "rebuild firmware".  They can
>> rely on the generated files already in the aic7xxx directory.  This
>> is why the option defaults to off.
>
>For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have
>had to manually select this for a 7892 controller. Without manually
>selecting it, it guarantees boot failure. I don't know if this is due to
>the SGI modifications or not.

It is a side effect of the SGI source control system.

Re: Cleanup kbuild for aic7xxx

[David Ford]

Here is 2.4.5 plain with the old aic driver.


(scsi0) <Adaptec AIC-7896/7 Ultra2 SCSI host adapter> found at PCI 0/12/1
(scsi0) Wide Channel B, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 392 instructions downloaded
(scsi1) <Adaptec AIC-7896/7 Ultra2 SCSI host adapter> found at PCI 0/12/0
(scsi1) Wide Channel A, SCSI ID=7, 32/255 SCBs
(scsi1) Downloading sequencer code... 392 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
       <Adaptec AIC-7896/7 Ultra2 SCSI host adapter>
scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
       <Adaptec AIC-7896/7 Ultra2 SCSI host adapter>

And then it breaks.

scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, 
lun 0 Inquiry 00 00 00 ff 00
(scsi0:0:0:0) Aborting scb 0, flags 0x6
SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
(scsi0:0:0:0) Sending WDTR message.
(scsi0:0:0:0) Reset called, scb 0, flags 0x16
(scsi0:0:0:0) Bus Device reset, scb flags 0x16, Message-Out phase
(scsi0:0:0:0) SCSISIGI 0xb6, SEQADDR 0xbd, SSTAT0 0x2, SSTAT1 0x3
(scsi0:0:0:0) Queueing device reset command.
(scsi0:-1:-1:-1) 0 commands found and queued for completion.
SCSI host 0 channel 0 reset (pid 0) timed out - trying harder
SCSI bus is being reset for host 0 channel 0.
(scsi0:0:0:0) Reset called, scb 0, flags 0x1076
(scsi0:0:-1:-1) Reset channel called, will initiate reset.
(scsi0:0:-1:-1) Resetting currently active channel.
(scsi0:0:-1:-1) Channel reset
(scsi0:0:-1:-1) Reset device, active_scb 0
(scsi0:0:0:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:1:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:2:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:3:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:4:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:5:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:6:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:8:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:9:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:10:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:11:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:12:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:13:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:14:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:15:-1) Cleaning up status information and delayed_scbs.
(scsi0:0:-1:-1) Cleaning QINFIFO.
(scsi0:0:-1:-1) Cleaning waiting_scbs.
(scsi0:0:-1:-1) Cleaning waiting for selection list.
(scsi0:0:-1:-1) Cleaning disconnected scbs list.
(scsi0:0:0:0) Aborting scb 0
(scsi0:0:0:0) Aborting scb 1
(scsi0:-1:-1:-1) 2 commands found and queued for completion.
SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
(scsi0:0:0:0) Sending WDTR message.
(scsi0:0:0:0) Reset called, scb 0, flags 0x6
(scsi0:0:0:0) Bus Device reset, scb flags 0x6, Message-Out phase
(scsi0:0:0:0) SCSISIGI 0xb6, SEQADDR 0xbd, SSTAT0 0x2, SSTAT1 0x3
(scsi0:0:0:0) Queueing device reset command.
(scsi0:-1:-1:-1) 0 commands found and queued for completion.
SCSI host 0 channel 0 reset (pid 0) timed out - trying harder
SCSI bus is being reset for host 0 channel 0.

And it happily loops on this over and over.

David

Re: Cleanup kbuild for aic7xxx

[Justin T. Gibbs]

>> >Users don't have to manually select "rebuild firmware".  They can
>> >rely on the generated files already in the aic7xxx directory.  This
>> >is why the option defaults to off.
>
>For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have
>had to manually select this for a 7892 controller. Without manually
>selecting it, it guarantees boot failure. I don't know if this is due to
>the SGI modifications or not. The real problem I found is that during
>boot failure, there was no meaningful debug message.

I don't know why your kernel source is out of sync.  I will have to
go pull down the 2.4.5 and 2.4.6 trees and see if some portion of
my patches never made it into those trees.  It also looks like the
comment section for this option didn't make it into my 2.4.4 and above
patches.  I'll correct this on this on Monday.  Here's the relevent
info.  Do you have any comments on what would make it more useful?

+Build Adapter Firmware with Kernel Build
+CONFIG_AIC7XXX_BUILD_FIRMWARE
+  This option should only be enabled if you are modifying the
+  firmware source to the aic7xxx driver and wish to have the
+  generated firmware include files updated during a normal
+  kernel build.  The assmebler for the firmware requires
+  lex and yacc or their equivalents, as well as the db v1
+  library.  You may have to install additional packages or
+  modify the assmebler make file or the files it includes
+  if your build environment is different than that of the
+  author.


>Missing firmware rebuild is fatal for my system, SMP x86 with integrated
>7892. Messages and config menu information is inadequate, it requires a
>bit of pounding the head on the wall to figure it out.

It is hard to make the kernel driver give a reasonable message for every
possible error that running with incompatible components may cause.

--
Justin

Re: Cleanup kbuild for aic7xxx

[Justin T. Gibbs]

>Ok, here's the relevant output from 2.2.19.  In future emails, would 
>like all the information posted to the list or would you like URLs to 
>the text docs?

If you think the information is of interest to the list, I have no
problem with continueing our dialog there.

Embedded text or URLs, whichever is easier for you is fine by me.

>Linux version 2.2.19 (root@James) (gcc version 2.95.3 20010315 
>(release)) #1 Fri
> Jun 22 20:17:08 PDT 2001
>...

Could you, by chance, have a 440GX based system, perhaps even an Intel
Lancewood MB?  If this is the case, your problem has to do with the PCI
IRQ table on the MB and/or how Linux now interprets it (Alan Cox or Doug
Ledford may have more info on this issue since they have been tracking
it for RedHat).  A possible work around is to enable APIC I/O.

If you don't have such a system, can you provide the full dmesg as
well as lspci output for your system.  That combined with the driver
messages should help me figure this out.

--
Justin

Re: Cleanup kbuild for aic7xxx

[Justin T. Gibbs]

>Here is the output of a plain jane 2.4.5 compile with the 'new' adaptec 
>compiled in:

Yup.  Interrupts are not working for the chip.  See my other reply
for a possible work around.

--
Justin

Re: Cleanup kbuild for aic7xxx

[Justin T. Gibbs]

>On Fri, 22 Jun 2001 22:17:12 -0600, 
>"D. Stimits" <stimits@idcomm.com> wrote:
>> On Fri, 22 Jun 2001 13:39:45 -0600,
>>> "Justin T. Gibbs" <gibbs@scsiguy.com> wrote:
>>> Users don't have to manually select "rebuild firmware".  They can
>>> rely on the generated files already in the aic7xxx directory.  This
>>> is why the option defaults to off.
>>
>>For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have
>>had to manually select this for a 7892 controller. Without manually
>>selecting it, it guarantees boot failure. I don't know if this is due to
>>the SGI modifications or not.
>
>It is a side effect of the SGI source control system.

Can you explain why this would be the case?  Are you saying that SGI
is building the generated file and also keeping it in their revision
control system?  If so, wouldn't their shipped config also include
building the firmware?

I think one of my distributed patches is somehow screwed up and this
error was propogated into the SGI kernel distribution.

--
Justin

Re: Cleanup kbuild for aic7xxx

[Keith Owens]

I am not refusing to make changes to aic7xxx kbuild but I do insist
that it satisfies the overall kernel requirements.  Justin, please try
my previous patch plus the Makefile update below and see if it causes
any significant problems for you as aic7xxx maintainer.

Ignoring aic7xxx for the moment, kernel build has problems with _all_
files that are both generated and shipped.  Perhaps if I explain the
problems, you will understand why the changes were done.

Suppose you have files "base" and "gen" where "gen" is generated from
"base".  In the ideal case only "base" is shipped and all users create
"gen" on their own system.  That covers most generated files and has no
timestamp or source repository problems.

OTOH suppose the process to convert "base" to "gen" requires utilities
that not every user is expected to install.  Then it makes sense to
ship "gen" as well as "base" but it must be done so that it satisfies
several kbuild requirements.

(1) All kernel source trees from the top level maintainers (LT, AC, DM)
    must be complete.

    Users must not have to have to search other sites for missing
    headers or sources.  The fact that several architectures will not
    work out of the box which violates this requirement is no excuse
    for ignoring it.

    This means that "gen" must be included in LT, AC and DM trees.
    Anybody wanting to maintain their own patches against a master tree
    or to supply a source tree for downstream users must therefore
    include "gen" in their source control system.  Omit "gen" and
    downstream users are forced to generate it which defeats the
    purpose of shipping it.

(2) Generated files must not be overwritten in place.

    When "gen" is shipped and also overwritten in place then anybody
    who regenerates the file (for whatever reason) runs the risk of
    spurious differences appearing in their patches.  Particularly when
    the generating process depends on tools which can vary from one
    user to another.

    For example, the collating order of identically keyed entries in a
    db database depends on the version of libdb, this has already
    generated a spurious patch against aic7xxx in the -ac tree.  The
    order of sort entries for text depends on the user's locale.  When
    you rely on external tools you can never guarantee that every
    user's version of those tools will produce exactly the same output
    as your version.  The result can be logically identical but be
    physically different, diff only cares about physical differences,
    hence the spurious patches.

    Some source control systems mark the master files as read only to
    prevent accidental editing of the inputs, you have to register that
    you want to modify the file before you can edit it.  Any generated
    file that is overwritten in place will break on these systems.

    When generated files are overwritten in place it adds uncertainty
    when you are building multiple kernels from a single source tree.
    If the previous compile overwrote "gen", is the result always valid
    for the next compile?  If make mrproper does not reset to a
    pristine kernel then the results are unreliable.  make mrproper can
    only erase generated files, it cannot reset them to their shipped
    state unless shipped and generated are separate files.

    The only solution to the problems above is to ship "gen" as
    "gen_shipped" and either copy "gen_shipped" to "gen" (no special
    tools required) or ignore "gen_shipped" and generate "gen" directly
    from "base" (needs special tools).  Never overwrite generated files
    in place.

(3) Files must not be generated unless the user changes something
    related to "gen", users who are not working on "gen" must not be
    forced to regenerate, they may not have the tools.  This is an
    obvious statement but how do you check if they have changed
    anything?

    You cannot rely on file timestamps when both "base" and
    "gen_shipped" are in the master source tree.  When the maintainer
    ships a new version of "base" and "gen_shipped", they eventually
    appear in top level patch sets.  When a user fetches a patch and
    applies it to their source tree, both "base" and "gen_shipped" get
    new timestamps, but which one is newer?  It depends on the order of
    the entries in the patch set, so you might have "base" being newer
    than "gen_shipped" (bad) or vice versa (good).  It all depends on
    how the patch set was generated and there is no defined order for
    files in a patch set, it varies from one source control system to
    another.  Even if the maintainer always send patches in the desired
    order, after they have gone through various source control systems,
    the final order is undefined.

    Since you cannot rely on timestamps, the only other option is to
    check if any of the related files have changed since they were
    shipped.  That is, the maintainer does an md5sum over the related
    files and ships the result as part of the patch, kbuild detects
    that a file has changed when its md5sum is different from the
    maintainer's copy.
    
    If any file related to "base" or "gen" has been changed (checked
    via md5sum) then the user must regenerate instead of relying on the
    shipped version.  This will only occur when the user is working on
    the files and they must have the additional tools.  Normal users
    are not affected.

(4) Users who are working on "base" must be supported by kbuild.

    Not only must kbuild protect users who are not working on "base",
    it must also support those who are working on "base".  They should
    not have to explicitly make anything, it should be automatic.

    The only thing that cannot be easily automated is the generation of
    the shipped files and their md5sums, only the coder knows when they
    are about to ship the files.


The current aic7xxx kbuild violates (1)-(3).  Not your fault, the
requirements have never really been documented.  My patch, with the
correction below, handles all 4 requirements.  The only extra work for
the aic7xxx maintainer is to

  cd drivers/scsi/aic7xxx
  sh make_sequencer ship

before generating the patch.  That type of action applies to everybody
who generates files that are also shipped.

After make_sequencer ship, any changes to the files in MD5SUMS will
automatically rebuild the firmware until the next make_sequencer ship,
satisfying requirement (4).  Or it will with the updated makefile
below.  This replaces drivers/scsi/aic7xxx/Makefile in my earlier
patch, with this addition, my patch supports all 4 requirements above.
Clean kbuild for aic7xxx developers and for end users, all automatic.

--- cut here
#
# drivers/scsi/aic7xxx/Makefile
#
# Makefile for the Linux aic7xxx SCSI driver.
#

O_TARGET := aic7xxx_mod.o
obj-m	:= $(O_TARGET)

# Platform Specific Files
AIC7XXX_OBJS = aic7xxx_linux.o aic7xxx_linux_pci.o
AIC7XXX_OBJS += aic7xxx_proc.o aic7770_linux.o
# Core Files
AIC7XXX_OBJS += aic7xxx.o aic7xxx_pci.o aic7xxx_93cx6.o aic7770.o

obj-y	+= $(AIC7XXX_OBJS)

MOD_TARGET = aic7xxx.o

include $(TOPDIR)/Rules.make

aic7xxx_generated	:= aic7xxx_seq.h aic7xxx_reg.h

$(AIC7XXX_OBJS): $(aic7xxx_generated)

$(aic7xxx_generated): dummy
	sh ./make_sequencer

clean:
	rm -f $(aic7xxx_generated)
	$(MAKE) -C aicasm clean

Re: Cleanup kbuild for aic7xxx

[Keith Owens]

On Fri, 22 Jun 2001 23:14:49 -0600, 
"Justin T. Gibbs" <gibbs@scsiguy.com> wrote:
>Can you explain why this would be the case?  Are you saying that SGI
>is building the generated file and also keeping it in their revision
>control system?  If so, wouldn't their shipped config also include
>building the firmware?

SGI's source control system marks the supplied files as read only to
prevent accidental updates.  That causes problems when generated files
are updated in place, see my long memo about why this is bad.  I am
guessing that SGI had problems with the earlier version of your
Makefile (it always generated the files) so they excluded the generated
files from their repository.

Changing aic7xxx kbuild so it does not overwrite supplied files will
fix this class of problem for all source repositories, not just SGI.

Re: Cleanup kbuild for aic7xxx

[D. Stimits]

"Justin T. Gibbs" wrote:
> 
> >> >Users don't have to manually select "rebuild firmware".  They can
> >> >rely on the generated files already in the aic7xxx directory.  This
> >> >is why the option defaults to off.
> >
> >For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have
> >had to manually select this for a 7892 controller. Without manually
> >selecting it, it guarantees boot failure. I don't know if this is due to
> >the SGI modifications or not. The real problem I found is that during
> >boot failure, there was no meaningful debug message.
> 
> I don't know why your kernel source is out of sync.  I will have to
> go pull down the 2.4.5 and 2.4.6 trees and see if some portion of
> my patches never made it into those trees.  It also looks like the
> comment section for this option didn't make it into my 2.4.4 and above
> patches.  I'll correct this on this on Monday.  Here's the relevent
> info.  Do you have any comments on what would make it more useful?
> 
> +Build Adapter Firmware with Kernel Build
> +CONFIG_AIC7XXX_BUILD_FIRMWARE
> +  This option should only be enabled if you are modifying the
> +  firmware source to the aic7xxx driver and wish to have the
> +  generated firmware include files updated during a normal
> +  kernel build.  The assmebler for the firmware requires
> +  lex and yacc or their equivalents, as well as the db v1
> +  library.  You may have to install additional packages or
> +  modify the assmebler make file or the files it includes
> +  if your build environment is different than that of the
> +  author.

I would add a note to try without it at first, but if bootup starts
normally, then hangs in what seems like a controller or filesystem
failure of a scsi drive, try to enable the option.

(this would give some hint about debugging an aic7xxx failure,
regardless of error messages)

D. Stimits, stimits@idcomm.com

> 
> >Missing firmware rebuild is fatal for my system, SMP x86 with integrated
> >7892. Messages and config menu information is inadequate, it requires a
> >bit of pounding the head on the wall to figure it out.
> 
> It is hard to make the kernel driver give a reasonable message for every
> possible error that running with incompatible components may cause.
> 
> --
> Justin

[working] Re: Cleanup kbuild for aic7xxx (attn: Alan & Doug)

[David Ford]

Justin T. Gibbs wrote:

>>Here is the output of a plain jane 2.4.5 compile with the 'new' adaptec 
>>compiled in:
>>
>
>Yup.  Interrupts are not working for the chip.  See my other reply
>for a possible work around.
>
>--
>Justin
>

Wow.

Ok, changing it to UNI and enabling the APIC stuff has made it boot just 
dandy.  I really appreciate your advice.  Thank you.

Now, if Alan and Doug are interested, here is some information of the 
system.

http://stuph.org/440GX-boot.dmesg
http://stuph.org/440GX-lspci
http://stuph.org/440GX-dump_pirq

David

Re: Cleanup kbuild for aic7xxx

[Justin T. Gibbs]

>Ignoring aic7xxx for the moment, kernel build has problems with _all_
>files that are both generated and shipped.  Perhaps if I explain the
>problems, you will understand why the changes were done.

Okay.

>Suppose you have files "base" and "gen" where "gen" is generated from
>"base".  In the ideal case only "base" is shipped and all users create
>"gen" on their own system.  That covers most generated files and has no
>timestamp or source repository problems.

Okay.

>OTOH suppose the process to convert "base" to "gen" requires utilities
>that not every user is expected to install.  Then it makes sense to
>ship "gen" as well as "base" but it must be done so that it satisfies
>several kbuild requirements.
>
>(1) All kernel source trees from the top level maintainers (LT, AC, DM)
>    must be complete.
>
>    Users must not have to have to search other sites for missing
>    headers or sources.  The fact that several architectures will not
>    work out of the box which violates this requirement is no excuse
>    for ignoring it.
>
>    This means that "gen" must be included in LT, AC and DM trees.
>    Anybody wanting to maintain their own patches against a master tree
>    or to supply a source tree for downstream users must therefore
>    include "gen" in their source control system.  Omit "gen" and
>    downstream users are forced to generate it which defeats the
>    purpose of shipping it.

Sure.

>(2) Generated files must not be overwritten in place.
>
>    When "gen" is shipped and also overwritten in place then anybody
>    who regenerates the file (for whatever reason) runs the risk of
>    spurious differences appearing in their patches.  Particularly when
>    the generating process depends on tools which can vary from one
>    user to another.
>
>    For example, the collating order of identically keyed entries in a
>    db database depends on the version of libdb, this has already
>    generated a spurious patch against aic7xxx in the -ac tree.  The
>    order of sort entries for text depends on the user's locale.  When
>    you rely on external tools you can never guarantee that every
>    user's version of those tools will produce exactly the same output
>    as your version.  The result can be logically identical but be
>    physically different, diff only cares about physical differences,
>    hence the spurious patches.
>
>    Some source control systems mark the master files as read only to
>    prevent accidental editing of the inputs, you have to register that
>    you want to modify the file before you can edit it.  Any generated
>    file that is overwritten in place will break on these systems.
>
>    When generated files are overwritten in place it adds uncertainty
>    when you are building multiple kernels from a single source tree.
>    If the previous compile overwrote "gen", is the result always valid
>    for the next compile?  If make mrproper does not reset to a
>    pristine kernel then the results are unreliable.  make mrproper can
>    only erase generated files, it cannot reset them to their shipped
>    state unless shipped and generated are separate files.
>
>    The only solution to the problems above is to ship "gen" as
>    "gen_shipped" and either copy "gen_shipped" to "gen" (no special
>    tools required) or ignore "gen_shipped" and generate "gen" directly
>    from "base" (needs special tools).  Never overwrite generated files
>    in place.

I think this is the crux of our where we disagree.  The generated file
in this case should only be overwritten by those developing the driver.
We've already agreed that the mechanism used in 6.1.5 of the aic7xxx
driver (always regenerage) cannot work.  Therefore the predominant
case, and in my opinion the only case you need to concern yourself with,
is building the kernel from the vendor generated file.

Consider for a moment, the "old" aic7xxx driver.  It does not ship with
the tools to rebuild its firmware even though it does ship with firmware
source.  There has never been the option to rebuild the firmware so no-one
has.  The build system doesn't attempt to verify that the firmware is
up to date via an MD5 checksum or by any other means.  The generated
firmware file is treated like a regular old header file that came from
the vendor (i.e. Doug Ledford).

The only issue with the above case was the occasional post from the
brave soul that wanted to hack the firmware themselves.  Rather than
force them to scour the web looking for how to update the firmware
(the usual result was a hit on aicasm in the FreeBSD distribution which
they then ported to Linux), I chose to ship the tools and optionally
have them integrated into the build.

In this scenario, I would argue that overwriting the files in place
is the correct strategy.  For the developer that choses to build
the firmware, timestamp based "up to date" behavior is correct,
the last firmware file you've generated/tested is already in the correct
place for generating patches, and, as a developer, you understand
how to use your revision control software so the fact that this file
is generated is not a concern.

>(3) Files must not be generated unless the user changes something
>    related to "gen", users who are not working on "gen" must not be
>    forced to regenerate, they may not have the tools.  This is an
>    obvious statement but how do you check if they have changed
>    anything?

If they don't have the tools, checking to see if they have changed
something is worthless.  If they do have the tools and understand the
consequences of what they are doing, they can check a box during
config.  If you care about dependencies (i.e. you are a developer),
timestamp based dependencies are certainly sufficient.  You may get
one extra build after a patch, but the build will succeed.

>(4) Users who are working on "base" must be supported by kbuild.
>
>    Not only must kbuild protect users who are not working on "base",
>    it must also support those who are working on "base".  They should
>    not have to explicitly make anything, it should be automatic.
>
>    The only thing that cannot be easily automated is the generation of
>    the shipped files and their md5sums, only the coder knows when they
>    are about to ship the files.

The assumption should be that the generated firmware is destined to
be shipped.  Those fixing firmware bugs will want to get their changes
tested by others.  Those requiring special firmware behavior will
ship those changes in their produce or internal kernel release.

>The current aic7xxx kbuild violates (1)-(3).

1 is only violated for distributions that were caught up by the build
behavior in 6.1.5.  This behavior was a bug and that bug has been corrected.
The only distributor I know of that *may* have been affected by this is SGI.
I'll be contacting them to fix their distribution.

2 is not an issue unless you happen to have an uncorrected tree from SGI.
Bulding the firmware was only a requirement for a short time in the new
driver, and has never been a requirement for the old driver.  I think
the sucess of the old driver validates that this scheme works without
any of the complexity of your proposal.

3 is not violated now either.  The build system may offer a warning,
but I have no concern with having that warning removed.  If anything,
your proposed scheme makes it more difficult to get the proper depency
semantics if you are really tryin to work on the firmware - the release
process is now separated from the standard build.  I contend that the
only reason people have been building the firmware is due to fallout
related to the old build scheme.  The new scheme avoids this, in effect,
by moving/deleting files forcing the correction of a few screwed up
revision control repositories.  Email to the distributors seems a much
simpler way to correct this last remaining problem.

--
Justin

Re: Cleanup kbuild for aic7xxx

[Keith Owens]

On Mon, 25 Jun 2001 12:22:29 -0600, 
"Justin T. Gibbs" <gibbs@scsiguy.com> wrote:
>Keith Owens wrote:
>>(2) Generated files must not be overwritten in place.
>>
>>    When "gen" is shipped and also overwritten in place then anybody
>>    who regenerates the file (for whatever reason) runs the risk of
>>    spurious differences appearing in their patches.  Particularly when
>>    the generating process depends on tools which can vary from one
>>    user to another.
>
>I think this is the crux of our where we disagree.  The generated file
>in this case should only be overwritten by those developing the driver.
>We've already agreed that the mechanism used in 6.1.5 of the aic7xxx
>driver (always regenerage) cannot work.  Therefore the predominant
>case, and in my opinion the only case you need to concern yourself with,
>is building the kernel from the vendor generated file.
>
>In this scenario, I would argue that overwriting the files in place
>is the correct strategy.  For the developer that choses to build
>the firmware, timestamp based "up to date" behavior is correct,
>the last firmware file you've generated/tested is already in the correct
>place for generating patches, and, as a developer, you understand
>how to use your revision control software so the fact that this file
>is generated is not a concern.

I think you are missing an important point.  Once the developer issues
a patch, that patch becomes part of everyone's source tree.  So
_everyone_ ends up changing the generated files, at which point they
run into the timestamp and source repository problems.  Overwriting in
place works for the developer but it causes problems for the rest of
the world.  The rest of the world can never guarantee that their
timestamps match the developer's timestamps, in fact you can almost
guarantee that they don't.

<emp>
  Any timestamp check in kbuild is unreliable when generated files are
  shipped and then updated in place, even if nobody except the
  maintainer ever changes the generated file.  Distributing a patch has
  exactly the same effect on timestamps as changing the generated file.
</emp>

You want timestamp checks for aic7xxx firmware, but including those
checks in kbuild will hit everyone else the moment they apply your
latest patch.  We either fix the dependency problem so it works for
everyone or we remove all dependency checking on aic7xxx firmware
generation.  Fixing the problem for everyone is my preferred option
because it gives better support for people working on the firmware.
Timestamps on generated and shipped files cannot reliably detect if
"base" and "gen" are in sync or not, hence the use of md5sum.

Re: Cleanup kbuild for aic7xxx

[Justin T. Gibbs]

>>I think this is the crux of our where we disagree.  The generated file
>>in this case should only be overwritten by those developing the driver.
>>We've already agreed that the mechanism used in 6.1.5 of the aic7xxx
>>driver (always regenerage) cannot work.  Therefore the predominant
>>case, and in my opinion the only case you need to concern yourself with,
>>is building the kernel from the vendor generated file.
>>
>>In this scenario, I would argue that overwriting the files in place
>>is the correct strategy.  For the developer that choses to build
>>the firmware, timestamp based "up to date" behavior is correct,
>>the last firmware file you've generated/tested is already in the correct
>>place for generating patches, and, as a developer, you understand
>>how to use your revision control software so the fact that this file
>>is generated is not a concern.
>
>I think you are missing an important point.  Once the developer issues
>a patch, that patch becomes part of everyone's source tree.  So
>_everyone_ ends up changing the generated files, at which point they
>run into the timestamp and source repository problems.

No they don't.  Post 6.1.13, the warnings will disappear.  Timestamp
dependencies between the firmware source and the generated files
will not exist unless you check the rebuild firmware box.  The only
dependencies that do exist are on the timestamp of the generated firmware
relative to the rest of the kernel driver.  This is the exact dependency
you want to apply to the general user.  If you update the firmware image
(from the vendor or somewhere else), the kernel driver is rebuilt.
Just like aic7xxx_old.  Just like the qlogic drivers when the vendor
drops some new firmware.  Just like any other file that depends on
a header.

>Overwriting in
>place works for the developer but it causes problems for the rest of
>the world.  The rest of the world can never guarantee that their
>timestamps match the developer's timestamps, in fact you can almost
>guarantee that they don't.

The timestamp dependencies between the firmware source and the generated
files *do not matter*.  The common user cannot rebuild the firmware anyway,
so having this check serves no purpose.  When has this scheme failed for
aic7xxxx_old?  The qlogic drivers?  The Tigon drivers?  It hasn't.  Post
6.1.5 we are using the exact same scheme in the new aic7xxx driver as
has been used successfully numerous times.  The only reason that this
scenario is at all different is that I introduced a bug by ever attempting
to build the firmware by default.  That bug has been corrected.  The SGI
tree is being corrected.  Where is the problem?

><emp>
>  Any timestamp check in kbuild is unreliable when generated files are
>  shipped and then updated in place, even if nobody except the
>  maintainer ever changes the generated file.  Distributing a patch has
>  exactly the same effect on timestamps as changing the generated file.
></emp>

If no-one but the maintainer ever checks the box to rebuild the firmware,
how is this scheme any different than the drivers I've listed above.
The dependencies all seem to work as expected.  If the generated firmware
is updated, via patch or full file replacement, the build works as intended.

>You want timestamp checks for aic7xxx firmware, but including those
>checks in kbuild will hit everyone else the moment they apply your
>latest patch.

That's not true.  Starting in my second reply to you on this subject
I have repeatedly said, "Then kill the warning [in the default case]".
The only dependency I want in the default case is:

$(AIC7XXX_OBJS): aic7xxx_seq.h aic7xxx_reg.h

Other than a non-fatal warning, this is what users have today.  This,
timestamp based dependency, is correct, works on any system that can
build a Linux kernel, and completely handles the default case of
generated files only being updated via patch or full file replacement.

>We either fix the dependency problem so it works for
>everyone or we remove all dependency checking on aic7xxx firmware
>generation.

Exactly.  No dependency checking on the generated firmware.  This is
what I've been advocating since my second reply to you.

>Fixing the problem for everyone is my preferred option
>because it gives better support for people working on the firmware.

As the maintainer who does arguably all of the work on the firmware,
I believe it will make my job more difficult.  Do I count?  8-)

>Timestamps on generated and shipped files cannot reliably detect if
>"base" and "gen" are in sync or not, hence the use of md5sum.

I find the extra machinery and complication to the build process overkill
relative to this danger.  You also increase the number of generated files
that are shipped.  I'd much rather just refine what is there now (i.e.
kill the warnings) than complicate things further.

--
Justin