KBuild 2.5 Impressions

KBuild 2.5 Impressions

[Daniel Phillips]

I wanted to know how well kbuild 2.5 really works, so I got the patches
from kbuild.sourceforge.net and gave them a test drive, comparing to
old kbuild.  First I did an out-of-the-box build, then I did 'touch
fs/ext2/inode.c' and rebuilt.  Results are as follows:

                         old kbuild       kbuild 2.5     Speedup

   First time build:     7 min 8 sec     5 min 55 sec     17%
   Incremental build:     25.94 sec       15.31 sec       41% :-)

The test system is a 2 x 1 GHz server with scsi raid.  Note that I only
used one processor for the tests, as I normally do: in my experience,
with old kbuild I spend more time picking up the broken pices than
I save in compile time.

For good measure, I did a make mrproper and rebuild with -j3.  That
completed in 3 minutes, 25 seconds.  Very impressive, and what's more,
running that make a second time completes in 12 seconds, as opposed to
old make, which tends to erroneously rebuild a large number of files,
and sometimes does not complete the job correctly.

I have only one point on the curve, but it confirms what Keith has
been saying.  The incremental build speed is especially important to
me.  If I were working all the time on 2.5 - sadly, I'm not - I would
without question be using kbuild 2.5 simply by reason of the fast
incremental builds.

Miscellaneous Notes
-------------------

Along the way, old kbuild did the usual wrong things:

  - In the incremental build, 6 files rebuilt that should not have been

  - Once, when I interrupted the make dep, subsequent make deps would
    no longer work, forcing me to do make mrproper and start again.

  - Way too much output to the screen

I took a quick look into some of the kbuild 2.5 Makefile.in files, just
to get a feeling for what they look like, and they look fine to me.  For
example, fs/ext2 has acquired a Makefile.in file, with contents that
seem easily understandible.  The syntax of these files is explained in
the documentation, which is provided by the patch set, in:

   Documentation/kbuild/kbuild-2.5.txt

Reading through it, I found out about the NO_MAKEFILE_GEN, an option
that promises to make a fast build system even faster for interative
development, the type I always do.  There is also a lot of informative
design documentation.  Amazingly, there is even postscript
documentation.  Full marks for documentation here.

Note to Keith: this file needs to be in some obvious place on the
sourceforge site.

Both the old and new build systems failed the rename test: rename the
root of the source tree and it will no longer build.  The kbuild 2.5
documentation explains:

  Unlike kbuild 2.4, renaming a source or object tree does not force a
  complete rebuild.  After renaming any tree and updating the KBUILD_SRCTREE
  and KBUILD_OBJTREE variables, just run make.  Unless you have changed any
  files, nothing should be rebuilt, however the make step must be run to save
  the new tree names ready for the install step.

but this did not work for me.  However, I do not doubt that it will
soon.

Reading through the patches, I noticed there is some useful looking
help text added for the makefile operations, but it wasn't immediately
obvious how to get it.  Reading the patch is, of course, one way.

There is no Python anywhere to be seen in kbuild 2.5, for those who
worry about that.  It is coded in C, about 10,000 lines it seems.
It has a simple built in database which I suppose accounts for some
of that.  For what it does, it seems quite reasonable.  There is a
bison-generated grammar, presumeably to parse the Makefile.in
language.  This is the proper way do do things - much more reliable
and maintainable than a hand-coded parser, not to mention more
efficient.  Most of the rest of the patch consists of Makefile.in
files.  I can really see why this is a big job for Keith to maintain
by himself: the maintainers really need to be involved.  I doubt that
it will be hard, and by appearances, there is no need for any
particular arch to step up to kbuild 2.5 immediately, since the old
build system still works.  In any event, the 1386-specific part of
the patch is only 700 or so lines long.

The output that kbuild 2.5 generates is a vast improvment over old
make.  It's enough to see the progress of the make, while not
obscuring the warnings.  This by itself should help in cleaning up
the tree.

Note to anyone who wants to try this themselves: with the kbuild 2.5
patches applied, nothing changes (and the old build system is used)
unless you add '-f Makefile-2.5' to the make command.  It does not
appear to be necessary to supply a bzImage target, and in fact,
Makefile-2.5 doesn't recognize it.  That's basically all you have to
know.

Detailed Timings
----------------

Old kbuild, out of the box build:

424.18user 29.65system 7:07.94elapsed 106%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1552796major+1856222minor)pagefaults 0swaps

touch fs/ext2/inode.c incremental build:

24.08user 2.04system 0:25.94elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (114294major+80954minor)pagefaults 0swaps

kbuild 2.5, out of the box build:

341.29user 18.71system 5:54.87elapsed 101%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1080599major+1427293minor)pagefaults 0swaps

touch fs/ext2/inode.c incremental build:

13.75user 1.76system 0:15.31elapsed 101%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (122776major+59338minor)pagefaults 0swaps

-- 
Daniel

Re: KBuild 2.5 Impressions

[Martin Dalecki]

Daniel Phillips wrote:

> Along the way, old kbuild did the usual wrong things:
> 
>   - In the incremental build, 6 files rebuilt that should not have been
> 
>   - Once, when I interrupted the make dep, subsequent make deps would
>     no longer work, forcing me to do make mrproper and start again.
> 
>   - Way too much output to the screen

Bull shit: make -s helps.

Re: KBuild 2.5 Impressions

[Kenneth Johansson]

On Thu, 2002-05-30 at 14:50, Martin Dalecki wrote:
> Daniel Phillips wrote:
> 
> > Along the way, old kbuild did the usual wrong things:
> > 
> >   - In the incremental build, 6 files rebuilt that should not have been
> > 
> >   - Once, when I interrupted the make dep, subsequent make deps would
> >     no longer work, forcing me to do make mrproper and start again.
> > 
> >   - Way too much output to the screen
> 
> Bull shit: make -s helps.

In that case it's way to little. In kbuild2.5 it's actually easy to spot
if the correct files get compiled after a change.

Re: KBuild 2.5 Impressions

[Paul P Komkoff Jr]

Replying to Daniel Phillips:

Thanks for numbers, Daniel. Maybe it will impress them much.

> I have only one point on the curve, but it confirms what Keith has
> been saying.  The incremental build speed is especially important to
> me.  If I were working all the time on 2.5 - sadly, I'm not - I would
> without question be using kbuild 2.5 simply by reason of the fast
> incremental builds.

I have almost complete kbuild25ified tree, 2.4.19-pre8-ac5 with addons, and
will make it available later today or earlier tomorrow.

> Note to anyone who wants to try this themselves: with the kbuild 2.5
> patches applied, nothing changes (and the old build system is used)
> unless you add '-f Makefile-2.5' to the make command.  It does not
> appear to be necessary to supply a bzImage target, and in fact,
> Makefile-2.5 doesn't recognize it.  That's basically all you have to
> know.

It is IMO needed to add here:

- kb25 makefile.in syntax is much cleaner and don't require to contain
  extra crap, .in files are better maintainable for patch systems like
  netfilter p-o-m. and another one - $(c_to_o) definition allows us to
  reduce size of makefiles, and unnesessary handmerging of some patches.
- it is very stupid do appeal to codesize of Rules.make vs. kbuild25 core
  and discard kb25 based on this. Remember - efficient way is not always
  eq smaller code (one example is bubblesort vs. heapsort). Here, in fact,
  if we'll bloat Rules.make to 10k lines then we stuck due to make 
  stupidity^Wlimitations, but if we use 10k of C code to build a program 
  which (with many other things) give us ONE makefile of whole tree, we'll 
  gain here - we don't need to invoke make many times etc.
- it's not very efficient to try to improve rotten system when there is
  ready to use better replacement floating around

-- 
Paul P 'Stingray' Komkoff 'Greatest' Jr /// (icq)23200764 /// (http)stingr.net
  When you're invisible, the only one really watching you is you (my keychain)

Re: KBuild 2.5 Impressions

[Ion Badulescu]

On Thu, 30 May 2002 11:45:14 +0200, Daniel Phillips <phillips@bonn-fries.net> wrote:

> I have only one point on the curve, but it confirms what Keith has
> been saying.  The incremental build speed is especially important to
> me.  If I were working all the time on 2.5 - sadly, I'm not - I would
> without question be using kbuild 2.5 simply by reason of the fast
> incremental builds.

There _are_ good things in kbuild25, no question about it, but that's
not a good enough reason to import it wholesale. Especially since Kai
has proven (and continues to do so) that it's possible to improve the
existing build system, to cherry-pick good features from kbuild2.5 
and add them to kbuild24.

> There is no Python anywhere to be seen in kbuild 2.5, for those who
> worry about that.  It is coded in C, about 10,000 lines it seems.
> It has a simple built in database which I suppose accounts for some
> of that.  For what it does, it seems quite reasonable.

Are YOU willing to maintain it if Keith abandons it, though?

That's the biggest problem of kbuild25: maintainability of the
configure+make replacement that Keith is using. Enough people know
make and makefiles that the existing system can be fixed or at least
made to work reasonably well. Not the same thing can be said about
the 10000-line brand-new make augmenter in kbuild25.

> The output that kbuild 2.5 generates is a vast improvment over old
> make.  It's enough to see the progress of the make, while not
> obscuring the warnings.  This by itself should help in cleaning up
> the tree.

If you read Kai's mail, he was actually asking whether this is a
desirable feature to add to kbuild. You don't need kbuild25 for it.

Everything that kbuild25 can be done with regular makefiles. You can
get out-of-tree builds, you can get correct dependencies, you can get
a non-recursive make process. At that point, timings will be _better_
than those of kbuild25.

Also, for those who can't read between the lines: Linus is taking 
(lots of) patches for kbuild24 and is ignoring kbuild25. This should
signal something to people, methinks...

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.

Re: KBuild 2.5 Impressions

[Thunder from the hill]

Hi,

On Thu, 30 May 2002, Ion Badulescu wrote:
> Are YOU willing to maintain it if Keith abandons it, though?

I know two people who are very serious about it, apart from Kaos.

> Everything that kbuild25 can be done with regular makefiles.

Do you know why? Because  kbuild-2.5 _is_ regular makefiles!

> Also, for those who can't read between the lines: Linus is taking (lots
> of) patches for kbuild24 and is ignoring kbuild25. This should signal
> something to people, methinks...

That means no one has prepared the Linus style patches yet.

Regards,
Thunder
-- 
ship is leaving right on time
empty harbour, wave goodbye
evacuation of the isle
caveman's paintings drowning

Re: KBuild 2.5 Impressions

[Daniel Phillips]

On Thursday 30 May 2002 23:55, Ion Badulescu wrote:
> On Thu, 30 May 2002 11:45:14 +0200, Daniel Phillips <phillips@bonn-fries.net> wrote:
> 
> > I have only one point on the curve, but it confirms what Keith has
> > been saying.  The incremental build speed is especially important to
> > me.  If I were working all the time on 2.5 - sadly, I'm not - I would
> > without question be using kbuild 2.5 simply by reason of the fast
> > incremental builds.
> 
> There _are_ good things in kbuild25, no question about it, but that's
> not a good enough reason to import it wholesale. Especially since Kai
> has proven (and continues to do so) that it's possible to improve the
> existing build system, to cherry-pick good features from kbuild2.5 
> and add them to kbuild24.
> 
> > There is no Python anywhere to be seen in kbuild 2.5, for those who
> > worry about that.  It is coded in C, about 10,000 lines it seems.
> > It has a simple built in database which I suppose accounts for some
> > of that.  For what it does, it seems quite reasonable.
> 
> Are YOU willing to maintain it if Keith abandons it, though?

That is pure FUD, shame on you.

> That's the biggest problem of kbuild25: maintainability of the
> configure+make replacement that Keith is using. Enough people know
> make and makefiles that the existing system can be fixed or at least
> made to work reasonably well. Not the same thing can be said about
> the 10000-line brand-new make augmenter in kbuild25.

It's quite readable and understandable.  I must say I find it easier
to comprehend than the current system.  Part of that is the extensive
documentation and another part is that appears to be well thought out
and constructed according to sound software engineering principles.

> > The output that kbuild 2.5 generates is a vast improvment over old
> > make.  It's enough to see the progress of the make, while not
> > obscuring the warnings.  This by itself should help in cleaning up
> > the tree.
> 
> If you read Kai's mail, he was actually asking whether this is a
> desirable feature to add to kbuild. You don't need kbuild25 for it.

It is one of many things that are improved in kbuild 2.5.  What about
the speed and reliability?  Old kbuild has got so far to go there,
are we supposed to wait while more years pass in the hope that it will
ever catch up to what already exists in kbuild 2.5?

What I do not appreciate about Kai's effort is that it is divisive.
We already have a clearly better solution, and Kai is holding out the
hope that somehow the old ugly duckling will turn into a beautiful
swan.  Meanwhile, countless hours of build time alone are going
straight down the drain.  Did you see the part in my previous post
about the 41% improvement in incremental build speed?  Do you think
Kai has any chance of achieving that?  Or are you willing to wait
years while he builds kbuild 2.5 all over again?

Let me put this bluntly: holding back kbuild 2.5 is slowing down
Linux development.

> Everything that kbuild25 can be done with regular makefiles. You can
> get out-of-tree builds, you can get correct dependencies, you can get
> a non-recursive make process. At that point, timings will be _better_
> than those of kbuild25.

You hope they will, and when will that be?  Two years from now?  If
ever, because you might be wrong?  And do you expect that no further
improvements will be made in kbuild 2.5?

> Also, for those who can't read between the lines: Linus is taking 
> (lots of) patches for kbuild24 and is ignoring kbuild25. This should
> signal something to people, methinks...

Yes, it shows 1) that old kbuild needs a lot of maintainance and 2) not
many have taken time to look at kbuild 2.5.  I highly recommed doing
so now.  The time needed to download and install will be paid back the
first day.

There is exactly one valid objection I've seen to kbuild 2.5 inclusion,
and that is the matter of breaking up the patch.  Having done a quick
tour through the whole patch set, I now know that there are some
easy places to break it up:

  - Documentation is a large part of the patch and can be easily
    broken out.

  - The makefile parser, complete with state transition tables etc,
    lexer, and so on, breaks out cleanly (sits on top of the db
    utilities).

  - Executable programs written in C.  Each one ends with a
    'main' function, and there is the natural division.

  - The remaining C code breaks out into a number of separable
    components:

      - Utilities such as environment variable parsing, canonical
        name generation, line reading, line editing etc.
      - The database 
      - File utilities that use the database (e.g., walk_fs_db)
      - Dependency generation
      - Global Makefile construction (command generation etc)

    These tend to be common to a number of the executable programs,
    and so have the nature of library components.  They can all go
    under the heading 'lib', and further breakdown is probably not
    necessary.

  - The Makefile.in patches seem to be about 30-40% of the whole
    thing, and imho must be applied all at the same time.  However,
    they break up nicely across subsystem lines (drivers, fs, etc)

  - The per-arch patches are already broken out, and are short.

I think that with these breakups done the thing would be sufficiently
digestible to satisfy Linus.  Now that I think of it, Linus's request
for a breakup is really an endorsement, and quite possibly Keith took
it the wrong way.  (Keith, by the way, how did I do on the structural
breakdown?  Sorry, I really couldn't spend as much time on it as it
deserves.)

A general comment: the c code is a pleasure to read.  It is written
in exactly the 'Linus' style, that is, it follows the proper
formatting conventions, it is internally commented only where needed,
and each nontrivial component comes with a substantial introductory
comment.

Let's see if we can get this thing back on track.  The payoff is an
immediate and substantial improvement in speed and reliability of
system building, and in my opinion, a build system that is far easier
to read and understand than the old one.  We really owe it to
ourselves and Linux users in general to take advantage of this
superior work.

-- 
Daniel

Re: KBuild 2.5 Impressions

[David Lang]

On Fri, 31 May 2002, Daniel Phillips wrote:

> On Thursday 30 May 2002 23:55, Ion Badulescu wrote:
> > On Thu, 30 May 2002 11:45:14 +0200, Daniel Phillips <phillips@bonn-fries.net> wrote:
> >
> > That's the biggest problem of kbuild25: maintainability of the
> > configure+make replacement that Keith is using. Enough people know
> > make and makefiles that the existing system can be fixed or at least
> > made to work reasonably well. Not the same thing can be said about
> > the 10000-line brand-new make augmenter in kbuild25.
>
> It's quite readable and understandable.  I must say I find it easier
> to comprehend than the current system.  Part of that is the extensive
> documentation and another part is that appears to be well thought out
> and constructed according to sound software engineering principles.
>

don't forget that the kbuild2.5 patch was a lot smaller before keith was
told to "go away and don't bother anyone until the speed problem is fixed"
a large part of the fix was to use the mmapped db stuff that Larry McVoy
made available instead of useing the standard db libraries on the system.

one possible way to make this more 'incramental' would be to make a
version of kbuild2.5 that used the standard db stuff and is 200% slower
then the existing kbuild and then after it's accepted put in the patch to
speed it up to where it's 17% faster (IIRC the numbers Daniel posted
earlier today) by converting the db that's used. Somehow I doubt that
crippling the speed mearly to make it 'incramental' would make many people
happy.

David Lang

Re: KBuild 2.5 Impressions

[Daniel Phillips]

On Friday 31 May 2002 02:09, David Lang wrote:
> On Fri, 31 May 2002, Daniel Phillips wrote:
> don't forget that the kbuild2.5 patch was a lot smaller before keith was
> told to "go away and don't bother anyone until the speed problem is fixed"
> a large part of the fix was to use the mmapped db stuff that Larry McVoy
> made available instead of useing the standard db libraries on the system.

I haven't seen complaints about the size of the patch, there are plenty of
patches of similar size.  I've only seen the request to break it up, and
as I showed, it's not that hard, so...

Though I can certainly see why somebody who is weary from a long trip
could react badly to the suggestion that they should go take a further
hike around the block.

> one possible way to make this more 'incramental' would be to make a
> version of kbuild2.5 that used the standard db stuff and is 200% slower
> then the existing kbuild and then after it's accepted put in the patch to
> speed it up to where it's 17% faster (IIRC the numbers Daniel posted
> earlier today) by converting the db that's used. Somehow I doubt that
> crippling the speed mearly to make it 'incramental' would make many people
> happy.

The way I see it, all that's required with respect to the db is to give
it its own patch.  Out of regard to Larry, who contributed it, even make
it a BitKeeper patch ;-)

-- 
Daniel

Re: KBuild 2.5 Impressions

[Larry McVoy]

On Thu, May 30, 2002 at 05:09:16PM -0700, David Lang wrote:
> don't forget that the kbuild2.5 patch was a lot smaller before keith was
> told to "go away and don't bother anyone until the speed problem is fixed"
> a large part of the fix was to use the mmapped db stuff that Larry McVoy
> made available instead of useing the standard db libraries on the system.

wc mdbm.c 
   1404    4736   32921 mdbm.c

Just for the record.  MDBM certainly has limitations, but being too many lines
of code is not one of them.  And it provides ndbm/dbm compat interfaces so
you can pull it out and drop in something else if you like.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: KBuild 2.5 Impressions

[Rusty Russell]

On Thu, 30 May 2002 17:32:19 -0700
Larry McVoy <lm@bitmover.com> wrote:

> On Thu, May 30, 2002 at 05:09:16PM -0700, David Lang wrote:
> > don't forget that the kbuild2.5 patch was a lot smaller before keith was
> > told to "go away and don't bother anyone until the speed problem is fixed"
> > a large part of the fix was to use the mmapped db stuff that Larry McVoy
> > made available instead of useing the standard db libraries on the system.

Of course, he could have used tdb.  I looked at converting kbuild to tdb, and
gave up after half an hour: there's a layer on top of mdbm which is 
"interesting".

Plug plug!
Rusty.
-- 
   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy

begin 664 tdb.tar.gz
M'XL(`%<5^SP``]0\_5/;2++Y%?\5DVR%6&"(34AV@^-L.6`27@"GC-F\?;DM
MEVR-L0Y9\DDRX'?)_>VO/V9&(UDV)'M[58_:#?J8Z>GO[NEID7K#W=&CO_:G
MWJC77^WO/ZK7ZXV?7];MWW#UHK[_XN6C^L_[/[]ZU=C;?]F`\8W&R_U'HOX7
MXT4_\R1U8R$>Q7"Q6#/NOO?_3W_$\RU1$?#SSDVD)Z)01+%_Y8=N("[<Z=`5
M_:-W-3&-/'_LP_MQ%(MY(N-DYHZD2.34G4VB6":[%01R&,T6,'N2BNJA(WK(
M,?PWD4%0$R?OSL1>O;Y'(QFVYZ;N$-85XWDX2OTH3):AM$,OEK>B'_O>%<`1
MN9_&Z]>O=P!H?7G>Z?Q:BH\R#&4Z$8=ND@!IIQ)?PP7]E,_[+QG+Z4*T@\"'
M*1L;&]9(_+\_\1,QBZ.KV)T*N!S'$A@1C=-;-Y9-L8CF8N2&(I:>GZ2Q/YRG
M4OBI<$/O.?".&+E`./!L'GHR%NE$BE3&TT1$8[IY?WXIWLM0QB"#3_-AX(_$
MJ3^2(?#)A:7Q23(!60P)#LXX1APN%`[B.`+`+K*S*:0/[V-Q`Q*#>[&GUU``
M:R!M!%)U4\0\%M$,YSF`[D($;II-W5U%?T:F)_R0@$^B&9`T`9A`Y*T/0AM*
MU)KQ/*@A"!@L/I_T/W0O^Z)]_KOXW.[UVN?]WYLP.)U$\%;>2`;E3V<!ZAT0
M%KLAJ%,T1@AGG=[A!YC2?G=R>M+_':@0QR?]\\[%A3CN]D1;?&KW^B>'EZ?M
MGOATV?O4O>CL@M))1$LB@#4\'I.8@(^>3%T_2`SEOX-H$T`O\,3$O9$@XI'T
M;P`Y5XQ`A>X7'P)Q@RB\(CIA<,;)IO#'(HS2FKB-?="8-%H6+$[/9`L&%8YV
M:^+5SR_%&:BW:-^`.`_!KLA2:N*L+>I[C1>O:^+RHKU;V7I>^<D/1\'<D^)-
MDGJ!/]R=O,T_\Z/\H_$H3(/\HWD(\O:*,V,_O,H_DW$<%J`EB^3Y=.J&RT_!
M!:>YIT]2"$N3)Y7*3YX<^Z%$+S0X:[\_.1P<=[M'XLDE/!!C/Y!_"Y_D!OW6
MZ5V<=,]%M7ZW]PH"R>M7/XMM\<I9AI0->?WZ,O_^N-?IZ$'_,A/R8XXZ[:,,
MT'&GT\`G^3'MTY/WYV>=\[[8-\_/3LX'O<[AX.+D?SJBNK>5^/\KHW$5>#@?
MI0),.QWPM0-XYX!DL(\ZQ^W+T_[@0_OB`P-JO&CD5O[4?M_A-T`D>B_]$DD[
M/;GH#_K=3Z*:7QR8/IA(%YR24T)']:[F.J):K=XA9E77V6DX8E/\J\J7^1GO
M?N]W>IW?<&RU2G,VZW?CL?/FS=Z^\U7='Q_7Z_#D%WP`3]Z^_<4\_<H/8/`R
MUZLQ`HV=G;=3]PJLJ]4J"*2`BGY<G/>X92G#YJ9X;"V0!T%\!H95)VXR`2`Y
M)@(OWET>?NST^>UVP]$R17Y&0+13J4"4/7\'[CN93V6"I@W^!:S?%4$T`C]Q
MX\:^.PPDA(X@`(^"^O]$N="$?=:6&,WC6(8I.)LPE7?@*MP@`3?A7@-$+P)/
ML]B9N3AB(A$!#WR+'Z8[$(0#FN_&5[!ZF.X*]`46>:?=]R0H6'3G;1!=#<;A
MKU7[3MPYM;HC#D2=20&DK\'=C1.9)C:P]Z?==^U3@'?X460JUS[LG_S6X:?[
M8-+^&.+>&/S3I\'QR6DGLPSU`*?*$.)D86P;WAWE1],C$.I-Y'MB"]4PFZK&
MV;*!D?S[J2#J6-EW\=D`6>942`7:_3;90C@/@B81#%+1;$]JZ)S!G<]!A&'$
MG)<[$/+"1%3)8Q)_4";ALU2$,DD?.\@E]'*@=KC$8?>\W_GOOMB"91+1$N>7
MIZ>PDAI!U"`"TWD("5:U.,.I_+.R`?&"130.W*L$#!%'G<"@WGG[U*EL;,0R
MG<<A0,V&`K#!+(WQK0)M/ZX)<T?,:%8V[-<&S6\EB/Z[T'R\//B\>P:R=AP!
MT(H(T;J(50'WFH"QE+J)3[UN'QQN^^@K@XY!YH,H#!:_BOH!O?S<.^EW'&L*
MJM;%AW:O<_15ZZ2"/_9J8`.([,;S+?A'H%GOBL\32%<0%S'&C`'3'B8KL=5T
MZ[S;WR(>BL?P0].?(ZBB?-"C9?.8\')1P'-MP`BA)O9JY#L&!AF5LR-3Q%-/
M5)\F#H1,36R!:1`'(&Y'<96BM^.@"FQ\JVQ\$S*`S*A$``J-;Z@48"<=L#U(
M?L%45-IX(&ZE0&YC2A=#2@7.CI*??4A?(<_YQQRR.C_U96)9"%LS`TF5;0_G
MXYJ8O]@3;*>`"M[X-;$U`S3@+6"!A%9]N*U#.B7>,-'/Q3[<;6^CKLV^^'^(
M5BY`X2,DD^7%@+YE@;8+"OU;U2G187S1Z5E!63T@3VKF_2HT&9MW-:'BPIV#
MOG3SCITIYGG#R#/YH]D4@>>?@G_"YQ'`MU(#$BF.Y<T'[L4P.9P%<PPIB80P
M`+D[0:)I-%ZZHXE`5P?1)IA+YG<QZ4`9J[`%GNLN;>+^D#V]Q@\?8^X;Q2;A
MIS4`'DT-).Y^1OB;9J=1"D(G:<.C*Y`]`%+S[3G7<F'F%$;#J]Q0)&S56"(:
M!Z-^P(XC&"#-C`ER#)X(>#,$&R5F**KT$CB+TH,F,!3GQ`OT]R,W!>Z1<9"F
M;FAP41!$MY#]PF8.-U@@,[5E.0!]XV=DOJ.)&RNJORCN_$'VF_%=CP)4OBAF
M\!!^C(1]T93SBV_X#V),/$;M:H*FHM63CX?7@.HW%<*84;"+NI(4H!!IO>\6
M.\IAB3J6`)+Y:"23A+>7N,?5VW..;,_G(4>X!L.$+`5YD<SDB*L$K#!<$^B&
MS+::(*="60_F+:A1F+Y@CJ/XBIO7&>1(N+=U(<.`O=%,QH':YL;1_&I"T09C
M;=6A-`82''HTC!&CI1!4$UJ9&27R>[S[QYGQ[2!=S,#QX4TPNK;N8.TA^QEM
M<I3TC(-<0,W'*<QPLI`&7L@::<(.NW/F14MTVH>'G8MF-FFG0>X4G%FP&Q`^
M,$KAV51/;R'<C/#Y1:?S<7#1Z>L76,I*X3D3JY^BQ;1$0]_.P)VBBU1T4,92
MU='-,&%S'*B02V&9V<%:FH\X+VM/,@'HD..FVFE`S%'8M^!2@X=K*PIIV1AQ
MZ&$F`*&Y,<L0YG`A.,]"0]2,0ZPZO=YA]ZA35=>4<M:`I0[QU)++MRR-51Y2
M>3+M?'?YZ4Y#Y=^8`48CX^A4H-+:MT+W2*M@AKHBBG1.1)#>X`)?OS+8MRT(
M7F'JE&>FQ/H\Y^O,>5S\`%8`KPZ2)5!/.>@'15:#VC,^0<;=O-X]7+5+=3L/
MC[SDA8^Z6IX7US`[\"+>!EUG4<V/@0B(>;4*HNR&'D1.\*H+",_3&0T91?.0
MP]IXGF(F#J/9,1NL$*3TOB#!VXT_=GD&9%;U3*TMSX$<M;=UV_M;Q"KB5.T8
MK>STXV?,_DJMH*[R+J)CGL@INE$E"V(_7C/#<QPGY2Y#-U"F'RC#_U8I'494
M;6\WEY6;?71.J0],5DHYU5".W#GF&>DST/$HHH(?IPKDCW>+*1D2R&"_4]GO
M52BM*V[HIPLQFDC4$RW-[S65\KU/&>-:K;H]>JU&WPL,=:O!R@&D'$6W(28.
M@9NPKH-79$M5@J'B;RA=R%K(C15T490IHS@>7)Z?HD^S%?(>[=C9T2I!I5OX
M;ZA+_52LQ23(O8IBR,JGD%!&4W'E#:>6["G!P-(0C*R:#?(6I"@F#Z>,LHET
M7R)H3)BBZ0Q+WV8)&K(K3)(%$3@_83$*I`GSD*9X@`E-8D5D!9&<:OB@)S[5
M33"3):1U$H<J0!-X.\`C6E@&>_'+<>-%^QCV;#!NYZW'>QZ_I78+V4.S7]"3
M%91M4>5!L/?!G<2;-Z"&6R_%4X%U*MH6*BNL-AKU%R\;+_?V7\!R>G9C[\7^
M2P<22R4/TG,R.-@S8=D;<M$A%G@A%:($#-(R4#F?BD#Y]T!MB&E1`OF_7]@W
M`+O!MB'HR[L9L)%."B#5FDK<1=!&#CTJOZ23"$SU<3D7<EU\$$:IJM\_@=SA
MB0Z!4^#Z=#[5N78HI:=VE[3\L+(<&*-HN"8G`T`KDBT$`_\HD\0$YDVK4)U8
MD6>5EAD>DL>H:`H8(UX80H=R$86XQTG!4$'9IIP#J*TT>G5.7\@5$2V94S)H
MF@QF39IRTLV2%)64(0-,4B8V(7:@>\'ZUL,@,9@DW<6='2+\AHN]`\+TSS$$
MMK"8X*UA0;;N#]"//@%K4[#=GWD8D=A.8SQK-+O`K'R5*U,1J2V1K=]4PZW!
MQ4#)!RZ0@F!NH3>00)^[M*$IR?QH\OIM1TU8%0R]@T4A6-&1#(4FXJ1MM@Q(
M5!YCNE),JDK+>7(ZFBVJ/+M*^\4MQQY4$[0^KMO$LBI653^T?^L,/E'YJ[)!
MC@%!SY@FHWQZ'N%&*%63O"K]A',M"/!;7F<`B`=ZJT(`X`GNPR"<KUAKQ3)4
MV5VAIRS&;/^!NPT9MJR:E\J`"1VBI[3<]4`]75(C3!D>I$4U<"2+H=2%H1*E
M0E#+.F6K5*91ED+5</[HYJ_0*Y++.N4JT2NLN=IJ153]9[2J?*D?4"H2ZG].
MIY!,%.#&AJX:6D;[$(VK\3X5M"F\4C49[-/`&.W;FL8R1`II_`J-6RJ>%+T7
M@Z&:J2[?PPW6Y0DL!F['6;-US1;7P57QNIS+/\3@;O>,5,!BL;$Q;1E$7*:1
M=1UL"7.LL585`+V0*7L7ZL9:+,]U4-$<S!MY-$Z^A^4$P"..J^7**2#3W'(\
M4VB&2353PW80P0(2#PA?95A8KT'86UXSAYCQZ1EFNC:.MFYCYY0R+2L.6^AB
MT?2!/"LI:V_!])QC7.8>C,A0P^$UP[FEW(OV[@BJ<,`,LU:HNT8?-E\>%YAA
M2_+T+JN4Z3H-#%0'U!JU>U7\L-OK77[J+P>G7`0@P%B\W\X121O(;T5./U0Q
MUK&ZY!T>&>'[!RM,G*E+G-<6T!.T3*H'*(7!;4VVIZ*2D;1J]@42<?8#-.H'
MU.D'=2F3O&Y-R/I0UFB5H>->U5)NM*!A/Z!>2]G%:MTJ2S66:U6<Z!O+YR,,
M49W.0;B3*/!,6,.J6C2Z=@KR9``#GG>_VA(C(,0FZ5KAZEG9Z0IO3[K9>1@C
M2@4(A3N7HWBCHN?AEL3B"V11Q#!]2F88DKEDRQA@=`9H1P-2N#E,RZ89X=CG
M\X8`^.U!FC!@'.]ET$KS)<LU4(EXN,26"+JVLLA5X0DRQTW;.EA/BM9!VD[M
M*^/J$]#!;N]`IP9IQ.:O;1ZRLCEIMT+=4N:ZVE%J0#CGP-C$G$XR,<U0<L!+
M=>Z&E_JH#:_-.6*++(N,ARXY.U'=J%8DV0VI0P>O%'2^4?#Y1J_`=V8-OJ4U
M:">?\=D<[8!.6/QC?=(++>N(\B\FZV")6]+;5&>&#^>^4OR,^QDX6P*:$U9I
M0\T$MV#CG*.G%`$USXMD@@4JD`&>R+(6/%9O4:C&$EHYS&IKELO%S`SEDCX7
M,B)08S]<40'W<XX#E^/&FFA&DHQFJOW`=)3Y+&)]B,2`L+[[N7=Z^-%4<@JR
MBV8@-`4])S6K1+\,RJIT:VEH&!:_2<U5Q&#L;B?`P6PL+:1N1&O)N>B`0&--
M;7HU5H!*GK_@ZU?T$B&#39]'J][TWY2>`#2Q?&O88<F,%U=(:7IU%G$`%*MB
MTM(<BGPVHCQ9S2S'EAI]21LI1/.9ZT9:2*",BN!!`5XU5WO>HI[L-/**HD&H
MI92K:.6.$E0((R-69YXFC4+UU(<N>873V);J7$ZIBEQ%H*TOX"KKO]S]H1-<
M0A)Y7:99RP'$\.A[(TB&&N&F-7YW;9)E2,BE4X`^\HLDB71I4HR?7EY-PY$A
M-I&HL*-9D?='+:&>PY;7<PR?5D41/8V6M51L.^=459N:F$8WIJ'<;MY1I^?:
MCG.^VB#/W3OK\.2BMT&BQI^36#^%`<;AV1XAK\J<%?8D8>Z&0@82&U>S@QZM
M7;M"G%&.B/WXZH@>8.XNI?L(:8#3!RN-MI#UZQMD2<ZI:RNKH2^ZWY@LH\S;
MH5;^O*5ET#=]2IYW&MB;[',>;0S$1S6GRAFI+"#Q63Z[P4K/'(\LTL<LW16)
MI;4(D6=U61Q30Y,@WR>JI"[*CV#C#IW,Q&G6P>7P.A:1/NM/R59E608'%,GU
M23GO5W3HT3N3!V],6&G:GF=K#$@_*FC,F8RO0%F\O[LC&6IC2(1/'Y:$<J1.
MPHHZA.*G4M"?VQ2;U``_.,)ZTSA56M3.MCBXD57Y#IT56WT-*]Q_>447H*+D
M@!_ZP%0G0TF$-=5;+IAS%P8V9022#$D,HZMY8ON)_`:K6#=QU&*G473-E*D>
MCNK)LRDNWP8CC=W`=\&!>>YTZJ>L.#QV.:M=L4TB_TU3"B.73@?)+,KB:+-2
M'F)8')NQ56Y8%53*.S]0-PX4\<6R,2>B]$[U@%Q%V!M`PE?1`MAW,N9>#':C
M?$"+CEM_%>-SZ[Z*8[NYKQ^6HAC'NA*_9],;D\?/D_<`^BC8K*4O3R`W*MK"
MQ%!E&(V"SH(6=QQ7*CCY(%,KO&6'BA=&959M=FC4VWRN79HLXJ<KJ[0E:*H<
MDD^KQZDN`FQ0>%)>7VV%0%9_QU(\M2X"\58AH"2C0FB@;QKHPS6,"%/$E^L9
MCK#5C&U7^_@B^XIDG8/WUP'-3A26;4:38$PF^"&3(826*($$8^X8<FH&S56$
M_8`%!7_*@A1:WVM`1&VY_5AR*])G=^!O9(F]L:\EV\JDJJR/;8HA'K")W./3
M;9K6490#LTR57<,FJG!$=M0/ZE83LUC.)$O*)-@<'[*2:%%(Y3MC.\7B[0K7
M)14UXNM7KM9D->X5=)N1A=2IL("B[F&\TO94/*K.5VGO85@;^'0KG\44LE6G
MT_ILVF[:)&`'#YV!600LBWF5LB67/KJ$M!M2!I#:&+]?CK#A48S!98:0OX#=
MN8GY=.T6?\^BQ+^#["IQ%XD9CE_98D<'`::/D_/Y%B\XP.76I%S<&Z+O7,_S
MZ?ME<S@YG(^_-.I[^W_0X32?3!_W>Y?GA^U^9P#P.N='JN5&XY\='"/P;0/3
MRL"716QAFW$":7UJW%KNTQMLW;*AKS_75,VYZD2<"5,]W&6M'&5='&(3,`4A
M5PM$[6#/XF/5N:@6*#EM+YE6.'TO&8%'\6Q$!60(%WO9%6?P>;[^V[G)'PJB
M4840],;XH3JW'\-B])$2-LVE$_RVF7LG^:L_I=UFJ)]@ZIS,W!@_J(==W6@B
M;NDS\:$D\F\D[/^QFL`I=YQU^WE^<JU@TUG'D*V:5R>FU6B+=..[;"UH[5,Y
M!0?!K0'UN_T]$W_QD-JJJF2RH%TCV!1NX/73M]:D7ZWK`SV@O$UH@_?3&'U*
M&X5"Q@:;05B9](2FCKIYQ6(#SFF2;N_+-TKSFJ5+TF)*A3AHIP@G7)E\V%K%
MSAADL4*W4("K%&JYE5LS3^S`^OB03FVV^:;8-63YU5P#ITL;,3R<PLGXB4V"
M+9P\5'=V4/]PL(!;W+<2*0C(B_0`TA?W"O?QN0[/Y6TM`[['RS[L3$A_>7+O
M?G5MP+0_)?%#"T<LT9:8,MDP&=`U6K([1//"/V$!(>K&CV`K:Z(,<=(%F\(_
MBS&+(VJSU3'4G&?F-I/8N8O^2FURW>`6X]C4O093CJ(I-_!JD37J_,<C5%FA
M1D*)L2ICE\5RXI[/T+6!@<^#U,<C:U#&_#?\B)\Z1\P^QR_BB+^V&L"^W%QT
MQ+F1:[ZT-?VRCMKVY+HL*_3)J\!*$_-:?0-M^4%!XV?8<2S']"<TE#;Z"<W,
M/IS&PU=0(AF.%LK5+N!NFH!J`5N[D`V^NS@"7RIC23/)2A-B)NHU?RN&GM$`
M2G<K&Z9/W+(J1BU-9#`V=92UM)L:FYV!+&N%\G.F\+*4JQ7DPWYMY==C]B?1
MJ=5:1X59[J9*<QUW^7I'4S7*_;.2?9F\1D[43&O)"=V6W3'&`'Y07`^7E_X`
MFLN7^!7/M>YFM[ZFAG02$EX(SF/@@]Y=6PU#YO,)N\M7.06@;@JF%<K;I6X1
M*Y32><*SO]6?U0K'@OD:??X$WJI[!7YX36WZ=K4QV\68_5I>)7:41AA72>7%
MI?,6JV/$4K'O2/I_*.?G/WH041J+:9#N)+0K\((+JOV)S`H2"`/_]`08?LH?
MD*)K@WPX"B$$T5<P5O!`72I\><?Z93G6"G7^H6]5'QYP0(Q47P9-I"]-ZZS9
M"@.E1XSVB-(QU+^A-'2!1\YBH6EJT&V)[LK^)]4!":CHQL2'57R+)WTU5$OU
MM/S4C]\_.)KF.A](,3MWZ?^U=[7-;1M).E_%7P%K*PXI4S3EO%V,T#E%EK.J
MLJ64)"?K<KFTE`C)L"E22Y!6M([WM]_TTSTS/<"`I.SD[G:+J-V*10"#>>GI
MZ=>G)WV9L$GVCUD^L1D;K*VS/0VSZ@URWI+68/GAX1POQL=X$ZM*NO8IENG\
M/N7K9%?)<#Q^RXG64S99G^>C6!38:7YAV!:RB.CS=2[&,`0L]#.&NR[LC@_5
MLHSA44_(P3MCK!O&['$22(P"7.2GPQM#C<,<J%CFS!</3;4Y2^?W`JP@:UPB
M>ZA+=H<UZ2HWLIVT9E=3"PI"JR4P(8R%#9FPZ7(K9J`78_+(A!S,7$R+BAOJ
M3N.)M4T'*&3M]S(OJ6K!>QOQKXK)GU_QO2-[AY@(&7*@(!"NB3E!LH'M6S!_
M/=>$LYM5/]_E#R@OHV4*]CM53J<6K-Z?5K8XM;PYSU$04EPXY(V-Q`\I"1:9
M]G(>DT-F8O8/>E7VI^J+^($Y+DB:O<X-\W3'2"NYQ+(R?L&\)B[A#P/7G5$D
MEV'(V&=L9*+&.O->;QZ_[H_>%B7<O%;'.2!+%CPQWGG*UQ-9MP,C$_@X)SM8
M<F:V[S3#`7]*D_&#6B6_XFKSR,17UMO&'%YG\T9K+T^"^=2-M<ZJ6CNJ\K#@
M@"5RH^%HX_M:1$;PHX,;]WI>XVMB(E\3+",8&1SF`P<&N"_Z9*>U:D!126C0
MD5YRCEE/\MRP`W6>J#<#]L#;B-5F2M,R6R(?D*4%?%\X/([W#I#]V+A"V(M>
M^H?YQ>O5HX%ZBE(HL3U81]8^5E&(Q<XOS%CSJ18GDMNC"BW<5M!RT:_BFZ7M
MRY)J*`KI#")DTD)XK&KQYLT3^V9-=)K*D?;*_-2AOB4;IHW!:<J15C;MC@17
MYTXFG8(47S["S+09"7H\N6GS;+(\;NZ1_LV`ACY]4BFQM;!SE%_D.AE!4DNM
M_H:.FI;.6#7BOFZU6@OR(Y$,LNE4^2=D\K.@E=Y=A\8W'UG0S)X&%DS=;==/
M\X`//7.W&>N@5Y+QYR6HAMJ!>[.L#MH@*+M6-D?KKG)O@CO0JOOYL[?8?F(&
MOR/Y9S3XOX]'9(K\P@&%FN[VB[?90%B;#<=G`JG&V,8L>UUMUHN+=C5V]^X<
M41"V4F;Z!0(]@#BU*?E2F8V_AA,B/Q>_(AWE-#X,ICJ6CYA`9/@3,PJ_SZHK
M3KOS\7APQRJ9U+S0!>Z>T-UV"=421D;#;IKASX0H*`14LGZJ+F+&5%ZTB#B)
M94DX-MR`'<^>^E@K!H8`_`^]TP%RCP`!M1,71V0CWYF9LWF++.?0]=AE7*-5
M$=N.\"4'*/`VNV&$+\1`-]:B'OF-24RG,D.JZ"%@E?4Z2!76,:J)E/2I.8H(
M?=-&?[AS;I[R$=,[]`&N/\U<3P-@WKV+$?9Z$T,+-G*<?C73V`&*`6Y)O'E+
M@5!MO$VM),">";+A&-WD-=05CNY6@%AK:V\ER%>E"NINZZ/1HN@AS<1_W8E[
M=]ZV1&!78\,=VB275TWT'G-AQ%HWE);";9&$O+>M5+>DA`@.-E$/?0@E"RU7
MS#DJ]@]V_V9T5)L?U>#H`C,S-R2L$W<WW3,[@Q..Q"-D>!/6@?`:1AD_S9@<
MD0/;O,_W(KO"[@./=&>/OJG'^:`.*"(%PE,)`J_T],ON*P=N40(SP>W\WM8K
MFFO^]%K0]-RY8J0E/U7;A=OS;>`]FZ\1-#882C9H\TX"=IP$N-5PC#ILI9!M
M`'+&/`BP'FN4F6N5<8S&DTYC#6O7\V`G=PGC1$V\6C)T`M,41Z)0EAJ-0-IV
MW8PR&9%NPN!Z,$ZTA+&Z7K><G5X+FS5?TUQ?QFM6*AO-+NV*'ARRHP5>KFA$
MNT_9VWQD>-P@TSD22I@C%UG_$L;HT@?X+4F]8FZ4,7JT:2HAH_1+`FA\G[RG
M=XZ>$SC:43M9/^)S:/V#3;9Y7XD!7=\93R:SJZF3GB,/4[+U^MY!LDMCC-QG
M*EY_*NAX6<UCD"+7#]B%RP)PY"FP#^K\(9\'V6^&#F-#L+L'WY7'`,0/'Q7M
MR^A+PIYL\RXQ!@VL?T@$]P]C37B2'5@+4(G,4O$0:?OI)7%D8-Z*4X+E2#'$
M37,0T$*VDOL1.5](HU7E0B`-VA.@@OQ5!S]H)N1N6(JQ-];W!/R,1T/OK9=3
M"TE2)&7/2`=70S();S*[!C;I]7CRMK`68ZN!H?>0:@K$EY*5>SCPMQ+K8:*3
MDE<-AA(1H&9P`HI)/0*-PQU;R-G<7P-RSB_E@_5GH??5.P5.E.<I.X)K^8UB
M7^B&J*_BD=`\S[5L`QB0]R+J.=YE*`P?TFR_J\V)W_O#WL@3-%;W1QE,V^M*
M0C*)XA7`^=P?3]EI=H-UMR0NRH3135.5CA;F'U=D&A^(['+W&A9"DKL):<7W
MN*R[X'/\+34L27^S&8`.-DQ!WKC\#/>4&:IOPL=$U-G0[K*'RMM`G5Y`G8K8
M*>3HF.ADQ%;,=*$4!S;"J]T5^'(N<BKDT+?"I"-FD%DV/7N]@/YKA/W:+>#>
MG6133?`<E(/C_71FSN^I@&HIN\_\74"$_.3D\#'M@<H6@/6%L<+I)Y#$LC)S
MG+Z(P@+Z2*5E,0WH>^DM%A(#B"\DR[&D]]<MIIQ,C1`B;"OF=:/U)MQ8N$%H
MZU=\<W12G=NP"'!B.L!(H^;$3@9Y-$KUB(%GI3.3K!`@8@J9&@]FPTSD2RB@
MA#IGN.RI#>`B)+N&@HGE(2Q#=+4DIMRU43[)-.(]M]V2A/?1:[7ET0]PX$-P
M+HR&:Z8N&V;3K`0IJ,X;>G2IW&\MYM%//VAP7>N95J/4,(14'H"Z>'_#K,2O
ML`2R#6QLM,Q)3D#65&#F>B1@H+0I\`"R483\I@G%$-`YNL\4QHB%EUF?5G!,
MYXM\LYUL&!K:4%T@BP\%?YN?&XGG_&(_@FM+X`,Q=?PA,U&)GBHPTI/;39B2
M;Z:3/IG0N(5D(Y"1V+Y$3V#81@0BH:F7Y.(P$FG(_`E<%<[O*D>9*983618Y
MI-T4N;RH_]4)K<XG$_RM2;!FE"$&IE4[B==74&9-3PASLX_$7>X%R<$:#?&+
M,CC(;3L[?_E)5!9\4`^;*PM<Y@V?3BH5/-BFQR:MW\T14%$4^W"1(&?3&<0I
M830+SONI#P@)9W8P/N$6YLRJ$U^J'+@24A&D8D83>/H4MWD61%TI).X*_%EU
M]^M3.XA:)#12H2)9=2(LV@,/S1$V`2_K$VON^TS;T!/J"]8H>_H\ARC;K&([
M*NBE%GQ<`*3UGH]8"N+\SB5,H^BU/I@H+34*80/B#5+0.6O5BFV)3A)M@YQE
M>3J:ID/3:$X)1OQ4Q#;J=`\S&QR"]9!=C?25:+YJQZ,*N][(/E3=FS<#J9^R
MY2,`ROVESKR3VF\<H:3=C]['6^,YGH>E\[R@`'7A0P(YW#5C,N20D^%H<\O\
M(8C\;&'H51V_%=?B;],Z0UP]]YLB.`'6N+D02G1*F-,(7R'_%MYCSH;@RM1F
M"MEA]8=PWU\78E6DQ&<IG&0M;V0U:;9B@.`EH^D\<Z9W%+)EA@IH\,9QP2%"
M7B,-.9PF,@+LM._CI8:"ARQ<1=5VJ!Z*A7N%A"6S5-KS/R3)$7K9YY@LLQ<P
M")4)=\=/N<I]F\,55+=:5E\QUUW=3CQZ(TQE(S`E%[NB$,M+0[`!%A&FI[[(
MMGX9DJ,HG2'/.`'>B47V'&[L87(QZ9\R\PCBLC3JBOO4W/@4"IKP%!R&,OA$
MQ6F&$BT6[]KS8_89-9/*DMA#3\J`I9_:R9)+R>'N\%R-QZ_'8U3O827.D+C%
M%%A;M`A>,7:_>\<,^7"EILK0"*%\0`*]'YN*EL3RD4(^:`N?]<H-UL_SFA<U
MT$-IPIVC%G<_4,6BFXT>UNRIZR)2?LV$J2(*B-:3/.>VA"4=OR01]$<W2"&2
M?,8HTW&&;C`[%T:B1Q=3'>OZ6XGD=<<![2W2J"=*9ML$[X1U>*0T6;K?(F,F
MV)[@*<#`Z9K'7:@$8E:6<X1%3OM1BS%^CNHX*'^%8!&VP"`F'+P;U3'-WZ/-
M?V:3L?V*0G@WW6LE-*MG</Z[)"Q_*DAU3E**&XDN#V/[4B-WNH.+"MV8[UC(
M9CH&.58F-,H.N-Y4K8V@]DPTV@EY-[AB6=?\CZSTUDS;#O4$&^QPW7?6#QLI
M],_^E)+<^J?C=V+^H+M[AWM_@P6$K*S(FACD'/2,*'W*?4[.)J\Y3<)05T<H
M.M0U!`.&1<@Z?>HT0Z591U?YJ"`%W_TM"37E9J'9V$B.0+!@HWQA+08C34[6
M;,3!!OFT4-Q2'.S-B8VO5[(*EM=\SQJMDT?6A^RU))O\Y]S>J`^E(]6L1[K&
MH&>F<0Q<Y`"-R#K!E5E/C'S:HB<N<?F`8O/A)N]4&5+\).PX!AR?>UER';;G
M,]>\_;VGNTVWG9W;W'+3<2_^5-1`R?/\F"):>>DX;)7V/4+%7`;'PH$C8FA$
M<0XALT(B(&]7?^`?D_N=>'<R0]XQ55G.1SAV'<N8(UC<9CHYW,"NI)YAT)J=
MY,IC'^KVB6_<9C1^7\71]'9]]25EE_?%=.+J.G+3^&7:5E$K/;UN;L3]@)HM
MSF&(HO-0%D>&O#PZY1VR36SRPSF1A:C^6N5>XL+7!8JJ+"%XQ=IJOP_M,=ZH
M7^$1-C2F?LMXIA'A&=5AW-/,PT>]U%N+(X...FJP+"6"`(%%Z<&&>9$L4$</
M]':,')0)W2RNK@UC_D0%OI!:++?F&:X]225BR9=(A?!<V*`::L@Z9LV_C:JS
M=YX4X[8_B6SY<4-]J+#;"77"D,;B2EADLMMVJK42IL83$\PKGPO2N\2I^/OO
MR9UF3<#5`KIQ@5>:%M%!:=B&6+5EA<1U:?]0Z8R.@^Z;J:0:[GWRS+C215S.
M7G1?B&;%V01>FWIN&MW0$:8?F>OPY(LR@6Z@^W&0F8\`L[[>.W5+7M*;1=A%
M5L9H/+DTQP0',M&H,0-:0*CC2F7_$,]SV97NQ(!(WVIH*\[QHGXD>GS)M3`G
MD>S4.%.5O?>34Y.MXLPB&Y_K_D!QB14<N6(K1GJ-.[!X+<>AG?PV1U99)*XM
MMX<"'LP5:9QM@D=J?9#E3(W;$O2'1EWSI:FJ.0EDS19Q_^4,]\Y1;_6F6FO]
MISCI'2#$'Q5^(H$-)96_$@=1,X.W"G<PJN4D"P$&*T<HJ3*B^;//'+%D_#PI
MN?!,PWA(07(TXPVE5NL"K&U1LB6>2'NRT9';10]QF"3E'\SW<-O0R&A($1_(
M5[[TLX\QZMXBXN)3(RT=:'YH+@V#'VO38YT=WE<+R*=NK=HTY4:CS293+RW0
MM%FDL+W](ZK\'$@+$EE@2;;EM;DP3LE'!N(T"RVC0:5MS"3)[KQ?-SELC0.$
MT,7+\2`_OR';"]-<IBRZ4Q]A%FI)/B9!1T-5AOCLX/'>DQ>D9^D1^"%(^&$$
M^(!%_4(<PSXB+[D:4]9_#C^B5'&%]<;WM.7M!K'0+EXRQ\G4YA(V::OEV4@2
MW'?@ECJM[ZP_(1"KQPZ>0J9ZD@UF9S!%]B]HN_8930C(5V02*H)&QOUA5F"K
M8TO_W>44?L&YB#:;$TYT'N.@1%%W`HJ2\T-S,=X7#4[8N;JAO^])_6YN?4.7
M_/'UP&FCG1%GY\(Z.(0%3@$`8@!D0%ZM))G!#EM<C1U+,Y^7PHO,I:]4[I'4
M]XG'[+7J8O0D=C9M5,$R)$?FJIUXP30XA.T#]]RO[9KXN]1#.G$**U`9>#\G
M]^VNN6\W#1VUKO`$N!8#CF2,)1,@!XROIOEE7G!%1:"JRJ[D8Z%IU@,OO^M/
MQ'O1+\:CHB5E+V.GG<,:L*L=F5!][)7SH8!"Z7)=,%3G`;U=YDNGY+,,OJ0-
M63W?S;0Q-T`Q.%HE34Y^CJ0$<YHGPS'-6,4`C`13(WNN7&:/R)M3J6LU-YDX
M4+-$&9I&XSX#83"Y4@MR3U%8KZ<:*CF"E\DKHMTA-GZH'AD75F#YQ!%$"\$$
M-G;`!O&:W2+1FT!Y:UFCTE4K36I%G(623<G?VQ\2N=QPH?5!]N[$\%2C&YWY
MW(I\-#XA3C%V9B`GAN0(DG.A+*:]:OR*Q['>?,0MT]3(OPCN>O.1:9N/'/J(
M1G-/K,GR0Z/J_:8>EP0R)`NR2:-4ZI28.<!+S$LGG)<)P!KZL*I%3]#%G$O/
MR<SX!MLN\:V&SC%F>,3MA)MC3FWH]L!,_<'^TQ<L`B%:G8%37$:O1)KW!^_R
M`AFUA)((3PA@4,SDG/=GPZG4T47?#\5T)UX5ZXTA.4_D+YP`7#B=VAX6**".
MDX\.2,1>BC..QC.U@?]PZ/AP_7;RAH*[C3I<@D'C?OSW57_2OTR0\W'9OR%.
MB0Y!KK+IOW:&N)IO67!E4M-)"/S=(&NY[8&X:79](#;*F;E%;&,%#7E>(H$@
M#"?#8]EO36Y>->V;K335QG`X&BK><VKQ]IU?F]=Q?H#%VPMV3.$?H^J.FR(/
MN%HZ%Y+Y.Y+,VV(P"\"_?/KTELUS9<MNRUE%=OI`!1^+D`1>Q.342W;W#Y[M
M1@YS/O?/!Y9AX4_0AM,9IF%&L_[5!VF4;O"&ZOD9M#?4[NVIR?0-TJ11L!'^
MD=H(WJ9Z[Z[9G]L[.T;HW06/MKMU'J"K+/M#PA+X8BJ,QTSJYP6?89L48N:*
M%R+I!<8$-WU[^[]L/XU,'W=/99>+O*[SS1_O/ME^_O283QI"ATF7&=3A8S^H
M:1`*9YK<$DO'A/WQ%.QG=ZSX_B3MD5@IR?3#S%`Z^74A.7M3&'_]]YXJ])Z&
M]^[VDG^!@)_N;A^>[#TY>;)W>'2<.M"N*L^0'@`4;#P1]Y&W02(L@OJ3#4+S
M[H)D>]?5IN]K\KMT_-FS[9];R_9\;5I&8'!JJP-HXX6V@U-VR:;?,6"#S#W*
M?"&$U%Y$E$YL!6$"]^WSXJ'Y?T"2-;B6GB(!I@>*%94-'7S`FIHLE\>7FV2)
M3:FBN$@+K^@`+F`5H7"I4L";#DG]Z>G!C]M/)16O'-'\:[DXYX)I\%6K*%+Y
M8C@^[;,_FP[+/V0^?/?UE%QG*(].'\81[L0#AA_I"QR?FRGH8+DLEIV9IC@Y
M>M5)VMXYWOMEMV:2[!QU26%`6-9=B2M4NR&D8.'XBGO\3@QCYW!W^]B9!^8`
M-<Q#>7>+L0[K:K+N%\4!)8=+,7<MU&(DY<7PR,M@1Q]TG2M=$3A$>HA!/%@<
MVM+O3NHW72-?BKK7J0=V8*^*>S=XRP)NW`E01DSGS:*1KOA.EK_\0J]'C__X
MPO"TW5^:ZM562YW?Y,4C)M!/.$%2!?TX3#(%/R.ZE(@(I;,$Q-"RNM,\7A<0
MA3_O#K!@>08H9`)F)%8P\2#+XCTJF\36]"0$),Q`'F)%1Y_-HZT:CLT/IPHG
MLWI:^8=<`>;%I.(_?TZREZ*RHE:=9B<F^=%8T[(V%^Q_LLAZ3R:#<6AN&6AG
M7.K>:$YMJ7I/ZE*,-SZ(;L=DW<@KS<\'[<\'+581N#_H"#IE?A0^7N&4L2\'
M(LZ/SX]>Q*P]"H-5!$-K6#+[:C"[:K*XQ,-8)&^6D59[TAVQ0>"FU3%]I^T=
M43/]$$)!U,O(>@\JB**0)OBEE]U7+6W,MK_?9ED\DW0PG$-.^"(IG\Y;TJY*
MQU=I^N<(Z`%6*L+A50]CQW+IQ*FFX'SB24"@4NH;U?-YV4/!\GW@LJ*<$6B8
M'=<V^1MR&`<2LG76W)D5]4)):?2Q[+?H1G?2'A>RV;.";9-1`S8Y#<6+N<7;
M'*!_DOY(=HA3AE'C>+XQ2PK`,B*9SN)+9\7L,F-[D3D&.=)&`'US-DEJV8=>
M>2T@-@ZRMG\VS=]92-<EA;-8WE`M6"V;?JQ%"#^)/I=J#5T%P+Z'?ER8-3RQ
M-(W_.BV6Z-=[=41;5.*_J)@!5=?#+J_9O`O_(K:3`$ABUVA`;%4)F?F8,\;Y
M7U*MC`RXGAL]=C8<%TZ0"IZ2C1@T);_1X27SX"?%3YXK2B\)O?0),AS9,U]Y
M#_GSM2%=[D<8\TH>OG^#V>7>?NP<UR2,E!_%[\X*#[1#Q,(8R6%J"+WPF*%!
M6E^1DHD4UM"[S8V\5;:(;J"T'\T!L]*-W,9CN&##4W-&OU5&4$&QMKS6HC'!
ME),V7,=;:2/FTJ;1W)?(GG)LN"(9NE];F57P0"1HF=@0XWW[>%X2*S;9K'!:
MA$JZ3\AKS$W+44DYGYK4$\=)JN;HH)"L.A$])U0E;%MJ31I2A4H,L3;FD:?A
MFA-0.AW/8&N_S:M/\_H&\;/H</*&>_S&O&5HZ`U#J%2L_F]B17^7F)2R0=U5
MN^7&%ZV^K\N[:$HC<3+EDL":[)#,%<?(&LTN3TDPUV$/Q<M7OEN8#16_9"V:
MAMA1IP&61D(]$,%7Q+X_('%,2[F!5?/28U::;6IZV3+G<Y-'<H\P+)<&L60,
M2S*_\=LDQO0GDS[`%_["8W,N==\'(Y^:;O`KEF3A'B5%M!A/H$M+U$;`OV1E
MY<W$E5F.17,4+_-7(#^\K0F7[!$ZCE5U[,V]K5<M\XSV6S&=@_$91D=\5I2R
MX+T'KZQ:7VK.\4,[T?GFFY:WZY6>]D[*#S*[Y)"[:3OY<3RQ**'S9N7/9AG\
M+9[\3^`,-4=:96J\*?XVS*2:FNJCW-"J#;@<NFTG!C6WZ6%G++&A*#>8BTI5
M)?]:-E1^-`<%J3FKF[*Z&:N>L63O\RYLJ?Y4@F28%:P6<3P*(YN,IHR%0F$N
ME#,U(L/.Q:P_,:]EILGQM>$LHQL)92A<Y+/G:$[ZHP]CS$L$]BG?62P,785O
MM4(6[I8-GYLM_<'RDBSS+<%%N:#*(N0L'8XO$`XS&YU-I;2<ZXZY1S=/[,U(
MG_!L<^-\U`IOL@^O'>#7M1.S.5NVY\K?1+XFUS/84_IP$&TZ$`ZL<O^<NVR(
M]JVJN(+L-MG]'&HR0(U$B2$DJ%V.CJ":BTB<G$V2JS[R)*7HY23;S`HCR!DY
M]+6P$T4$W*?X1BJ[$AL1\;PB75LI7)P83DJ73158$__5%'OB[P<GJ,;7XMS'
M0)Q?:.;G(3P4%T>I=M<"0SX85,1@)WUPYB!2*I2A"*9?,2&Y6VQ=6J:G\,.8
MQ^]S:X:>B8I&%]G@CBMMM82QYJ/-$\MTT=EDQJ=3Q-B(8<!\K::/085)A8'N
M2"2:E&HW!<<=?!$A3@J.:M)>K'%Y"Z<W_^ZQ8D6_8H\IC2DT:0G50[WB5(=R
M)3%]:'WVGW^9F>B\_I._T=WJ=K_YZJO/NMWNUK=?=_5_Z9];6U]]_5GWVZ^^
M_>:;K:UON^9W\]/76Y\EW3^Y7[AFY$).DL\FYA\W<YY;=/_?]/I+?CZB(H\G
M)XA<.SEI_,7\F1L91?UBRR=_7]P4]PE.MNB\?E3ZF5AI^.ML9([C`?U&VYU.
MK>>C_+?DZ-F/]_>SZ6D^-H?@Y17'Q2/0%MGEOXA#[,M.E_X\ZE^>*AN6/;01
MB$L!L0RYW=QI4:&827:='$_RP45FF,K6=]]]1T]QE!>[,2XH3BDO)$YV?#ZE
M-.84R,14$L*(6SF!BY[.N(R!.4CO4YU:A(PB0&O*(&L<DIA-+@L;E/C3_O/D
MIVR43?K#Y.>9.7//DJ?F4!B1"<Y\>H93&!(N`]YE7.CC2/J0/"&4!<Q"FF0Y
M<%FL:_"!_88TV#9*"#72-*?S#3#5KKC,)TE_P_[4O]JI&[\?IL=+-XQ1RO9.
MG>QH))3SV;!-35"6^:][QW\]>'Z<;.^_2'[=/CS<WC]^D3K$@\QB/]&J4K6*
M:])%1],;TW]JX=GNX<Y?S2O;/^X]W3M^0;Z_)WO'^[M'1\F3@\-D._EY^_!X
M;^?YT^W#Y.?GAS\?'.UV$I3VD""[.7.,<L*H.)@1RFCA1OZ"0*<9%@"BE)&.
M,W.<4>&H,XJG7KA\@"4`IJGD;?B93`7(L"U1JV))#Q:67O=KVS:*]EFGG7SS
M[=?)LWY1)-N4P+]C:!Q4VTZ>;2?=!UM??M=.GA]M,YB:5&$U^_'L:C@KZ/\-
M<ZYE!'R[L^[+YW*6)P0L"2;E'!'H4'93TY8^W/WYZ?;.;K(5_,HAZ,F#X$=)
M`_A2M7TNH8$X1RMM2V!2TB57+X(&^S#]]4_S86XH@=TOK\=#T:+UNV%(0J5[
M;$HVNX&2``2,@%;<[!!;VT&_(-$\2?*5?V$PYCTB44R5-RCDQ[SQ7_X-<@K9
MPKM!7]E3G&Q]0\_:Z@]<#,+HGM;/8U['%`7O6KWY#*&%$RH?+B%`-E@>MTC'
MH9M<)M;E44!.*L%J:[3LGE0`#<"Q-0!V:$X5>=#9E<KHU16\Z5#;!\JT/4.,
M_NT&2KKX;%3D%Z-LX"B4C@YZ4/2+]S:=:"`98_D_*?I1HL<_.-4P]6]2LU#B
M*-NO_"-@88!W(@H6"`0EUKF0UW@$V)\,90^TD;M:"L?VS4=UO/SRP2M$,-`.
MN)]-S^YS##M2V$T/A.?B$<NZA;M@6>USRA9*:0ILN#,/PB9`V7EYIBK2$LH=
MJ6ZI3L8JLHEA82^_W'IEIBEMZ.XCVY,F)GFOL`=3_O>0;E1>"2%*WL\#-!07
M!-*Z@<'C<\4^A%,O^*WD"5$^:UL6WN6(0G4UY_NI"WTJT0CT"&G'T0NIE9@]
MY+-3!(%,M%[3-<9P$6<3'K_F$#5T01"!AC>)E$*%?8T2Y`9XUL?-F3UW-LFO
M#"TY_/3@.T*/B:NP2Z_#'#,[DPI5T/1.,WY(?\SY/MPWD3AK?26HF11;W`V)
MYZ6WV.)K8;V\IE\#OA]P$XRHB@8?J0W%_^$/&F'IC(09?8*J^DE$%!R#:]>(
MCPZ)IY?3R<6ZT>,;WG06CLDG^A</)=24;-O.M%T/M>/!,XE#"X24!_[PTQ2A
M-"9T=(354YRIC"+JRS2;`7`+.D4B93S"_!\S*JJ2D\&&:G<5O#-HEGGM)7]B
ML.0+8I*2$/!FK,]36^9K:!C<,&:EPHC$_A48Q];"0'1F<U@SV*AT=-(F(AO9
M5BLJO&G@0Z+4<\6OJ5UX(D.,I8I=S;)Z_2_>ORW/YV4.IBHF?FD#75H3N?^G
MY!RD_P^R!-+&0E-?6FMO26]E+@T6)+U%49'T%F4GTH]`CT]OF<B>_D'IU>FB
M0(OR8&I!=M);HZ^$X_@DX+/TEKCIZ:=Z;=/E?#WIXJ"$2DLU3S4`[GG-+-,I
M!L[*\!`*`!0_2AG^*"=*^E&>$.[:X^QTIKK306D+RY*-%CJ8X48G<'`,9I=7
M)XMFY6IB!F)+)T=G1G3,D/X`01+32#\X(9__FS#"6P>8,/_71J[5M;I6U^I:
M7:MK=:VNU;6Z5M?J6EVK:W6MKM6UNE;7ZEI=JVMUK:[5M;I6U^I:7:MK=:VN
6U;6Z5M?J6EVKZS_L^A][ABVU`/``````
`
end

Re: KBuild 2.5 Impressions

[Kenneth Johansson]

On Fri, 2002-05-31 at 01:19, Daniel Phillips wrote:
> There is exactly one valid objection I've seen to kbuild 2.5 inclusion,
> and that is the matter of breaking up the patch.  Having done a quick
> tour through the whole patch set, I now know that there are some
> easy places to break it up:
> 
>   - Documentation is a large part of the patch and can be easily
>     broken out.
> 
>   - The makefile parser, complete with state transition tables etc,
>     lexer, and so on, breaks out cleanly (sits on top of the db
>     utilities).
> 
>   - Executable programs written in C.  Each one ends with a
>     'main' function, and there is the natural division.
> 
>   - The remaining C code breaks out into a number of separable
>     components:
> 
>       - Utilities such as environment variable parsing, canonical
>         name generation, line reading, line editing etc.
>       - The database 
>       - File utilities that use the database (e.g., walk_fs_db)
>       - Dependency generation
>       - Global Makefile construction (command generation etc)
> 
>     These tend to be common to a number of the executable programs,
>     and so have the nature of library components.  They can all go
>     under the heading 'lib', and further breakdown is probably not
>     necessary.
> 
>   - The Makefile.in patches seem to be about 30-40% of the whole
>     thing, and imho must be applied all at the same time.  However,
>     they break up nicely across subsystem lines (drivers, fs, etc)
> 
>   - The per-arch patches are already broken out, and are short.
> 
> I think that with these breakups done the thing would be sufficiently
> digestible to satisfy Linus.  Now that I think of it, Linus's request
> for a breakup is really an endorsement, and quite possibly Keith took
> it the wrong way.  (Keith, by the way, how did I do on the structural
> breakdown?  Sorry, I really couldn't spend as much time on it as it
> deserves.)

Maybe I'm the idiot here but what dose this gain you??

The reason to break up a patch is not simply to get more of them. There
is no point in splitting if you still need to use every single one of
them to make anything work. 

Re: KBuild 2.5 Impressions

[Daniel Phillips]

On Friday 31 May 2002 02:13, Kenneth Johansson wrote:
> On Fri, 2002-05-31 at 01:19, Daniel Phillips wrote:
> > There is exactly one valid objection I've seen to kbuild 2.5 inclusion,
> > and that is the matter of breaking up the patch.  Having done a quick
> > tour through the whole patch set, I now know that there are some
> > easy places to break it up:
> > 
> >   - Documentation is a large part of the patch and can be easily
> >     broken out.
> > 
> >   - The makefile parser, complete with state transition tables etc,
> >     lexer, and so on, breaks out cleanly (sits on top of the db
> >     utilities).
> > 
> >   - Executable programs written in C.  Each one ends with a
> >     'main' function, and there is the natural division.
> > 
> >   - The remaining C code breaks out into a number of separable
> >     components:
> > 
> >       - Utilities such as environment variable parsing, canonical
> >         name generation, line reading, line editing etc.
> >       - The database 
> >       - File utilities that use the database (e.g., walk_fs_db)
> >       - Dependency generation
> >       - Global Makefile construction (command generation etc)
> > 
> >     These tend to be common to a number of the executable programs,
> >     and so have the nature of library components.  They can all go
> >     under the heading 'lib', and further breakdown is probably not
> >     necessary.
> > 
> >   - The Makefile.in patches seem to be about 30-40% of the whole
> >     thing, and imho must be applied all at the same time.  However,
> >     they break up nicely across subsystem lines (drivers, fs, etc)
> > 
> >   - The per-arch patches are already broken out, and are short.
> > 
> > I think that with these breakups done the thing would be sufficiently
> > digestible to satisfy Linus.  Now that I think of it, Linus's request
> > for a breakup is really an endorsement, and quite possibly Keith took
> > it the wrong way.  (Keith, by the way, how did I do on the structural
> > breakdown?  Sorry, I really couldn't spend as much time on it as it
> > deserves.)
> 
> Maybe I'm the idiot here but what dose this gain you??

It makes it faster to analyze.  I would have appreciated that in doing
my own analysis.  If Linus incorporated the whole thing without analyzing
its structure, I'd be worried.

The only problem would be that this kind of breakup and convenience of
applying the patch tend to be mutually exclusive.  I suppose that could
be solved with a script Keith's end - simply append all the broken-apart
pieces into one large patch (in fact, it seems that two of the tree
patches you need to apply for the i386 version would be better appended
together for the purpose of distribution.)

The question of how much work it is to do the breakup itself is separate.
In my experience, maintaining a system in a broken-up form tends to be
a major use of time.  It's something you want to do once, just before
inclusion, and that seems to be exactly what Linus has asked for.

> The reason to break up a patch is not simply to get more of them. There
> is no point in splitting if you still need to use every single one of
> them to make anything work. 

See above.  It's all about analyzing the structure of the patch.  To be
fair though, it took me less than an hour to get a pretty good idea of
how the current patch set is structured.

-- 
Daniel

Re: KBuild 2.5 Impressions

[Skip Ford]

Daniel Phillips wrote:
> On Friday 31 May 2002 02:13, Kenneth Johansson wrote:
> > On Fri, 2002-05-31 at 01:19, Daniel Phillips wrote:
> > > 
> > > I think that with these breakups done the thing would be sufficiently
> > > digestible to satisfy Linus.  Now that I think of it, Linus's request
> > 
> > Maybe I'm the idiot here but what dose this gain you??
> >
> > The reason to break up a patch is not simply to get more of them. There
> > is no point in splitting if you still need to use every single one of
> > them to make anything work. 
> 
> See above.  It's all about analyzing the structure of the patch.  To be
> fair though, it took me less than an hour to get a pretty good idea of
> how the current patch set is structured.

I could be wrong but I think Linus wants small patches that slowly
convert kbuild24 to kbuild25, and not just a chopped up wholesale
kbuild25.

There's a big difference between splitting kb25 into pieces and figuring
out a way to migrate from kb24 to kb25 with small patches.  You're
suggesting the former while Linus wants the latter.

-- 
Skip

Re: KBuild 2.5 Impressions

[Daniel Phillips]

On Friday 31 May 2002 03:20, Skip Ford wrote:
> Daniel Phillips wrote:
> > On Friday 31 May 2002 02:13, Kenneth Johansson wrote:
> > > On Fri, 2002-05-31 at 01:19, Daniel Phillips wrote:
> > > > 
> > > > I think that with these breakups done the thing would be sufficiently
> > > > digestible to satisfy Linus.  Now that I think of it, Linus's request
> > > 
> > > Maybe I'm the idiot here but what dose this gain you??
> > >
> > > The reason to break up a patch is not simply to get more of them. There
> > > is no point in splitting if you still need to use every single one of
> > > them to make anything work. 
> > 
> > See above.  It's all about analyzing the structure of the patch.  To be
> > fair though, it took me less than an hour to get a pretty good idea of
> > how the current patch set is structured.
> 
> I could be wrong but I think Linus wants small patches that slowly
> convert kbuild24 to kbuild25, and not just a chopped up wholesale
> kbuild25.

I hope you're wrong, because that does not sound reasonable.  On the other
hand, the two build systems coexist quite happily in the same tree.  You
have to explicitly do the -f Makefile-2.5 for the new build system to kick
in.  So nobody is being asked to make any sudden change, people can convert
at their own convenience.

> There's a big difference between splitting kb25 into pieces and figuring
> out a way to migrate from kb24 to kb25 with small patches.  You're
> suggesting the former while Linus wants the latter.

If that's really a correct interpretation, it would be weird.  I hope it
isn't.

-- 
Daniel

Re: KBuild 2.5 Impressions

[Tomas Szepe]

> > I could be wrong but I think Linus wants small patches that slowly
> > convert kbuild24 to kbuild25, and not just a chopped up wholesale
> > kbuild25.
> 
> I hope you're wrong, because that does not sound reasonable.  On the other
> hand, the two build systems coexist quite happily in the same tree.  You
> have to explicitly do the -f Makefile-2.5 for the new build system to kick
> in.  So nobody is being asked to make any sudden change, people can convert
> at their own convenience.

How about a little simile?

Suppose you travel somewhere regularly. You go by train. Then you find out
that switching to bus service would cost you 30% less. Neat!! But hold on,
you are used to going by train -- maybe it's sort of a ritual, like you sit
on the same bench every time and read a newspaper or the conductor's your
friend and you always have a great time chatting with him. But saving 30%
off the traveling costs might be worth sacrifying these pleasures.

What are you going to do? There's no reasonable way to make a transition
from "going by train" to "going by bus," because trains and buses are way
too different. By god, most of the time there's even no toilet in the bus!
Sure, you could go half the route by train and then change to bus, but that
doesn't classify as reasonable with me (it's complicated, eats time and is
certainly expensive). Apparently, the only way to deal with the situation
is to sometimes go by bus and sometimes by train, and eventually cut out
going by train, should you conclude that the switch in your habits pays
off.

--

With that out, I have to say I've never seen so much talk about
something as clear. Let's summarize:

kb25	- is superior to kb24 in one too many aspects
	- is next to impossible to split up "unartificially"
	- coexists with kb24, which provides for the only conceivable
	kind of transition in a change of two greatly diverse systems
	- is transparent and well documented
	- has been spoken in favor of by celebrities (MOST IMPORTANT!! :D)

I'd tell you where the problem lies but I like to avoid saying the obvious.

T.

Re: KBuild 2.5 Impressions

[Nicolas Pitre]

On Fri, 31 May 2002, Tomas Szepe wrote:

> With that out, I have to say I've never seen so much talk about
> something as clear. Let's summarize:
> 
> kb25	- is superior to kb24 in one too many aspects
> 	- is next to impossible to split up "unartificially"
> 	- coexists with kb24, which provides for the only conceivable
> 	kind of transition in a change of two greatly diverse systems
> 	- is transparent and well documented
> 	- has been spoken in favor of by celebrities (MOST IMPORTANT!! :D)
> 
> I'd tell you where the problem lies but I like to avoid saying the obvious.

One thing obvious so far is that there were a lot of positive comments
(which is good).  However no one actually tried to produce multiple logical
patches for kbuild25 yet and send them to Linus.  Whether you agree with the
procedure or not is somewhat irrelevant for the final result.  And Daniel
Philips nicely demonstrated how it could be done.


Nicolas

Re: KBuild 2.5 Impressions

[Thunder from the hill]

Hi,

On Fri, 31 May 2002, Nicolas Pitre wrote:
> One thing obvious so far is that there were a lot of positive comments
> (which is good).  However no one actually tried to produce multiple logical
> patches for kbuild25 yet and send them to Linus.  Whether you agree with the
> procedure or not is somewhat irrelevant for the final result.  And Daniel
> Philips nicely demonstrated how it could be done.

Stingr did that for 2.4, and I'm currently working on the 2.5 version. I'm 
just suffering incredible headaches for days now, so it takes some time 
since I can't work very continuously.

Please be patient. It's all on its way. See 
<URL:ftp://luckynet.dynu.com/pub/linux/kbuild-2.5/> for details!

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: KBuild 2.5 Impressions

[Skip Ford]

Thunder from the hill wrote:
> On Thu, 30 May 2002, Skip Ford wrote:
> > I could be wrong but I think Linus wants small patches that slowly
> > convert kbuild24 to kbuild25, and not just a chopped up wholesale
> > kbuild25.
> 
> That's what we have. If you want to try kbuild-2.5, you have to use the
> Makefile-2.5 explicitly. If you don't explicitly do that, you're using 
> kbuild-2.4, so you got a pretty good chance to evaluate kbuild-2.5 and 
> then decide whether you leave it or pull it. Enough migration?

That's not a migration at all.  That's two different build systems side
by side.

A migration would mean that there is only ever 1 build system.  Send
patches that would convert what we have now to kbuild25 over the next 10
kernel releases or so.  That's a migration.

-- 
Skip

KBuild 2.5 Migration

[Daniel Phillips]

On Friday 31 May 2002 06:01, Skip Ford wrote:
> Thunder from the hill wrote:
> > On Thu, 30 May 2002, Skip Ford wrote:
> > > I could be wrong but I think Linus wants small patches that slowly
> > > convert kbuild24 to kbuild25, and not just a chopped up wholesale
> > > kbuild25.
> > 
> > That's what we have. If you want to try kbuild-2.5, you have to use the
> > Makefile-2.5 explicitly. If you don't explicitly do that, you're using 
> > kbuild-2.4, so you got a pretty good chance to evaluate kbuild-2.5 and 
> > then decide whether you leave it or pull it. Enough migration?
> 
> That's not a migration at all.  That's two different build systems side
> by side.
> 
> A migration would mean that there is only ever 1 build system.  Send
> patches that would convert what we have now to kbuild25 over the next 10
> kernel releases or so.  That's a migration.

You're 'improving' the meaning of the term a little.  Suppose you're
going to migrate all the servers in a company from Windows to Linux, do
you come up with a succesion of intermediate operating systems?  IOW, in
a migration, it is the users who migrate, not the software.  I believe
the term you were thinking of is 'evolution'.

-- 
Daniel

Re: KBuild 2.5 Migration

[Skip Ford]

Daniel Phillips wrote:
> On Friday 31 May 2002 06:01, Skip Ford wrote:
> > 
> > That's not a migration at all.  That's two different build systems side
> > by side.
> > 
> > A migration would mean that there is only ever 1 build system.  Send
> > patches that would convert what we have now to kbuild25 over the next 10
> > kernel releases or so.  That's a migration.
> 
> You're 'improving' the meaning of the term a little.  Suppose you're
> going to migrate all the servers in a company from Windows to Linux, do
> you come up with a succesion of intermediate operating systems?  IOW, in
> a migration, it is the users who migrate, not the software.  I believe
> the term you were thinking of is 'evolution'.

Ok, I'll buy that.  I used the wrong word.

That doesn't change the situation though.  I think Linus would like the code
to _evolve_ into whatever it becomes, and not just do a wholesale replacement.

-- 
Skip

Re: KBuild 2.5 Impressions

[Nicolas Pitre]

On 31 May 2002, Kenneth Johansson wrote:

> On Fri, 2002-05-31 at 01:19, Daniel Phillips wrote:
> 
> > I think that with these breakups done the thing would be sufficiently
> > digestible to satisfy Linus.  Now that I think of it, Linus's request
> > for a breakup is really an endorsement, and quite possibly Keith took
> > it the wrong way.  (Keith, by the way, how did I do on the structural
> > breakdown?  Sorry, I really couldn't spend as much time on it as it
> > deserves.)
> 
> Maybe I'm the idiot here but what dose this gain you??

1) easier review

2) Linus acceptance

While the breakups doesn't necessarily guarantee #2 it is at least a known 
prerequisite.

And of course #2 is quite important here.


Nicolas

RE: KBuild 2.5 Impressions

[Hua Zhong]

The patch size accusation is kinda rediculous to me. Linus _does_ accept
large patches -
remember the whole VM switchover? The ALSA patch, as another example?  And I
bet
whenever there is a new file system the patch must be huge. Why aren't they
split
up? How does it sound, "let's ask Andrea to split up his VM patches so that
they
gradually improve Rik's VM"? (no offense to Andrea) If such a big change in
such a critical
subsystem is allowed, why not kbuild 2.5?

Sometimes it just doesn't make sense to split up things if they need to work
_together_,
especially when you want to _replace_ something instead of improving it.
Well, you could
split it up into many small patches, but if they must be applied together
how much good would that
give you? To me it's just like "well, since they asked let's do it just to
make _them_ happy
so the damn thing can get in".

Auh..the "only Keith could fix things"....come'on, isn't this open-source?
Hey, You guys are genius,
and I don't believe at all a build system is more complex than any piece of
the kernel itself. And look at
the VM change during 2.4 (sorry to mention it again), how about "only Andrea
could fix bugs in the new
VM"? That still happened, although there was far less documentation of the
new VM than that of kbuild 2.5.

I have to say I don't see good reasons to set up obstacles to Keith's work.
It's faster, it's more reliable,
it coexists with the current build system, and it's been well tested. What
else to ask for? Let's just get it
in and  be done with it, so people can spend time on more useful things. (I
have a feeling that if Linus
actually does this, all the accusations will go away, so all the questions
boil down to: what does Linus
think/do? :-)

I'm not an active kernel hacker (although I do work on Linux and writing
kernel modules is part of my job),
so my opinion may not count, but I can't help on this.

regards,

Hua

> Maybe I'm the idiot here but what dose this gain you??
>
> The reason to break up a patch is not simply to get more of them. There
> is no point in splitting if you still need to use every single one of
> them to make anything work.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: KBuild 2.5 Impressions

[Daniel Phillips]

On Friday 31 May 2002 05:29, Hua Zhong wrote:
> Auh..the "only Keith could fix things"....come'on, isn't this open-source?
> Hey, You guys are genius,
> and I don't believe at all a build system is more complex than any piece of
> the kernel itself. And look at
> the VM change during 2.4 (sorry to mention it again), how about "only Andrea
> could fix bugs in the new
> VM"? That still happened, although there was far less documentation of the
> new VM than that of kbuild 2.5.

Funny you should mention that, since I just this minute completed a small
hack for the benefit of Andrew Morton, who likes to be able to have his
.config as a symlink.  Yes it was easy, even starting from a state of
nearly complete cluelessness.  And before anybody asks, no I did not do the
job properly, I do not pretend or want to be a member of the kbuild team.
I just wanted to know how hard it is to hack this thing.

-- 
Daniel

RE: KBuild 2.5 Impressions

[Thunder from the hill]

Hi,

On Thu, 30 May 2002, Hua Zhong wrote:
> To me it's just like "well, since they asked let's do it just to make
> _them_ happy so the damn thing can get in".

Kind of...

> Auh..the "only Keith could fix things"....come'on, isn't this
> open-source? Hey, You guys are genius

That's not even needed. The new kbuild-2.5 makes coding much easier...

> I have to say I don't see good reasons to set up obstacles to Keith's
> work. It's faster, it's more reliable, it coexists with the current
> build system, and it's been well tested. What else to ask for? Let's
> just get it in and be done with it, so people can spend time on more
> useful things. (I have a feeling that if Linus actually does this, all
> the accusations will go away, so all the questions boil down to: what
> does Linus think/do? :-)

That's what I'm working for.

> I'm not an active kernel hacker (although I do work on Linux and writing
> kernel modules is part of my job), so my opinion may not count, but I
> can't help on this.

It's exactly one opinion, it doesn't count more than that. I think that's 
enough for you, isn't it?

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: KBuild 2.5 Impressions

[Ion Badulescu]

On Fri, 31 May 2002, Daniel Phillips wrote:

> > Are YOU willing to maintain it if Keith abandons it, though?
> 
> That is pure FUD, shame on you.

FUD? Heh. No, it's a simple question and you haven't answered it.

> What I do not appreciate about Kai's effort is that it is divisive.

Read below. I don't have much time to waste on this topic, so I'll be 
brief.

> There is exactly one valid objection I've seen to kbuild 2.5 inclusion,
> and that is the matter of breaking up the patch.  Having done a quick
> tour through the whole patch set, I now know that there are some
> easy places to break it up:

And that's precisely the wrong way to break it up. You'll waste your time
and you'll probably hit Linus' bit bucket in no time. Thank you very much,
but I can split patches based on the files they touch by myself, I don't
need your help.

What you and other very vocal proponents of kbuild25 don't understand is 
that you need break it up __functionally__. That is, add one feature at a 
time. That way, good features can be added without much of a discussion, 
and debatable features can be, well, debated.

Unfortunately, I don't see Keith doing this anytime soon. He's too much in 
love with his baby to risk seeing parts of it being thrown away, so he's 
taking an all-or-nothing attitude.

Fortunately, it is precisely what Kai is doing. He deserves a big THANKS 
for doing it, not your silly bashing. I also saw some good work on this 
from Sam Ravnborg on the list.

Anyway, EOT for me.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.

Re: KBuild 2.5 Impressions

[Daniel Phillips]

On Sunday 02 June 2002 06:03, you wrote:
> On Fri, 31 May 2002, Daniel Phillips wrote:
> What you and other very vocal proponents of kbuild25 don't understand is 
> that you need break it up __functionally__. That is, add one feature at a 
> time. That way, good features can be added without much of a discussion, 
> and debatable features can be, well, debated.
> 
> Unfortunately, I don't see Keith doing this anytime soon. He's too much in 
> love with his baby to risk seeing parts of it being thrown away, so he's 
> taking an all-or-nothing attitude.

Fortunately, he's got help now:

   http://marc.theaimsgroup.com/?a=102296100300003&r=1&w=2

> Fortunately, it is precisely what Kai is doing. He deserves a big THANKS 
> for doing it, not your silly bashing. I also saw some good work on this 
> from Sam Ravnborg on the list.

If I got the impression that Kai was actually trying to work with the team,
I'd thank him for that.  He appears to be doing just the opposite, and I
stand by my comment that that is divisive.  He could accomplish the same
thing result he wants - patching up old kbuild - and bring parts of kbuild
2.5 into the tree, reducing the size of that patch *at the same time*,
instead of (apparently) trying to marginalize that work.  That is what I'd
call cooperation.

We have a perfect - and rare - situation here where the two can coexist in
the same tree, and may the best and fastest eventually predominate.  Let's
take advantage of that: let's have both in parallel for a while.

-- 
Daniel

Re: KBuild 2.5 Impressions

[Thunder from the hill]

Hi,

On Sun, 2 Jun 2002, Ion Badulescu wrote:
> On Fri, 31 May 2002, Daniel Phillips wrote:
> FUD? Heh. No, it's a simple question and you haven't answered it.

It fit happily into the "noone is willing to maintain kb25" cliche.

BTW, I think I will release a patch against linux 0.01 which will 
introduce all the features of the current linus tree in a few minutes. Why 
calling it linux 2.5.19? It has the features! Yet I'm patching it, if you 
want piecemeal, grab the list.

> And that's precisely the wrong way to break it up. You'll waste your time
> and you'll probably hit Linus' bit bucket in no time. Thank you very much,
> but I can split patches based on the files they touch by myself, I don't
> need your help.

I split it so that you can merge some stuff in and it has no effect. You 
can even merge the whole thing in with no effect as long as you're using 
the old Makefile,v 2.4.

> What you and other very vocal proponents of kbuild25 don't understand is 
> that you need break it up __functionally__. That is, add one feature at a 
> time. That way, good features can be added without much of a discussion, 
> and debatable features can be, well, debated.

I'm not exactly german. I'm in germany, currently, but what does it tell 
you? And before you ask, I never answer questions about my nationality. 
And anyway, they don't belong to linux-kernel in any way.

For the most features you'll at first need the core, or you merge it in, 
and later pull it from the kernel again to introduce it with core support. 
Diffing into every single feature _can_ be done, but I'll be kicked off 
the list if I post them one by one.

> Unfortunately, I don't see Keith doing this anytime soon. He's too much in 
> love with his baby to risk seeing parts of it being thrown away, so he's 
> taking an all-or-nothing attitude.

It's more or less because it is quite silly to post every single feature, 
and lethal for kernel development on this list.

> Fortunately, it is precisely what Kai is doing. He deserves a big THANKS 
> for doing it, not your silly bashing. I also saw some good work on this 
> from Sam Ravnborg on the list.

See my statement about linux-0.01.

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: KBuild 2.5 Impressions

[Sam Ravnborg]

On Sun, Jun 02, 2002 at 01:58:10AM -0600, Thunder from the hill wrote:
[cc: list trimmed]

> I split it so that you can merge some stuff in and it has no effect. You 
> can even merge the whole thing in with no effect as long as you're using 
> the old Makefile,v 2.4.

Piecemal is not about splitting the patch in small bits only.
It's about adding features one-by-one, and about fixing bugs one-by-one.
Forget the story that current kbuild-2.5 needs the core in order to
enable any functionality.
A small list of stuff independent of the core stuff:
o New defconfig target
o New installable target
o Replacement of installkernel script with a couple of commandline options
o asmoffset stuff, allthough not used for i386 at present
o The idea behind _shipped prefix on shipped files
o randconfig, warnings in split-include, mkdep, 2048 symbol limit, dbl qoutes
o Quit output, making warnings more visible
o etc.

I think Linus did not want to take a patch that changed too much, and
thats what kbuild-2.5 does. This does not change when you split it up
file by file.

	Sam

Re: KBuild 2.5 Impressions

[Daniel Phillips]

On Sunday 02 June 2002 16:03, Sam Ravnborg wrote:
> On Sun, Jun 02, 2002 at 01:58:10AM -0600, Thunder from the hill wrote:
> [cc: list trimmed]
> 
> > I split it so that you can merge some stuff in and it has no effect. You 
> > can even merge the whole thing in with no effect as long as you're using 
> > the old Makefile,v 2.4.
> 
> Piecemal is not about splitting the patch in small bits only.
> It's about adding features one-by-one, and about fixing bugs one-by-one.

You mean, fixing the bugs you introduced by trying to add it piecemeal?
How about breaking it up where it makes sense to do so, and not breaking
it up where it's silly.

If you have a specific suggestion about which part should be broken out,
feel free to provide details.

-- 
Daniel

Re: KBuild 2.5 Impressions

[Sam Ravnborg]

On Sun, Jun 02, 2002 at 04:38:33PM +0200, Daniel Phillips wrote:
> You mean, fixing the bugs you introduced by trying to add it piecemeal?
> How about breaking it up where it makes sense to do so, and not breaking
> it up where it's silly.
Can we agree that it makes sense to add features one-by-one when
they are independent?

If thats the case then it is a simple matter of looking through the
features already present in kbuild-2.5.
Then to compare those features with the work done by Kai.
If the feature is worth it and can be introduced without the core,
then introduce it in kbuild-2.4.
This will make this specific feature visible to many people, and 
those who feel against it can speak up.

> If you have a specific suggestion about which part should be broken out,
> feel free to provide details.
I already gave a list of features that could be broken out. Do you request
more information than that?

I already submitted 4 patches digged out from kbuild-2.5, one of them
introducing a bug. The bug was present in kbuild-2.5!
This bug was easy to spot since the patch was selfcontained, but
within several thousands of kbuild-2.5 source lines it would have been missed
most probarly.

	Sam

Re: KBuild 2.5 Impressions

[Thunder from the hill]

Hi,

On Sun, 2 Jun 2002, Sam Ravnborg wrote:
> Can we agree that it makes sense to add features one-by-one when
> they are independent?

No, as that means introducing a buggy version of kbuild-2.5 to fix the 
bugs afterwards. Sure, there are bugs, but they can be fixed either. I 
don't need to reintroduce all the kbuild-2.4 bugs therefor.

The one thing you all seem to have got wrong is that kbuild-2.5 does not 
overwrite kbuild-2.4 but exist in parallel to it. So there's nothing to 
fix, we could just introduce all the features one by one, but that means 
they all will only function after the last patch, which will be some kind 
of "activation".

For me, I don't purposely introduce bugs.

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: KBuild 2.5 Impressions

[Daniel Phillips]

On Sunday 02 June 2002 16:56, Sam Ravnborg wrote:
> On Sun, Jun 02, 2002 at 04:38:33PM +0200, Daniel Phillips wrote:
> > You mean, fixing the bugs you introduced by trying to add it piecemeal?
> > How about breaking it up where it makes sense to do so, and not breaking
> > it up where it's silly.
>
> Can we agree that it makes sense to add features one-by-one when
> they are independent?

Oh absolutely, and have you looked at the current factoring?

   http://marc.theaimsgroup.com/?a=102296100300003&r=1&w=2

This is still being improved, of course.

> If thats the case then it is a simple matter of looking through the
> features already present in kbuild-2.5.
> Then to compare those features with the work done by Kai.

Well, actually a lot of the work done by Kai is simply importing
portions of Keith's work that break out easily, which is purely
duplication of effort, since such work is already in progress.  In
fact it creates more work, because then we have to go parse Kai's
patches and find out what he submitted, then see if it gets applied
so we can mark it 'applied' in the list.  This is a real waste of
time, and did I mention, it's divisive?

> If the feature is worth it and can be introduced without the core,
> then introduce it in kbuild-2.4.
> This will make this specific feature visible to many people, and 
> those who feel against it can speak up.
>
> > If you have a specific suggestion about which part should be broken out,
> > feel free to provide details.
>
> I already gave a list of features that could be broken out. Do you request
> more information than that?

Yes, those seem to be good suggestions.  What I'd suggest is: import
enough of kbuild 2.5 to support the feature (in some case nothing
needs to be imported), then make it work also for old kbuild (in
some cases that will require no work.  This I'd call cooperation,
which would look good on everybody involved.

I'm not working on this, please pass your specific suggestions to:

   Thunder from the hill <thunder@ngforever.de>

> I already submitted 4 patches digged out from kbuild-2.5, one of them
> introducing a bug. The bug was present in kbuild-2.5!
> This bug was easy to spot since the patch was selfcontained, but
> within several thousands of kbuild-2.5 source lines it would have been missed
> most probarly.

Good point.  The bright side of all this is, we're getting more eyeballs
than ever actually looking at the code, and chances are, even thinking
about how it works.

By the way, kbuild 2.5 running on 2.4.19-pre9 turns in a build time of
5.4 seconds when nothing needs to be rebuilt and 8.3 seconds after
touch fs/ext2/inode.c, on my 2 x 1 GHz compile box.  And so far, hasn't
embarrassed itself once.

-- 
Daniel

Re: KBuild 2.5 Impressions

[Sam Ravnborg]

On Sun, Jun 02, 2002 at 05:16:34PM +0200, Daniel Phillips wrote:
> > Can we agree that it makes sense to add features one-by-one when
> > they are independent?
> 
> Oh absolutely, and have you looked at the current factoring?
> 
>    http://marc.theaimsgroup.com/?a=102296100300003&r=1&w=2
> 
> This is still being improved, of course.
I have looked at the above factoring, which was only a file factoring,
neither bug-fix factoring, nor feature factoring.
IMHO this is not the way kbuild-2.5 ever get included in the kernel.

> What I'd suggest is: import
> enough of kbuild 2.5 to support the feature (in some case nothing
> needs to be imported), then make it work also for old kbuild (in
> some cases that will require no work.  This I'd call cooperation,
> which would look good on everybody involved.
Again wrong approah. Extend kbuild-2.4 with the features, tweak them until
they actually meet the requirements and then on to the next step.
Obviously the dependency step is huge, but the point is that there is
steps before and after this.

	Sam

Re: KBuild 2.5 Impressions

[Thunder from the hill]

Hi,

On Sun, 2 Jun 2002, Sam Ravnborg wrote:
> Again wrong approah. Extend kbuild-2.4 with the features, tweak them
> until they actually meet the requirements and then on to the next step.
> Obviously the dependency step is huge, but the point is that there is
> steps before and after this.

You keep missing the fact that you have kbuild-2.4 and kbuild-2.5 in the 
same tree. I told you I won't introduce bugs in order to fix them! I'm NOT 
Microsoft!

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: KBuild 2.5 Impressions

[Ion Badulescu]

On Sun, 2 Jun 2002, Thunder from the hill wrote:

> On Sun, 2 Jun 2002, Sam Ravnborg wrote:
> > Again wrong approah. Extend kbuild-2.4 with the features, tweak them
> > until they actually meet the requirements and then on to the next step.
> > Obviously the dependency step is huge, but the point is that there is
> > steps before and after this.
> 
> You keep missing the fact that you have kbuild-2.4 and kbuild-2.5 in the 
> same tree. I told you I won't introduce bugs in order to fix them! I'm NOT 
> Microsoft!

And you keep missing the fact that having both in the tree doesn't solve 
anything. Bugs are not a problem in the development series, bugs are 
found and fixed.

However, having both in the tree can mean only one of a few things:

1. kbuild24 will slowly become unmaintained
2. kbuild25 will slowly become unmaintained
3. both will be partially broken for certain newly added targets (e.g. 
author FOO adds driver BAR and only adjusts only of the kbuilds for his 
driver, and you end up with kbuild24 building certain modules and 
kbuild25 building certain other modules, ugh)
4. everybody will have to put in double work to update both kbuilds, test 
changes, etc.

None of the above looks acceptable, IMNHO.

You need to break it up FEATURE BY FEATURE, that's the only way it will go
in. Then you add one feature to the existing kbuild, test, release, get 
bug reports, fix bugs, add the next feature, rinse, repeat.

Also, don't say 'well you need the core to do this and that', it only shows 
that you don't understand the core and you're treating it like a black box.
Once you do understand it, you'll see there are many ways to break it up 
feature-wise.

Ion [swearing this is his last reply in this thread]

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.

Re: KBuild 2.5 Impressions

[Thunder from the hill]

Hi,

No matter if ya'll reply, but a few things to be mentioned:

On Sun, 2 Jun 2002, Ion Badulescu wrote:
> However, having both in the tree can mean only one of a few things:

5. the better will stay, the worse will be pulled from the tree.

> Also, don't say 'well you need the core to do this and that', it only shows 
> that you don't understand the core and you're treating it like a black box.
> Once you do understand it, you'll see there are many ways to break it up 
> feature-wise.

But other features require parts of the thing you call core which won't 
get in because they look silly without the stuff that is using it. Who 
needs a loose mdbm?

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: KBuild 2.5 Impressions

[Kai Germaschewski]

On Sun, 2 Jun 2002, Daniel Phillips wrote:

> > Can we agree that it makes sense to add features one-by-one when
> > they are independent?
> 
> Oh absolutely, and have you looked at the current factoring?
> 
>    http://marc.theaimsgroup.com/?a=102296100300003&r=1&w=2
> 
> This is still being improved, of course.

Actually, I was about to answer that issue in a reply to the mail by
Thunder, where he said that he can do a lot of patches, which do not have
any effect. Sam did actually state it already, it's not about adding which
have no effect, it's about patches which do change one thing at a time. N
patches which don't change anything and then number N+1 which changes
everything doesn't help the situation at all.

> Well, actually a lot of the work done by Kai is simply importing
> portions of Keith's work that break out easily, which is purely
> duplication of effort, since such work is already in progress.  In
> fact it creates more work, because then we have to go parse Kai's
> patches and find out what he submitted, then see if it gets applied
> so we can mark it 'applied' in the list.  This is a real waste of
> time, and did I mention, it's divisive?

Well, thanks. Maybe you have an example of what you mean above? If I take
other people's work, I credit them, and I don't think I did so far at all,
but definitely not "a lot".

I will surely pick pieces, though - this is what this process is all
about.

Anyway, since you don't understand anything about the internals of the
kbuild process at all (neither kbuild-2.4 nor 2.5), as you now proved
publically multiple times, but are just aiming at proving your abilities
in making politics on l-k, don't expect me to answer any further mails on
this (and save yourself the effort to reply to this one, but I know you
won't).

--Kai

Re: KBuild 2.5 Impressions

[Thunder from the hill]

Hi,

On Sun, 2 Jun 2002, Sam Ravnborg wrote:
> I think Linus did not want to take a patch that changed too much, and
> thats what kbuild-2.5 does. This does not change when you split it up
> file by file.

See appended. We have only 27 files which actually _changed_, the rest is 
_created_. I can submit patches for those 27 changed files, but they still 
don't make sense without the created files.

Regards,
Thunder

Creating Config.help
Creating Config.in
Creating Documentation/DocBook/Makefile.in
Creating Documentation/cdrom/Makefile.in
Creating Documentation/kbuild/kbuild-2.5-db.ps
Creating Documentation/kbuild/kbuild-2.5-db.txt
Creating Documentation/kbuild/kbuild-2.5-db.vcg
Creating Documentation/kbuild/kbuild-2.5.txt
Creating Documentation/kbuild/random.txt
Creating Makefile-2.5
Creating Makefile.in
Creating Makefile.orig
Creating arch/i386/Makefile.defs.config
Creating arch/i386/Makefile.defs.noconfig
Creating arch/i386/Makefile.in
Creating arch/i386/Makefile.orig
Creating arch/i386/asm-offsets.c
Creating arch/i386/boot/Makefile.in
Creating arch/i386/boot/bbootsect.S
Creating arch/i386/boot/bsetup.S
Creating arch/i386/boot/compressed/Makefile.in
Creating arch/i386/boot/config.install-2.5
Creating arch/i386/boot/rules-2.5.cml
Creating arch/i386/boot/tools/Makefile.in
Creating arch/i386/kernel/Makefile.in
Creating arch/i386/lib/Makefile.in
Creating arch/i386/math-emu/Makefile.in
Creating arch/i386/mm/Makefile.in
Creating arch/i386/pci/Makefile.in
Creating arch/i386/vmlinux.lds.S
Creating arch/s390/Makefile.defs.config
Creating arch/s390/Makefile.defs.noconfig
Creating arch/s390/Makefile.in
Creating arch/s390/Makefile.orig
Creating arch/s390/asm-offsets.c
Creating arch/s390/boot/Makefile.in
Creating arch/s390/boot/config.install-2.5
Creating arch/s390/kernel/Makefile.in
Creating arch/s390/lib/Makefile.in
Creating arch/s390/math-emu/Makefile.in
Creating arch/s390/mm/Makefile.in
Creating arch/s390/vmlinux.lds.S
Creating arch/s390x/Makefile.defs.config
Creating arch/s390x/Makefile.defs.noconfig
Creating arch/s390x/Makefile.in
Creating arch/s390x/Makefile.orig
Creating arch/s390x/asm-offsets.c
Creating arch/s390x/boot/Makefile.in
Creating arch/s390x/boot/config.install-2.5
Creating arch/s390x/kernel/Makefile.in
Creating arch/s390x/lib/Makefile.in
Creating arch/s390x/mm/Makefile.in
Creating arch/s390x/vmlinux.lds.S
Creating arch/sparc64/Makefile.defs.config
Creating arch/sparc64/Makefile.defs.noconfig
Creating arch/sparc64/Makefile.in
Creating arch/sparc64/asm-offsets.c
Creating arch/sparc64/boot/Makefile.in
Creating arch/sparc64/boot/config.install-2.5
Creating arch/sparc64/boot/rules-2.5.cml
Creating arch/sparc64/kernel/Makefile.in
Creating arch/sparc64/lib/Makefile.in
Creating arch/sparc64/math-emu/Makefile.in
Creating arch/sparc64/mm/Makefile.in
Creating arch/sparc64/prom/Makefile.in
Creating arch/sparc64/solaris/Makefile.in
Creating arch/sparc64/vmlinux.lds.S
Creating drivers/Makefile.in
Creating drivers/acorn/Makefile.in
Creating drivers/acorn/block/Makefile.in
Creating drivers/acorn/char/Makefile.in
Creating drivers/acorn/char/defkeymap-acorn.c_shipped
Creating drivers/acorn/char/defkeymap-acorn.c_sum
Creating drivers/acorn/net/Makefile.in
Creating drivers/acorn/scsi/Makefile.in
Creating drivers/acpi/Makefile.in
Creating drivers/acpi/debugger/Makefile.in
Creating drivers/acpi/dispatcher/Makefile.in
Creating drivers/acpi/events/Makefile.in
Creating drivers/acpi/executer/Makefile.in
Creating drivers/acpi/hardware/Makefile.in
Creating drivers/acpi/namespace/Makefile.in
Creating drivers/acpi/parser/Makefile.in
Creating drivers/acpi/resources/Makefile.in
Creating drivers/acpi/tables/Makefile.in
Creating drivers/acpi/utilities/Makefile.in
Creating drivers/atm/Makefile.in
Creating drivers/base/Makefile.in
Creating drivers/block/Makefile.in
Creating drivers/block/paride/Makefile.in
Creating drivers/bluetooth/Makefile.in
Creating drivers/cdrom/Makefile.in
Creating drivers/char/Makefile.in
Creating drivers/char/agp/Makefile.in
Creating drivers/char/defkeymap.c_shipped
Creating drivers/char/defkeymap.c_sum
Creating drivers/char/drm/Makefile.in
Creating drivers/char/ftape/Makefile.in
Creating drivers/char/ftape/compressor/Makefile.in
Creating drivers/char/ftape/lowlevel/Makefile.in
Creating drivers/char/ftape/zftape/Makefile.in
Creating drivers/char/ip2/Makefile.in
Creating drivers/char/mwave/Makefile.in
Creating drivers/char/pcmcia/Makefile.in
Creating drivers/char/qtronixmap.c_shipped
Creating drivers/char/qtronixmap.c_sum
Creating drivers/char/rio/Makefile.in
Creating drivers/dio/Makefile.in
Creating drivers/fc4/Makefile.in
Creating drivers/hotplug/Makefile.in
Creating drivers/i2c/Makefile.in
Creating drivers/ide/Makefile.in
Creating drivers/ieee1394/Makefile.in
Creating drivers/input/Makefile.in
Creating drivers/input/gameport/Makefile.in
Creating drivers/input/joystick/Makefile.in
Creating drivers/input/serio/Makefile.in
Creating drivers/isdn/Makefile.in
Creating drivers/isdn/act2000/Makefile.in
Creating drivers/isdn/capi/Makefile.in
Creating drivers/isdn/divert/Makefile.in
Creating drivers/isdn/eicon/Makefile.in
Creating drivers/isdn/hardware/Makefile.in
Creating drivers/isdn/hardware/avm/Makefile.in
Creating drivers/isdn/hisax/Makefile.in
Creating drivers/isdn/hysdn/Makefile.in
Creating drivers/isdn/i4l/Makefile.in
Creating drivers/isdn/icn/Makefile.in
Creating drivers/isdn/isdnloop/Makefile.in
Creating drivers/isdn/pcbit/Makefile.in
Creating drivers/isdn/sc/Makefile.in
Creating drivers/isdn/tpam/Makefile.in
Creating drivers/macintosh/Makefile.in
Creating drivers/md/Makefile.in
Creating drivers/media/Makefile.in
Creating drivers/media/radio/Makefile.in
Creating drivers/media/video/Makefile.in
Creating drivers/message/Makefile.in
Creating drivers/message/fusion/Makefile.in
Creating drivers/message/i2o/Makefile.in
Creating drivers/misc/Makefile.in
Creating drivers/mtd/Makefile.in
Creating drivers/mtd/chips/Makefile.in
Creating drivers/mtd/devices/Makefile.in
Creating drivers/mtd/maps/Makefile.in
Creating drivers/mtd/nand/Makefile.in
Creating drivers/net/Makefile.in
Creating drivers/net/appletalk/Makefile.in
Creating drivers/net/arcnet/Makefile.in
Creating drivers/net/e100/Makefile.in
Creating drivers/net/e1000/Makefile.in
Creating drivers/net/fc/Makefile.in
Creating drivers/net/hamradio/Makefile.in
Creating drivers/net/hamradio/soundmodem/Makefile.in
Creating drivers/net/irda/Makefile.in
Creating drivers/net/pcmcia/Makefile.in
Creating drivers/net/sk98lin/Makefile.in
Creating drivers/net/skfp/Makefile.in
Creating drivers/net/tokenring/Makefile.in
Creating drivers/net/tulip/Makefile.in
Creating drivers/net/wan/Makefile.in
Creating drivers/net/wan/lmc/Makefile.in
Creating drivers/net/wireless/Makefile.in
Creating drivers/nubus/Makefile.in
Creating drivers/parport/Makefile.in
Creating drivers/pci/Makefile.in
Creating drivers/pcmcia/Makefile.in
Creating drivers/pnp/Makefile.in
Creating drivers/s390/Makefile.in
Creating drivers/s390/block/Makefile.in
Creating drivers/s390/char/Makefile.in
Creating drivers/s390/misc/Makefile.in
Creating drivers/s390/net/Makefile.in
Creating drivers/sbus/Makefile.in
Creating drivers/sbus/audio/Makefile.in
Creating drivers/sbus/char/Makefile.in
Creating drivers/scsi/53c700_d.h_shipped
Creating drivers/scsi/53c700_sum
Creating drivers/scsi/53c700_u.h_shipped
Creating drivers/scsi/53c7xx_d.h_shipped
Creating drivers/scsi/53c7xx_sum
Creating drivers/scsi/53c7xx_u.h_shipped
Creating drivers/scsi/53c8xx_d.h_shipped
Creating drivers/scsi/53c8xx_sum
Creating drivers/scsi/53c8xx_u.h_shipped
Creating drivers/scsi/Makefile.in
Creating drivers/scsi/aic7xxx/Makefile.in
Creating drivers/scsi/aic7xxx/aicasm/Makefile.in
Creating drivers/scsi/pcmcia/Makefile.in
Creating drivers/scsi/pcmcia/aha152x_inc.c
Creating drivers/scsi/pcmcia/fdomain_inc.c
Creating drivers/scsi/pcmcia/qlogicfas_inc.c
Creating drivers/scsi/sim710_d.h_shipped
Creating drivers/scsi/sim710_sum
Creating drivers/scsi/sim710_u.h_shipped
Creating drivers/scsi/sym53c8xx_2/Makefile.in
Creating drivers/sgi/Makefile.in
Creating drivers/sgi/char/Makefile.in
Creating drivers/tc/Makefile.in
Creating drivers/tc/lk201-map.c_shipped
Creating drivers/tc/lk201-map.c_sum
Creating drivers/telephony/Makefile.in
Creating drivers/usb/Makefile.in
Creating drivers/usb/class/Makefile.in
Creating drivers/usb/core/Makefile.in
Creating drivers/usb/host/Makefile.in
Creating drivers/usb/image/Makefile.in
Creating drivers/usb/input/Makefile.in
Creating drivers/usb/media/Makefile.in
Creating drivers/usb/misc/Makefile.in
Creating drivers/usb/net/Makefile.in
Creating drivers/usb/serial/Makefile.in
Creating drivers/usb/storage/Makefile.in
Creating drivers/video/Makefile.in
Creating drivers/video/aty/Makefile.in
Creating drivers/video/matrox/Makefile.in
Creating drivers/video/riva/Makefile.in
Creating drivers/video/sis/Makefile.in
Creating drivers/zorro/Makefile.in
Creating fs/Makefile.in
Creating fs/adfs/Makefile.in
Creating fs/affs/Makefile.in
Creating fs/autofs/Makefile.in
Creating fs/autofs4/Makefile.in
Creating fs/bfs/Makefile.in
Creating fs/coda/Makefile.in
Creating fs/cramfs/Makefile.in
Creating fs/devfs/Makefile.in
Creating fs/devpts/Makefile.in
Creating fs/driverfs/Makefile.in
Creating fs/efs/Makefile.in
Creating fs/exportfs/Makefile.in
Creating fs/ext2/Makefile.in
Creating fs/ext3/Makefile.in
Creating fs/fat/Makefile.in
Creating fs/freevxfs/Makefile.in
Creating fs/hfs/Makefile.in
Creating fs/hpfs/Makefile.in
Creating fs/intermezzo/Makefile.in
Creating fs/isofs/Makefile.in
Creating fs/jbd/Makefile.in
Creating fs/jffs/Makefile.in
Creating fs/jffs2/Makefile.in
Creating fs/jfs/Makefile.in
Creating fs/lockd/Makefile.in
Creating fs/minix/Makefile.in
Creating fs/msdos/Makefile.in
Creating fs/ncpfs/Makefile.in
Creating fs/nfs/Makefile.in
Creating fs/nfsd/Makefile.in
Creating fs/nls/Makefile.in
Creating fs/ntfs/Makefile.in
Creating fs/openpromfs/Makefile.in
Creating fs/partitions/Makefile.in
Creating fs/proc/Makefile.in
Creating fs/qnx4/Makefile.in
Creating fs/ramfs/Makefile.in
Creating fs/reiserfs/Makefile.in
Creating fs/romfs/Makefile.in
Creating fs/smbfs/Makefile.in
Creating fs/sysv/Makefile.in
Creating fs/udf/Makefile.in
Creating fs/ufs/Makefile.in
Creating fs/umsdos/Makefile.in
Creating fs/vfat/Makefile.in
Creating have_config
Creating init/Makefile.in
Creating ipc/Makefile.in
Creating kernel/Makefile.in
Creating lib/Makefile.in
Creating lib/zlib_deflate/Makefile.in
Creating lib/zlib_inflate/Makefile.in
Creating mm/Makefile.in
Creating net/802/Makefile.in
Creating net/802/pseudo/Makefile.in
Creating net/802/transit/Makefile.in
Creating net/8021q/Makefile.in
Creating net/Makefile.in
Creating net/appletalk/Makefile.in
Creating net/atm/Makefile.in
Creating net/ax25/Makefile.in
Creating net/bluetooth/Makefile.in
Creating net/bridge/Makefile.in
Creating net/core/Makefile.in
Creating net/decnet/Makefile.in
Creating net/econet/Makefile.in
Creating net/ethernet/Makefile.in
Creating net/ipv4/Makefile.in
Creating net/ipv4/netfilter/Makefile.in
Creating net/ipv6/Makefile.in
Creating net/ipv6/netfilter/Makefile.in
Creating net/ipx/Makefile.in
Creating net/irda/Makefile.in
Creating net/irda/ircomm/Makefile.in
Creating net/irda/irlan/Makefile.in
Creating net/irda/irnet/Makefile.in
Creating net/khttpd/Makefile.in
Creating net/lapb/Makefile.in
Creating net/netlink/Makefile.in
Creating net/netrom/Makefile.in
Creating net/packet/Makefile.in
Creating net/rose/Makefile.in
Creating net/sched/Makefile.in
Creating net/sunrpc/Makefile.in
Creating net/unix/Makefile.in
Creating net/wanrouter/Makefile.in
Creating net/x25/Makefile.in
Creating scripts/Makefile-2.5
Creating scripts/Makefile.in
Creating scripts/find_srcfile
Creating scripts/get_one_config
Creating scripts/include_list.awk
Creating scripts/kwhich
Creating scripts/lilo_new_kernel
Creating scripts/lxdialog/Makefile-2.5
Creating scripts/mdbm/COPYING
Creating scripts/mdbm/README
Creating scripts/mdbm/byte_order.c
Creating scripts/mdbm/common.h
Creating scripts/mdbm/debug.c
Creating scripts/mdbm/hash.c
Creating scripts/mdbm/mdbm.c
Creating scripts/mdbm/mdbm.h
Creating scripts/mdbm/mtst.c
Creating scripts/mdbm/tune.h
Creating scripts/pp_db.c
Creating scripts/pp_db.h
Creating scripts/pp_dbdump.c
Creating scripts/pp_env.c
Creating scripts/pp_makefile.h
Creating scripts/pp_makefile1.c
Creating scripts/pp_makefile2.c
Creating scripts/pp_makefile2_parse.l
Creating scripts/pp_makefile2_parse.lex.c_shipped
Creating scripts/pp_makefile2_parse.tab.c_shipped
Creating scripts/pp_makefile2_parse.tab.h_shipped
Creating scripts/pp_makefile2_parse.y
Creating scripts/pp_makefile2_parse_sum
Creating scripts/pp_makefile4.c
Creating scripts/pp_makefile5.c
Creating scripts/shadow.pl
Creating sound/Makefile.in
Creating sound/arm/Makefile.in
Creating sound/core/Makefile.in
Creating sound/core/ioctl32/Makefile.in
Creating sound/core/oss/Makefile.in
Creating sound/core/seq/Makefile.in
Creating sound/core/seq/instr/Makefile.in
Creating sound/core/seq/oss/Makefile.in
Creating sound/drivers/Makefile.in
Creating sound/drivers/mpu401/Makefile.in
Creating sound/drivers/opl3/Makefile.in
Creating sound/i2c/Makefile.in
Creating sound/i2c/l3/Makefile.in
Creating sound/isa/Makefile.in
Creating sound/isa/ad1816a/Makefile.in
Creating sound/isa/ad1848/Makefile.in
Creating sound/isa/cs423x/Makefile.in
Creating sound/isa/es1688/Makefile.in
Creating sound/isa/gus/Makefile.in
Creating sound/isa/opti9xx/Makefile.in
Creating sound/isa/sb/Makefile.in
Creating sound/isa/wavefront/Makefile.in
Creating sound/oss/Makefile.in
Creating sound/oss/cs4281/Makefile.in
Creating sound/oss/dmasound/Makefile.in
Creating sound/oss/emu10k1/Makefile.in
Creating sound/pci/Makefile.in
Creating sound/pci/ac97/Makefile.in
Creating sound/pci/ali5451/Makefile.in
Creating sound/pci/cs46xx/Makefile.in
Creating sound/pci/emu10k1/Makefile.in
Creating sound/pci/korg1212/Makefile.in
Creating sound/pci/nm256/Makefile.in
Creating sound/pci/rme9652/Makefile.in
Creating sound/pci/trident/Makefile.in
Creating sound/pci/ymfpci/Makefile.in
Creating sound/ppc/Makefile.in
Creating sound/synth/Makefile.in
Creating sound/synth/emux/Makefile.in
Creating symbols-2.5.cml
Updating Documentation/kbuild/00-INDEX
Updating Makefile
Updating arch/i386/Makefile
Updating arch/s390/Makefile
Updating arch/s390x/Makefile
Updating arch/sparc64/kernel/entry.S
Updating arch/sparc64/kernel/etrap.S
Updating arch/sparc64/kernel/head.S
Updating arch/sparc64/kernel/trampoline.S
Updating arch/sparc64/kernel/traps.c
Updating arch/sparc64/lib/VIScopy.S
Updating arch/sparc64/lib/VIScsum.S
Updating arch/sparc64/lib/VIScsumcopy.S
Updating arch/sparc64/lib/VIScsumcopyusr.S
Updating arch/sparc64/lib/VISsave.S
Updating arch/sparc64/solaris/entry64.S
Updating drivers/scsi/script_asm.pl
Updating include/asm-sparc64/system.h
Updating include/asm-sparc64/thread_info.h
Updating include/linux/module.h
Updating scripts/Configure
Updating scripts/Menuconfig
Updating scripts/kernel-doc
Updating scripts/mkdep.c
Updating scripts/split-include.c
Updating scripts/tkparse.c
Updating scripts/tkparse.h

Created: 381 files, patched: 27 files
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: KBuild 2.5 Impressions

[Peter Osterlund]

Daniel Phillips <phillips@bonn-fries.net> writes:

> I wanted to know how well kbuild 2.5 really works, so I got the patches
> from kbuild.sourceforge.net and gave them a test drive, comparing to
> old kbuild.

I currently have three problems with kbuild 2.5:

1. make TAGS doesn't work.

2. NO_MAKEFILE_GEN is unsupported and therefore likely to stop working
   in future kernels. The documentation says:

        Bug reports against kbuild when you used NO_MAKEFILE_GEN will
        be ignored.

   NO_MAKEFILE_GEN is about 8.4 times faster when you want to create a
   single .o file on my 2.2GHz P4 system. It doesn't matter that much
   on a fast machine, but my old PPro 200MHz machine required
   something like 40s just to process the makefiles.

3. You have to remember the "-f Makefile-2.5" arguments to make,
   otherwise it will use the old makefile system. This seems to mess
   things up so that subsequent make commands fail.
   I tried to "mv Makefile-2.5 Makefile" to overcome this problem, but
   it doesn't work because the original Makefile appears to be needed
   for extracting kernel version information.

-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: KBuild 2.5 Impressions

[Thunder from the hill]

Hi,

On 2 Jun 2002, Peter Osterlund wrote:
> 3. You have to remember the "-f Makefile-2.5" arguments to make,
>    otherwise it will use the old makefile system. This seems to mess
>    things up so that subsequent make commands fail.
>    I tried to "mv Makefile-2.5 Makefile" to overcome this problem, but
>    it doesn't work because the original Makefile appears to be needed
>    for extracting kernel version information.

There was no intention to reinvent the wheel. The only _replacing_ 
Makefile is a _merged_ version of them. Then you'll also have to find any 
Makefile-2.5s and revert them to Makefiles. This will take a moment, and 
is not yet intented.

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: KBuild 2.5 Impressions

[Peter Osterlund]

Thunder from the hill <thunder@ngforever.de> writes:

> On 2 Jun 2002, Peter Osterlund wrote:
> > 3. You have to remember the "-f Makefile-2.5" arguments to make,
> >    otherwise it will use the old makefile system. This seems to mess
> >    things up so that subsequent make commands fail.
> >    I tried to "mv Makefile-2.5 Makefile" to overcome this problem, but
> >    it doesn't work because the original Makefile appears to be needed
> >    for extracting kernel version information.
> 
> There was no intention to reinvent the wheel. The only _replacing_ 
> Makefile is a _merged_ version of them. Then you'll also have to find any 
> Makefile-2.5s and revert them to Makefiles. This will take a moment, and 
> is not yet intented.

Yes, I realize this problem will go away automatically when support
for the old makefile system is removed. I just wanted to present my
complete list of problems with kbuild 2.5. Except for those three
issues, I don't see any advantages with the old makefile system.

-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: KBuild 2.5 Impressions

[Thunder from the hill]

Hi,

On 2 Jun 2002, Peter Osterlund wrote:
> Yes, I realize this problem will go away automatically when support
> for the old makefile system is removed. I just wanted to present my
> complete list of problems with kbuild 2.5. Except for those three
> issues, I don't see any advantages with the old makefile system.

Well, problem #1 (make TAGS) - what did you use it for?
Problem #2 (make NO_MAKEFILE_GEN) is a bit tricky with the new concept. 
You may try to implement it, but I wonder where you'll end up.
Problem #3 is a migration problem...

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: KBuild 2.5 Impressions

[Thunder from the hill]

Hi,

On Sun, 2 Jun 2002, Thunder from the hill wrote:
> You may try to implement it, but I wonder where you'll end up.
maintain         ^^^^^^^^^

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: KBuild 2.5 Impressions

[Peter Osterlund]

Thunder from the hill <thunder@ngforever.de> writes:

> Hi,
> 
> On 2 Jun 2002, Peter Osterlund wrote:
> > Yes, I realize this problem will go away automatically when support
> > for the old makefile system is removed. I just wanted to present my
> > complete list of problems with kbuild 2.5. Except for those three
> > issues, I don't see any advantages with the old makefile system.
> 
> Well, problem #1 (make TAGS) - what did you use it for?

To create a TAGS file for emacs, which makes navigating the source
tree a lot easier.

> Problem #2 (make NO_MAKEFILE_GEN) is a bit tricky with the new concept. 
> You may try to maintain it, but I wonder where you'll end up.

On my system I get 0.40s with NO_MAKEFILE_GEN compared to 3.41s
without, so my system is fast enough even without NO_MAKEFILE_GEN. I
just find it strange that the documentation says bug reports will be
ignored. If it breaks unintentionally in future kernels, fixing it
would probably not be too hard. Or are you planning to remove this
feature altogether?

-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: KBuild 2.5 Impressions

[Daniel Phillips]

On Sunday 02 June 2002 14:51, Peter Osterlund wrote:
> Thunder from the hill <thunder@ngforever.de> writes:
> > Problem #2 (make NO_MAKEFILE_GEN) is a bit tricky with the new concept. 
> > You may try to maintain it, but I wonder where you'll end up.
> 
> On my system I get 0.40s with NO_MAKEFILE_GEN compared to 3.41s
> without, so my system is fast enough even without NO_MAKEFILE_GEN. I
> just find it strange that the documentation says bug reports will be
> ignored. If it breaks unintentionally in future kernels, fixing it
> would probably not be too hard. Or are you planning to remove this
> feature altogether?

I think what he's saying is that the feature is a hack and isn't supposed
to work properly all the time, so don't complain about if it doesn't.  I
think that's a reasonable attitude.  There's yet more speed to be gained
by building the proper machinery for deciding reliably when the makefile
has to be rebuilt, and maybe doing the job incrementally, but that's not
the task at hand, that's a project for somebody to take their time and
do properly later.  It's exactly this kind of work Keith has provided a
solid base for.

FYI, the way it works is, it just fails to do the makefile rebuild,
relying on human intelligence and experience to know that nothing
changed that would require a rebuild.  IOW, use at your own risk.  I
doubt this feature will go away, because anything that speeds up a
edit/compile/kaboom cycle that much is going to be happily used by a
significant number of madmen.  If it breaks for some reason, such as
a new feature of bugfix that requires the makefile to *always* be
updated, somebody will step up to fix it.

-- 
Daniel

Re: KBuild 2.5 Impressions

[Dan Kegel]

Daniel Phillips wrote:
> Well, actually a lot of the work done by Kai is simply importing
> portions of Keith's work that break out easily, which is purely
> duplication of effort, since such work is already in progress.  In
> fact it creates more work, because then we have to go parse Kai's
> patches and find out what he submitted, then see if it gets applied
> so we can mark it 'applied' in the list.  This is a real waste of
> time, and did I mention, it's divisive?

Linus sees Kai as being the most promising fellow to
integrate kbuild2.5 right now (see
http://marc.theaimsgroup.com/?l=linux-kernel&m=102307114005894&w=2 )
and Kai is willing to take it on in just the way Linus wants.
It's probably worth giving Kai and Linus the benefit of the doubt for a while,
even if it does mean having to rejigger the kbuild-2.5 patch
each time Linux accepts one of Kai's patches.

I personally am anxious to see kbuild-2.5 make it into the kernel,
but I also feel it can only benefit from a strong review of
the sort that comes about during gradual evolution
of the kernel build process towards the techniques used by kbuild-2.5.

Thanks to everyone, Keith, Daniel, Thunder, and Kai, who are
working (together or not!) on moving the kernel build process
into the modern era.
- Dan

Re: KBuild 2.5 Impressions

[Linus Torvalds]

In article <3CFAD94B.F848897B@kegel.com>, Dan Kegel  <dank@kegel.com> wrote:
>
>Linus sees Kai as being the most promising fellow to
>integrate kbuild2.5 right now [...]

Side note, just to explain _why_ I prefer it done this way, so that
people can understand - even if they don't necessarily have to agree
with - why this is my preferred approach.

There's actually several reasons:

 - I always hate "flag day" patches. Do they happen? Sure. Some people
   have already given examples of such big flag-day patches, the ALSA
   merge being one prime example.  That doesn't mean that I like them
   any more for that.

   In short: if at all possible, I _much_ prefer gradual merges, where
   "gradual" really means that features are added one-by-one (and that
   does _not_ mean "build up the infrastructure slowly, so that the
   final 'flag-day' patch itself is small but has large ramifications")

 - Kai has already shown that he can merge with me easily, and actually
   took one traditional flag-day-project (ISDN: every single merge was a
   flag-day merge), and has turned that into a very easy gradual merge
   for me. I used to dread ISDN merges, these days I don't even have to
   think about them.

 - Kai obviously already knows the build system, as he has been doing a
   lot of incremental stuff on it already.

 - Kai isn't an enthusiastic kbuild-2.5 supporter. In fact, he tends to
   be a bit down on some of it. Which is a plus in my book: it means
   that whatever Kai tries to push my way I'll feel just that much more
   comfortable with as having had critical review.

So let's see how it works out.  Maybe it won't, but this would seem
workable at least in theory. 

		Linus