On Sun, Sep 23, 2007 at 08:03:35AM +0200, Sam Ravnborg wrote:
> > > Please Oleg.
> > > You know very well that most people will not have their kernel src RO.
> >
> > Sure, if it will be not comfortable.
> >
> > But if kbuild deals with this transparently, it must be OK. Brokenness
> > due to binutils, kbuild, root user bugs won't garbage source. Only thing
> > to ask from experienced users *and* kernel developers, is
> > `useradd kbuild`, everything else will not bother anybody.
> Better would be to fix the bugs where we today clobber the sources.
> Care to point out the exact cases you see.
It is not about particular case, it is about whole environment.
* interactive:
shell (profile setup).--> source editing / patching
`-> building parts / doing tests
where profile is one particular source tree with particular
config/development goals. On multiple terminals (sessions), one
may just type in favorite shell `wana profile-xx` and environment
is set up there. I.e.
+ where ever you are, it's easy to go to current obj or src tree,
+ quilt knows its setup
+ kbuild does also
+ tracking files, sent to editor (e.g. emacsclient / emacsserver)
o easily composing file / change sets to be operated by quilt
o kbuild knows exactly what to check and possibly to rebuild
+ all actions are written to history, that can be imported into any session
o saving sessions
o restore sessions: checking profile consistency / updating
+ less ugly (e.g. just stupid bash command line) user interface
o even ordinary command line can be improved much-much more in
terms of efficiency and comfort
o more nice-looking information of what is happening and how is
happening
* automatic:
running setup of selected profiles:
o patch/update sources
o configure and (cross) build multiple source trees with multiple output
trees each.
o run time testing: emulators, hardware.
Many ideas, collected in kbuild-2.5-history.tar.bz2 back in 2000, are
still interesting and useful.
More i do development, more i realize, that i spend too much time to
do trivial and repeating things. And this time will not go less, if
something like that will be by hand.
I'd really like to see a work flow of best development staff, because
behind patches i can not see anything. And frankly, i doubt there's
anything significant there. The only sharing of tools i can see is
patch scripts (now quilt), diff-tools, linux/scripts. Still just tools.
There's no environment, where people would know particular configs for
editors, mailers, 2-3 steps easy to get right help messages, i.e
*environment*. UI tricks, like common, most useful, sh aliases for using
tools, different color schemas: for error/log output, editing C or asm
(with linux specific annotations, rules), tools like checkpatch, but not
checkpatch -- helper for developers to get changes checked and ready to
create actual patch, etc. etc. etc....
For example, i'd really like to have, candy C + diff color fontlocking
(emacs' brain damaged lexicon) for easy patch reviewing. I did some
trivial enhancements more than 3 years ago, like highlighting of actions
that change variable's value, thus, i don't do many stupid things in C any
more. I'd like to have candy fontlocking for sed and shell and
sed-in-shell syntax, etc. etc.
And all this is needed just for stupid terminal emulator. So, what
people are doing all this time? Noo, X? There's no X, period.
____
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
