Skip to contentSkip to conversation

Cleanup kbuild for aic7xxx

DISCUSSION Keith Owens 5 participants 28 messages Jun 22, 2001 – Jun 26, 2001

lore
Share & tools
lore
#0 lore raw

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#\_;6MGRT4O0E: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.*QK7VS[=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_SU(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_S74N.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_>9EQY^^\_[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(_G39GFR>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?&7OU3V;' M8A7CQPQ8_<QGLS)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%)"GQF1V;@*"$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;:,-%&MSJ: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:=!@<;X9S*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!VIG1C+^(A4/I2($A)QI0(G&E M13)(:X7LK$MV]/"Q=R&=TQVQQ.VK(+<7LH8>L>8M00=)IW'AY(=0D&+M#4*# MM_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$*<$@F2PC]*HDQNJ>LQ;;(RRLG.6>IZK%41\;U2+QMZ2O"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[7P1M1X+ST<*R"YW1: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;PSN0R1&^XTYL3#XEV0_IK83SLRQX,K/5/6%,V8::39[Q MPSEM069#NQ"3LQS,*8Q1'@G/5A!.=T@'5T8YG@VDU0O"=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> [email protected]<O9H"M%>@$1VH6R!IV0697O@72=D)R%R12F;4AVLV&-1C;+6, M/,\BM8P[0PE0]E13D&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&?GECF(;;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@CONEZJ)-O5&]KWM(Y!FLOE>@.3XYHLT5- MX(=Z\FCIIW7,B1J$KDI.S=BB39;47.JW79,7&,B)\0]&T1QZQAG5;!C'>QW M0.,M-;H&<5<?H&/"CJ'^L66=2TL>MIQ^!J%\8TYY8X@RQ]"P4VC_1L?RS 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^AM3I'7R%.Y8[$YCH1&4/NLM&.YC?*0%;(T7[K@(9A\/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=))BQD M-T_=;L9RB^O94DLN]G5W-WKM)R<@@5+;;!XI*;;W#)#"4S:X#904NPWQKH. M\E6Y)>M<V6HFT-O2D&V#3GYDF1I((/<<A,&9FNK+-O(B.E='+FG('\5W0U. MP2<J3G',DCD%J21HC89N.\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]RMLY4H(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@*QJJVQ!PC(;8G8A/=,>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\MO8'K4/]6^B$!$N=@6!W\"[K%0/QMA3L#GE#]SK6#PL MH0VZ2<_Q?)#A*!D$SG42/;X:::Z[9I-/H%4UOYS18XQRSQF!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/%_BGV=$$*>V$K-=2+B*5;N^Z/HC#\A6B5GQ_O[.9E M3MU)OQV"[O/9HN:_#<22H5C?X?7ODE,^\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<UVS 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>"CAZ6LOW5O.\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)_$;[email protected],$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(;_*J41U8J1-W'(-L4M,235RNIH@KE2AT=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:YUB2<,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:0JW9;_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/ MRH?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? M3SI7B1=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$#+@F0-N2&#2F56NY$!?@=\=_G!&M)1:3,C;8663[2\<SKLS[N3;@6G M5C(8G3-XOW?>MTMH?#;5.5AIZ\L+-!A..1STT3BF30*'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% MH0]"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+-W7U<^L09M\B4'^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&-)][0C=\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\ZU&+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<<. MGQ2]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<LM4RIAA" M@^<L@4$8$5J#N='IX"]]1L;IL(_@-0:3;G?>J^4D,$CN0>9@?PZ&H?D%OR9 M\4E_.NI>S4+B8PC9A'PJ%^/OYX!,-IDCNGY?'R-DG6.03HK+-&\ZC"93#$& MCCQ7DSY_"XE3Y^2+#/">&36CUA*G5LDHT."!"2=>@<OS/%$)R_,\03>&TR8 M7QI@FR$Z>S8XYMQZ"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;3VQNN'0_K1^W?S,VJ+3#6)_SYQ/.][PQF;/^Y-[I0.Q;OA&T)S6 MA4AJL)J&90DU#W.;Z\&O9G%9;("GW!7]=#:K>!$:L%7<31@)G2"*#.)> MW_8GH_YPSLK,J_%4S5%@CJ$5R%*^XX)"Z,(C-*RRDS-)3!(.V2F+<,Q$B)4 M;MRD.N8:.,F_=GU9#0/7'#FHT8]WJ5W*9Z3WE3P:Y8C[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=+02&UO<AQZNZ&*$OY;;/_FA"$PQCL2!4M7$MN1G M!_4\-@&OZKA1;"6KKC:R9M$?,%APG&J%[1P0.5DE)JC8<ADF.+9RG<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)QMVMED@/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["&$VT9CF%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 [email protected](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;UN8M:<H M'#5-PM&Q,V2J2CL>F:_9SX?%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:PFH^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^.*LDC0P!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]*-49^'22KAA,<>8PW?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/>JEI: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>RP%OB^"%PC</C(#SN_=:@LB>C*Y[(J2 M$X6*'K0=*M!S:]%B%\M\F9(,SF;:#HOR:OQ^)+IAPIFEL6;F^'S(.8<J41+ M.EE,/N>3\36_H=?KUU,DE')^>9@1SK1IJCD*D7JKDJFU4C!.-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>FC5@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(9FZ);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@WF60FJP%I*=H$C_&2_UF(F2,?2R<NT!@?C^'O MP_<_YZ$Y!J33%I"DQ&,2V7@*B0(?&\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"R1"&&!*!5D9+[%_;M`4?;)MH8BHDEF?$%H(:
M8J,()2"&,V6I5A')=46K<)[email protected]"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^UM=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!$RBS][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#-+$MOOM;8#'D3[$2;56GR*J%U2B MN7,=G"N#=Z&]3MA9G]@I\J/2\R4D&P0-4?D=SO!MO2=<A8:$:HBEAIP@>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"?!NTJ%BD=L"E8!Z23D5H&<FZZ M/Y)3J*HM=19:(6,JUVP$N61I!]-:LL*+&,"FE.$B(+<14&<$@B2P0K\*(DR MN:6NQ[3)[email protected]>IZ[%61<3W2KULZ6L"*=R%RR1R:W7,%MFR1-!!AGJ^VLQ M"^5BF247HWHD&Q9VS:U.:CD*2T%V@#JMNV+BB<>J5F/MHBU;LE@[3DY+:> M-U0$/^&^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<+RRYWA29_L!]UI:C/!%T1U&=1ZXQ"P-BR]:A.ZE\[TIH&HZT-.\% M'=7V%-F/ICLXK[)I2%SK2<N]<_342D!"*C?(]R$#(3FL[/QKX;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@_GM69#>U"3,YR,*<P1GDD M/%M!.-TA'5P9Y7@VDY0O2142SV(: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^?U95T5[8'\@#I==8F!X)("T"\5$MHR!X3^D8 MJ/B_SI,W^1UR?V=A>A=YSD1HQDEAJ#9>V7>R6-1U3.&4M9X.N%.D%1&@7 MB)KV697?D62-L)R5V02&76A@RLV6!0C['5,O(\B]0R[@PE0-E33D%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[/WQY5];!X-FJG>#;+?67;&*Q5@?.<-J"]]:B>#6*PZJ[@/@7< M)$LBONDZZ%.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>0AHQV#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&**JAL-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?0FIJ-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*QJHVA)SC(38G@0@/M$=2_Y%$&59JAJJK(3><89NGGP:?&F1#MT?-9R MR\J'F+>YR2W>"-UW4;=K0T-[X]2B(1;OM4P6&.+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:^MC8'[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&6QT%9GFN37MNRAVSG/J&96"+ M6=;[B4@3H796M)'>(#F))#TA=3OS,4@GEIJF9#LW'-B5NZT1K<_D&?5Z&Q* M<8IO2$9D?TO0)^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$$GGX&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<1DD=/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":4SXTI9PY9$*<$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%:@RYXX=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<E0XABN9\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/"<7W&_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_?-Z9V^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$N1VN2\":Q(PX)H$#+@A@4EG5KF2WT%?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 M8(;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\E8>\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?OQ-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&MPNGCL.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[+4LF88@@-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"NRID1[/!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"<%H7H6HB>@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=@ML^#&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]<[email protected]&<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/+SN37Z.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-!E860XSR['HFB),8)&]@F2CM1G,FC?PF(>N47", M%LD;3HGU49&[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]HTT$_II4S%+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%; MG*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#1KK-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 MW')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 MJ/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=%#[email protected]$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#WOQ8QZ00.#: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('#[RPXOW>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

#1 lore raw
Quoted 5 lines

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.

Quoted 2 lines

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

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

Quoted 4 lines

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

Quoted 7 lines

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

Quoted 4 lines

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

Quoted 4 lines

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.

Quoted 2 lines

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

This is already true today.

Quoted 2 lines

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

Already true today.

Quoted 1 line

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

#2 lore raw
Quoted 9 lines · Justin T. Gibbs
Quoted 5 lines

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.

Quoted 4 lines
Quoted 2 lines

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

Quoted 8 lines
Quoted 4 lines

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

Quoted 10 lines
Quoted 7 lines

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

Quoted 9 lines
Quoted 4 lines

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

Quoted 4 lines

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.

Quoted 6 lines
Quoted 4 lines

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.

Quoted 4 lines
Quoted 2 lines

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.

Quoted 4 lines
Quoted 2 lines

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

Quoted 4 lines
Quoted 1 line

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.

Quoted 3 lines

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.

#3 lore raw

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]

#4 lore raw
Quoted 3 lines

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/

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 5 lines

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

#5 lore raw

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

Quoted 14 lines · Justin T. Gibbs
Quoted 2 lines

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:

Quoted 2 lines

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.

Quoted 7 lines
Quoted 2 lines

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.

Quoted 10 lines
Quoted 2 lines

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.

Quoted 6 lines
Quoted 5 lines

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

Quoted 7 lines

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

#6 lore raw
Quoted 5 lines

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

Quoted 11 lines
Quoted 11 lines

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:

Quoted 6 lines
Quoted 2 lines

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.

Quoted 7 lines
Quoted 4 lines

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.

Quoted 8 lines
Quoted 7 lines

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.

Quoted 4 lines

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

#7 lore raw
Quoted 8 lines

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

#8 lore raw
Quoted 3 lines

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.

Quoted 4 lines

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

#9 lore raw
In reply to Justin T. Gibbs

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

#10 lore raw
Quoted 2 lines

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

#11 lore raw

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

Quoted 9 lines · Justin T. Gibbs
Quoted 2 lines

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

#12 lore raw
In reply to Justin T. Gibbs

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

#13 lore raw
In reply to Keith Owens
Quoted 8 lines
Quoted 6 lines · Justin T. Gibbs
Quoted 5 lines

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.

Quoted 7 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

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

Quoted 9 lines
Quoted 8 lines
Quoted 4 lines

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

Quoted 5 lines

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.

Quoted 8 lines
Quoted 8 lines
Quoted 7 lines

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

Quoted 5 lines
Quoted 2 lines

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?

Quoted 25 lines
Quoted 9 lines
Quoted 4 lines

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

Quoted 4 lines

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

Quoted 4 lines

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.

Quoted 10 lines
Quoted 6 lines
Quoted 4 lines

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.

Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

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.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

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.

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

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.

Quoted 6 lines
Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 1 line

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.

Quoted 1 line

The new method is clean.

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

Quoted 1 line

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

#14 lore raw

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
#15 lore raw
Quoted 3 lines

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.

Quoted 4 lines

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.

Quoted 13 lines

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.

Quoted 6 lines

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.

Quoted 31 lines

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

Quoted 5 lines

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.

Quoted 5 lines

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

Quoted 9 lines

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

Quoted 1 line

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

#16 lore raw
Quoted 16 lines · Justin T. Gibbs
Quoted 7 lines · Keith Owens

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

Quoted 7 lines

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.

#17 lore raw
Quoted 15 lines
Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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?

Quoted 6 lines

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

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 2 lines

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

Quoted 2 lines

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

#18 lore raw
In reply to Keith Owens
Quoted 5 lines · Keith Owens
Quoted 2 lines · Justin T. Gibbs
Quoted 2 lines

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

Quoted 7 lines
Quoted 7 lines
Quoted 3 lines

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

Quoted 5 lines

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.

Quoted 16 lines
Quoted 4 lines
Quoted 2 lines

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

Quoted 8 lines
Quoted 4 lines

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

Quoted 17 lines

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.

Quoted 10 lines
Quoted 7 lines

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

Quoted 86 lines

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

Quoted 9 lines
Quoted 4 lines

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

Quoted 4 lines

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.

Quoted 6 lines
Quoted 4 lines

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.

Quoted 4 lines
Quoted 2 lines

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.

Quoted 4 lines
Quoted 2 lines

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

Quoted 4 lines
Quoted 1 line

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.

Quoted 3 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#19 lore raw
Quoted 10 lines · D. Stimits

On Fri, 22 Jun 2001 13:39:45 -0600,

Quoted 4 lines

"Justin T. Gibbs" <[email protected]> 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.

#20 lore raw
Quoted 8 lines
Quoted 6 lines · D. Stimits

On Fri, 22 Jun 2001 13:39:45 -0600,

Quoted 4 lines

"Justin T. Gibbs" <[email protected]> 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.

Quoted 6 lines
Quoted 4 lines

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

#21 lore raw
Quoted 4 lines · Justin T. Gibbs

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.

#22 lore raw
In reply to D. Stimits
Quoted 9 lines
Quoted 3 lines
Quoted 3 lines

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.
Quoted 3 lines

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

#23 lore raw
Quoted 19 lines · Justin T. Gibbs
Quoted 10 lines
Quoted 4 lines
Quoted 4 lines

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?

(quoted diff) +1 -0
+Build Adapter Firmware with Kernel Build

Review

Quoted 10 lines
(quoted diff) +10 -0
+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, [email protected]

Quoted 10 lines
Quoted 4 lines

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

#24 lore raw
In reply to Justin T. Gibbs
Quoted 10 lines · On 20010623 Keith Owens wrote:
Quoted 4 lines

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 ?

Signature · 4 lines
J.A. Magallon                           #  Let the source be with you...        
mailto:[email protected]
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
#25 lore raw
Quoted 12 lines · J . A . Magallon
Quoted 10 lines · On 20010623 Keith Owens wrote:

Justin Gibbs wrote

Quoted 3 lines

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.

Quoted 5 lines

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.

#26 lore raw
In reply to J . A . Magallon
Quoted 2 lines

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

#27 lore raw
In reply to Justin T. Gibbs
Quoted 22 lines · J . A . Magallon
Quoted 10 lines · On 20010623 Keith Owens wrote:
Quoted 4 lines

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.

Quoted 1 line

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, [email protected]

Quoted 11 lines

--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/