lkml.org 
[lkml]   [2010]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT] kbuild changes for 2.6.35


On Mon, 31 May 2010, Michal Marek wrote:
> >
> > I refuse to take stuff like this. If I don't know why somethign happens, I
> > don't want to pull it.
>
> Sorry, here is a more complete description of the changes.
> Alternatively, would you pull a branch with the section rename stuff taken
> out?

No, the commits themselves are likely fine, although for the future it
really would be good to make things like that more descriptive. I just
want people to try to argue for _why_ I should do a pull, and _what_ I'm
getting in their "please pull" thing.

It's not always necessary, and some people do it better than others. For
an example of a really good pull request, look at the ones David Miller
sends me for networking - they explain what's going on in the pull, so
it's always easy to pull them because just the request makes me feel like
David is really on top of things, and lets me have some 30'000 ft overview
of what's going on.

At the same time, in many cases I obviously pull _without_ any kind of
real explanation - and that tends to be especially true with maintainers
that I've worked with for a long time, or areas that are so specialized
that they are almost self-explanatory (let's be honest: when a filesystem
maintainer asks me to pull their special filesystem, I'm perfectly happy
with the overview of "30 changesets to XFS", and there's no need for much
explanation, although a rough overview of what's been going on is always
good to see).

So the reason I ask for explanations for kbuild is that not only have we
had different maintainers, it's an area that affects a lot of different
things and has historically had issues with odd architectures or old
binutils tools etc.

So for something like that, I really do want to know what is going on, and
then when I get a pull request with little to no explanation, and look at
a trial pull with "gitk ORIG_HEAD.." and see no additional explanation
there either, I just go "no, I can't pull this, I don't really know what
it does or why it does so".

> Summary of the changes:
> - A new configuration interface (make nconfig)
> - Improvements to the other *config interfaces
> - Better modpost mismatch reporting
> - Section rename to allow for -ffunction-sections -fdata-sections
> - Untagged builds without LOCALVERSION_AUTO have a '+' appended to the
> version string
> - Lots of minor fixes & improvements.

So I really want to know _why_ that section rename is specifically like it
is. Why is ".data..stack" better than ".data.stack"?

Linus


\
 
 \ /
  Last update: 2010-06-01 17:43    [W:0.039 / U:0.700 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site