gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom Lord
Subject: Re: [Gnu-arch-users] preparing to stress test tla with linux-2.5
Date: Sun, 24 Aug 2003 16:36:29 -0700 (PDT)


    > From: Miles Bader <address@hidden>

    > On Sun, Aug 24, 2003 at 03:24:09PM -0700, Tom Lord wrote:
    > >  And to the list of people to whom I should, in some sense, be 
advocating
    > > breaking the kernel up into a multi-project config.

    > Hmmm, while I appreciate that often its nice to compose source trees from
    > multiple sources, I currently think of configs as an `extra layer of
    > annoyance' and since I'm quite used to treating the kernel as as a single 
big
    > tree, cringe a bit at having to use configs for it.

With respect, that you think of the kernel as a single big tree makes
me glad I don't use that kernel.


    > No doubt this is partly my ignorance about configs (really I have only 
used
    > them to get Tom's source tree for tla set up).

Yeah, configs are cool.   You'll get into them eventually.


    > I guess my main beef is the way they seem to interfere with the nice 
`single
    > command operates on/produces a single tree' property of arch/tla, and 
that I
    > to stop and think about the fact that `OH, in _this_ tree (or part of a 
tree)
    > I have to use special commands because it uses configs.'  

Sure, but I think that strongly correlates with a good software architecture.


    > In the case of the kernel, there are natural boundaries for organizational
    > splits -- e.g., the various arch/ subdirs -- but existing development 
styles
    > definitely treat it all as `one big tree', and it's not uncommon for 
single
    > changes to pervasively affect the whole tree, regardless of organizational
    > boundaries.

Sounds mostly like a meta-bug in the kernel.


    > So, I'm not sure what my real point is other than (1) configs currently 
seem
    > annoyingly clunky, and (2) it's not clear that in their current form they
    > really fit with existing kernel development style.


I agree with (2) and about (1) -- there's plenty of room to beef up
the arch command set to maximize the convenience of configs in arch.


-t






reply via email to

[Prev in Thread] Current Thread [Next in Thread]