Re: [Gnu-arch-users] preparing to stress test tla with linux-2.5

[Tupshin Harper]

Tom Lord wrote:

>    > From: Tupshin Harper <address@hidden>
>
>    > Can you explain your thoughts on this? Do you mean (for example) that 
>    > high level kernel subdirectories would be different projects? Is there 
>    > any rationale for this besides arch performance? How would changesets 
>    > that span multiple projects work?
>
>
> Lot's of little rationales rather than just one big one.  Here's some:
>
> Arch performance is one reason -- but the relevence to arch
> performance is relvent to plenty of other things as well.  In general,
> when streaming the source in a "unit of management" through some
> process takes so long that it's uncomfortable, maybe it's time to
> reduce the "unit of management" size. 
This is all well and good, but when most tasks would need to be 
performed against all of the smaller units, then the subdivision isn't 
beneficial and just becomes an administrative hindrance. There are very 
few things that I would want to do with the kernel source that would be 
meaningful to do with only one part of the source.

> (and, again, the upcoming
> inode-signature optimization will greatly reduce the number of
> circumstances under which arch wants to read the whole tree and yadda
> yadda yadda.  (But no such optimization is forseen for, say, grep,
> agrep notwithstanding.))
>
> Another reason to partition the source when it gets that large is to
> make it harder to make the parts _that_ interdependent.  It's a way to
> encourage better engineering.
This is certainly the case, but for better or for worse, the linux 
kernel isn't strongly segmented this way, and I'm certainly not 
expecting to have much influence making it so. ;-) It's probably 
necessary to view the linux kernel as a severe corner case in respect to 
arch. It is one of the largest bodies of code that it will have to deal 
with, and it is simultaneously one of the least amenable to 
segmentation. That, combined with it's widespread use, is why it is 
such  an ideal test case. If arch works there, it is hard to envision a 
body of code that it wouldn't work for.

> Changesets spanning multiple trees?  That's part of what configs are
> for.  Committing a top-level, config-containing directory is
> effectively an atomic commit across multiple sub-projects.
>  
Thanks..this is one area I haven't explored yet.

-Tupshin