No cute April 1st shenanigans, just a regular -rc release that happened to

come up today because I was waiting for the input layer oops-fixes to be

ready and tested.
I think the dirstat continues to be fairly informative, with arch/ and

drivers dominating as usual. And within arch, a fair amount of the line

noise are all those defconfigs. I wish we had some saner way of handling

that, but apart from causing noise in the statistics there aren't any real

downsides. Anyway, here is:
	  15.2% arch/mips/configs/

	  17.5% arch/mips/

	   2.3% arch/powerpc/configs/

	   3.1% arch/powerpc/

	   7.8% arch/sparc64/kernel/

	   8.1% arch/sparc64/

	   4.3% arch/x86/kernel/

	   2.0% arch/x86/lguest/

	   3.2% arch/x86/mach-rdc321x/

	  11.0% arch/x86/

	  40.6% arch/

	   2.2% drivers/char/

	   2.6% drivers/lguest/

	   2.3% drivers/net/igb/

	   8.7% drivers/net/netxen/

	   2.1% drivers/net/phy/

	  15.8% drivers/net/

	  30.6% drivers/

	   4.7% fs/

	   5.0% include/asm-sh/

	   8.6% include/

	   3.9% net/

	   7.5% scripts/
but the bulk of the fixes are the usual random one-liners. Some of the

"bulk" above (like the arch/x86/kernel changes) are actually just moving

some functions around in a file, so they look like larger diffs than they

actually are.
A lot of the one-liners are some sparse cleanups, which is probably

unnecessary noise at this point, but when Al sends me a series I just tend

to apply it because his patches tend to be rather careful and basically

always correct.
The big thing that is actually *noticeable* to most people is that this

should fix the two top regressions: we've had some suspend-resume

regressions due to the stupid ACPI _PTS orderign issues, and while the

cleanups were left, the ordering changes were reverted. So that should fix

issues for some people (of course, the people who had it fixed are

unhappy, but regressions are worse).
The other thing that bit a number of people and is now fixed (and that

also probably often showed up as ...
[ message continues ]

On Tue, 1 Apr 2008 13:08:57 -0700 (PDT) Linus Torvalds <torvalds@linux-foun=
The downside is that at least some of these were already pending in

maintainers trees for 2.6.26 (among other changes) and so have now caused

(unnecessary) merge conflicts.  Is there some reason that these fixes

can't go through the subsystem trees (especially once we get past rc1 (or

2) and people are gearing up for the next merge window)?
--=20

Cheers,

Stephen Rothwell                    sfr@canb.auug.org.au

http://www.canb.auug.org.au/~sfr/

I don't think it's necessarily a bad idea to go through subsystem trees,

but on the other hand I also don't think it should necessarily be a goal

in itself.
For example, we had a patch-series from Roland McGrath that was apparently

almost entirely based on the fact that going through (and getting

sign-off) from all the architecture maintainers for his ptrace changes was

just painful as hell for him.
At that point, when there is somebody like Roland who knows the rare and

odd ptrace interfaces, having him jump through hoops just to go through

"proper channels" is in my opinion just anti-productive (especially since

I also think the "political" aspect of the problem causes the actual

technical side of the patches to suffer - because they are more about

the politics than about the technology).
So at some point, subsystem mainteinance should also be about picking up

and handling the changes that come the other way. The kernel development

isn't a strict hierarchy, and shouldn't be - it's more of a network of

trust.
In other words, there are people I think are generally trusted across most

maintenance borders. Al, as far as I'm concerned, is one of them.

Especially sicne he is also one of the few people who clearly not only

does run sparse but also looks at the code and actually fixes real bugs

with byte order etc - regardless of where it is (ie he works across

drivers, filesystems, an arch-specific code)
In other words, I don't think the borders are so tightly drawn, and the

same way I trust the individual developers who send me patches (and git

trees) rather than whatever _companies_ they happen to work, I also tend

to trust individual developers rather than the _subsystem_ that they

happen to maintain.
Of course, there's often a rather direct mapping between the two, where

people naturally have the area they work in. But some people cross across

any particular area, and while that tends to be unusual, that very much

includes people like Andre...
[ message continues ]

What should I sent directly to you and for what should I pray that

someone picks it up?
E.g. I have a some patches that add missing MODULE_LICENSE's to modules

and some build fixes (some of the patches already sent to linux-kenrel,

some are still in my private testing) that IMHO belong into 2.6.25.
I also have sparse fixes and similar stuff pending.
And what about the removal of the broken v850 port I've already sent

five times to linux-kernel?
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

Btw - don't get me wrong - we clearly do try to (and should) make merges

easy, and it's why the kernel source code is generally pretty modular and

we try to keep things as independent as possible. I'm not at all arguing

against that.
I'm just trying to explain that at least personally, I just don't see that

"modularity" and maintainership as a _primary_ issue. The primary issue is

just the interpersonal trust people build up over time. The modularity and

trying to keep borders is about practical concerns, and it's important

too. But it is still secondary, I think. 
			Linus

--

We (the arch maintainers) could try to do the bulk of the defconfig

updates at about -rc2 or -rc3 time, if you'd prefer.
Paul.

--

Well, that part isn't the one that I think is bothersome - I just wonder

if the whole "defconfig" mess is worth keeping with the kernel at _all_.
It also causes tons of noise whenever I happen to do something like "git

grep CONFIG_XYZZY" to see where some config variable is used etc.
So I was more wondering whether maybe there could be better ways of doing

that whole thing. 
		Linus

--

Having the defconfigs seems to be useful for the embedded folks,

judging by the number of defconfigs they have.  They generally have a

defconfig for each reference board.
Those defconfigs would be much smaller and change much less often if

they could be expressed as a delta from some other defconfig.  So we'd

end up with a small number of base defconfigs plus a set of board

defconfigs that would say effectively "use the options from that other

defconfig, plus turn this on and that off".
On the whole, I think defconfigs are useful because we have so many

configuration options, and the defaults and help texts for many of the

options are not always helpful.
We could possibly do without defconfigs if we put effort into making

sure that all the "depends" and "default" values in all the Kconfig

files are sensible.  Ideally, a user could select something like

"32-bit powermac support" and take the defaults for everything else,

and get something sensible for a 32-bit powermac.  We're not at that

point, and I think it would take considerable effort to get there.
I would like to see something better than what we have at the moment

(whether one of the two ideas above, or something else) because I find

maintaining the defconfigs a bit of a pain myself.
Paul.

--

I'm thinking of getting rid of the board specific defconfigs for PowerPC

4xx actually.  We already have ppc44x_defconfig that builds most boards,

and ppc40x_defconfig will be coming soon.
IIRC, Fedora builds their kernels using such a mechanism, though it's

done in the RPM specfile with a perl script.  Maybe that's something to

look at to start with.
josh
--

kconfig allready allow you to override values simply by appending to

the end of the .config file.

So it is a matter of creating the proper stuff around to:

1) use it

2) make is simple to update defconfigs

   A simple extract delta between two config
I'm not up to do that at the moment - but it is doable.

And I would hate to see the defconfig disappear just because

they are so visible in Linus' dirstat.

	Sam

--

I have a trivial script that does "build all defconfigs", and it has

resulted in me reporting and fixing dozens of bugs in 2.6.25

(and some regressions in gcc 4.3).
And I use it for verifying that patches don't break the compilation.
Different to randconfig builds the defconfigs allow me to cover most 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--