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

[Tom Lord]

    > From: Tupshin Harper <address@hidden>

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

It's really not that much of a hassle, in my experience, to modify the
subtrees, commit them individually on your branches, and then commit
a config snap of them.

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

That is pretty much how I see it.

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

And, again, the inode-sig stuff is what should make a big difference.

-t