Linux 2.6.25-rc8

Linux 2.6.25-rc8

[Linus Torvalds]

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 a suspend/resume regression) was some 
"struct device" lifetime changes that broke the input layer. Thanks to 
people who debugged that one.

So give it a test. And update your regression entries..

		Linus

---
Adrian Bunk (2):
      sound/oss/ac97_codec.c: restore MODULE_LICENSE
      remove include/asm-sh/floppy.h

Al Viro (33):
      wavelan_cs arm fix
      igb: endianness fix
      igb trivial annotations
      e100: endianness annotations
      reduce stack footprint in namespace.c
      count ghost references to vfsmounts
      sanitize locking in mark_mounts_for_expiry() and shrink_submounts()
      do shrink_submounts() for all fs types
      mnt_expire is protected by namespace_sem, no need for vfsmount_lock
      jbd/jbd2 NULL noise
      NULL noise: fs/*, mm/*, kernel/*
      futex_compat __user annotation
      NULL noise: drivers/media
      NULL noise: drivers/misc
      ioat_dca __iomem annotations
      misc __user misannotations (pointless casts to long)
      net/rxrpc trivial annotations
      NULL noise: frv cmpxchg()
      drivers/char/n_tty.c misannotated prototype
      vma_map: use proper pointer types
      fix iomem misannotations in nozomi
      compat_sys_wait4() prototype misannotation
      cifs: fix misannotations
      dma_page_list ->base_address is a userland pointer
      virtio_pci iomem annotations
      drivers/crypto/hifn_795x.c trivial endianness annotations
      8250_pci: duplicate initializer in array ([pbn_b0_8_115200])
      fix the broken annotations in fsldma
      trivial endianness annotations: infiniband core
      powerpc/pseries/xcis: ansify
      zr364xx __user annotations
      mfd/asic3: ioread/iowrite take pointer, not unsigned long
      dm9000 trivial annotation

Alasdair G Kergon (1):
      dm io: write error bits form long not int

Alessandro Zummo (1):
      ixp4xx-beeper: add MODULE_ALIAS

Alexandr Smirnov (1):
      Marvell PHY m88e1111 driver fix

Alexey Starikovskiy (1):
      ACPI: SBS: remove typo from sbchc.c

Ananth N Mavinakayanahalli (1):
      kprobes: another MAINTAINERS update

Andres Salomon (1):
      x86: GEODE: add missing module.h include

Andrew Morton (5):
      x86: ptrace.c: fix defined-but-unused warnings
      Avoid false positive warnings in kmap_atomic_prot() with DEBUG_HIGHMEM
      drivers/char/drm/ati_pcigart.c: fix printk warning
      net/9p/trans_fd.c:p9_trans_fd_init(): module_init functions should return 0 on success
      memstick: suppress uninitialized-var warning

Andy Whitcroft (1):
      update checkpatch.pl to version 0.16

Anthony Liguori (1):
      virtio_pci: unregister virtio device at device remove

Anton Vorontsov (1):
      mtd: maps/physmap: fix oops in suspend/resume/shutdown ops

Bartlomiej Zolnierkiewicz (2):
      Revert "ide: change master/slave IDENTIFY order"
      ide: fix defining SUPPORT_VLB_SYNC

Benjamin Herrenschmidt (3):
      Give futex init a proper name
      pata_sil680: only enable MMIO on Cell blades
      drm: fix for non-coherent DMA PowerPC

Björn Steinbrink (1):
      evdev: Release eventual input device grabs when getting disconnected

Bryan Wu (2):
      smc91x: fix build breakage from the SMC_GET_MAC_ADDR API upgrade
      blackfin video driver: update the BF52x EZKIT video framebuffer driver according to LKML review

Christoph Hellwig (1):
      ext3: don't export ext3_fs.h and jbd.h

Christoph Lameter (3):
      count_partial() is not used if !SLUB_DEBUG and !CONFIG_SLABINFO
      x86: stricter check in follow_huge_addr()
      Fix undefined count_partial if !CONFIG_SLABINFO

Daniel Yeisley (1):
      slab: fix cache_cache bootstrap in kmem_cache_init()

Dave Airlie (2):
      drm/r300: fix bug in r300 userspace hardware wait emission
      drm/i915: fix oops on agp=off

Dave Jones (1):
      audit: silence two kerneldoc warnings in kernel/audit.c

David Brownell (1):
      leds: Remove incorrect use of preempt_count() from leds-gpio

David Howells (1):
      afs: add a MAINTAINERS record for AFS

David S. Miller (16):
      [SPARC64]: Make save_stack_trace() more efficient.
      [SPARC64]: Adjust {TLBTEMP,TSBMAP}_BASE.
      [SPARC64]: Fix sparse warnings in arch/sparc64/kernel/{cpu,setup}.c
      [SPARC64]: Fix sparse errors in arch/sparc64/kernel/traps.c
      [SPARC64]: Fix sparse warnings in arch/sparc64/kernel/iommu.c
      [SPARC64]: Fix sparse warnings in arch/sparc64/kernel/irq.c
      [SPARC64]: Fix sparse warnings in arch/sparc64/kernel/ptrace.c
      [IRDA]: Store irnet_socket termios properly.
      [SPARC64]: Fix sparse warnings in arch/sparc64/kernel/time.c
      [SPARC64]: Fix most sparse warnings in arch/sparc64/kernel/sys_sparc.c
      [SPARC64]: Fix sparse warnings in arch/sparc64/kernel/signal.c
      [SPARC64]: Fix __get_cpu_var in preemption-enabled area.
      [SPARC64]: Fix allnoconfig build, ptrace.c missing CONFIG_COMPAT checks.
      [SPARC64]: Update defconfig.
      [SPARC64]: flush_ptrace_access() needs preemption disable.
      [SPARC64]: Define TASK_SIZE_OF()

Dhananjay Phadke (4):
      netxen: improve msi support
      netxen: napi and irq cleanup
      netxen: remove low level tx lock
      netxen: fix rx dropped stats

Dmitri Monakhov (1):
      vfs: fix data leak in nobh_write_end()

Dmitry Torokhov (1):
      Input: make sure input interfaces pin parent input devices

Florian Fainelli (2):
      rdc321x: GPIO routines bugfixes
      [MIPS] XSS1500: Fix compilation

Gordon Farquharson (1):
      [ARM] 4875/1: Add MODULE_ALIAS to ixp4xx-beeper module

Haavard Skinnemoen (3):
      avr32: Work around byteswap bug in gcc < 4.2
      avr32: Build fix for CONFIG_BUG=n
      avr32: Fix bug in early resource allocation code

Harvey Harrison (2):
      kernel: add bit rotation helpers for 16 and 8 bit
      drm: radeon: fix sparse integer as NULL pointer warnings in radeon_mem.c

Helge Deller (1):
      Input: apm-power - fix crash when unloading modules

Herbert Xu (1):
      [IPSEC]: Fix BEET output

Ingo Molnar (4):
      x86: add dmi quirk for io_delay
      x86: fix prefetch workaround
      x86: prefetch fix #2
      revert "ACPI: drivers/acpi: elide a non-zero test on a result that is never 0"

Jarod Wilson (1):
      firewire: fw-ohci: plug dma memory leak in AR handler

Jay Schulist (1):
      smctr.c: fix logical-bitwise-or confusion

Jay Vosburgh (3):
      bonding: Fix locking in 802.3ad mode
      bonding: fix two compiler warnings
      bonding: update version

Jean Delvare (2):
      hwmon: (w83781d) Fix I/O resource conflict with PNP
      pci: revert SMBus unhide on HP Compaq nx6110

Jeff Garzik (1):
      netxen, phy/marvell, skge: minor checkpatch fixes

Jens Axboe (1):
      relay: set an spd_release() hook for splice

Jeremy Fitzhardinge (2):
      xen: fix RMW when unmasking events
      xen: fix UP setup of shared_info

Jesper Juhl (1):
      driver core: fix small mem leak in driver_add_kobj()

John W. Linville (1):
      arlan: fix warning when PROC_FS=n

Jonathan Corbet (1):
      in_atomic(): document why it is unsuitable for general use

Julia Lawall (2):
      ixgb: remove unused variable
      ACPI: drivers/acpi: elide a non-zero test on a result that is never 0

Jussi Kivilinna (1):
      rndis_host: fix oops when query for OID_GEN_PHYSICAL_MEDIUM fails

Kazunori MIYAZAWA (1):
      [IPSEC]: Fix inter address family IPsec tunnel handling.

Lai Jiangshan (1):
      set relay file can not be read by pread(2)

Len Brown (1):
      pnpacpi: reduce printk severity for "pnpacpi: exceeded the max number of ..."

Libor Pechacek (1):
      bonding: Fix sysfs attribute handling

Linus Torvalds (3):
      Revert "PCI: remove transparent bridge sizing"
      Revert "SLUB: remove useless masking of GFP_ZERO"
      Linux 2.6.25-rc8

Marcin Slusarz (1):
      x86, documentation: nmi_watchdog=2 works on x86_64

Marin Mitov (1):
      skge napi->poll() locking bug

Mark Lord (1):
      fix uevent action-string regression

Masakazu Mokuno (1):
      rt2x00: Add id for Corega CG-WLUSB2GPX

Masami Hiramatsu (1):
      kprobes: MAINTAINERS update

Michael Buesch (3):
      b43: Fix DMA mapping leakage
      b43: Remove irqs_disabled() sanity checks
      b44: Truncate PHY address

Michael Ellerman (1):
      [POWERPC] Fix missed hardware breakpoints across multiple threads

Michael Hennerich (1):
      blackfin video driver: fix bug when opening/reading/mmaping BF54x and BF52x framebuffer simultaneously

Mike Rapoport (1):
      [ARM] 4873/1: Fix ITE 8152 interrupt demux

Mikulas Patocka (1):
      plip: replace spin_lock_irq with spin_lock_irqsave in irq context

Milan Broz (1):
      dm crypt: fix ctx pending

Nick Andrew (1):
      x86: Documentation/i386/IO-APIC.txt: fix description

Nishanth Aravamudan (2):
      hugetlb: indicate surplus huge page counts in per-node meminfo
      hugetlb: fix potential livelock in return_unused_surplus_hugepages()

Oliver Schuster (1):
      [WATCHDOG] Fix it8712f_wdt.c wrong byte order accessing WDT_TIMEOUT

Olof Johansson (1):
      [POWERPC] update pasemi_defconfig

Pascal Terjan (1):
      iwlwifi: fix a typo in Kconfig message

Patrick McHardy (3):
      [VLAN]: Don't copy ALLMULTI/PROMISC flags from underlying device
      [UML]: uml-net: don't set IFF_ALLMULTI in set_multicast_list
      [NET]: Fix multicast device ioctl checks

Paul Bolle (1):
      lguest: lguest.txt documentation fix

Paul Mundt (2):
      sh: Fix occasional FPU register corruption under preempt.
      sh: Fix TIF_USEDFPU clearing under FPU emulation.

Pavel Emelyanov (2):
      [NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns (v3).
      [ICMP]: Dst entry leak in icmp_send host re-lookup code (v2).

Peter Korsgaard (3):
      dm9601: add Hirose USB-100 device ID
      dm9601: configure MAC to drop invalid (crc/length) packets
      dm9000: Support promisc and all-multi modes

Rafael J. Wysocki (1):
      ACPI PM: Restore the 2.6.24 suspend ordering

Ralf Baechle (3):
      [MIPS] VPE loader: Check result of memory allocation.
      [MIPS] I8253: Export i2853_lock to modules.
      [MIPS] Bigsur: make defconfig more useful.

Randy Dunlap (1):
      x86: convert mtrr/generic.c to kernel-doc

Reinette Chatre (2):
      MAINTAINERS: update iwlwifi git url
      iwlwifi: fix __devexit_p points to __devexit functions

Rick Farrington (1):
      iwlwifi: mac start synchronization issue

Riku Voipio (1):
      [ARM] 4878/1: Add oabi shim for fstatat64

Robert P. J. Day (1):
      [AX25]: Remove obsolete references to BKL from TODO file.

Roland Dreier (2):
      cxgb3: Fix lockdep problems with sge.reg_lock
      RDMA/cxgb3: Program hardware IRD with correct value

Rusty Russell (2):
      lguest: Don't need comment terminator before disk section.
      lguest: comment documentation update.

Samuel Ortiz (1):
      Input: pxa27x - fix keypad KPC macros

Sebastian Siewior (1):
      mtd: nand: add out label in rfc_from4

Sergei Shtylyov (1):
      [MIPS] Alchemy: work around clock misdetection on early Au1000

Sreenivasa Honnur (1):
      S2io: Handle TX completions on the same CPU as the sender for MIS-X interrupts

Stephan Diestelhorst (1):
      x86, cpufreq: fix Speedfreq-SMI call that clobbers ECX

Suresh Siddha (1):
      x86: fix performance drop for glx

Sven Schnelle (1):
      afs: prevent double cell registration

Tejun Heo (1):
      libata: ATA_EHI_LPM should be ATA_EH_LPM

Thomas Bogendoerfer (3):
      [MIPS] Check for GCC r10k-cache-barrier support
      [MIPS] BCM1480: Fix PCI/HT IO access
      [MIPS] Add missing 4KEC TLB refill handler

Thomas Gleixner (2):
      clocksource: revert: use init_timer_deferrable for clocksource_watchdog
      NOHZ: reevaluate idle sleep length after add_timer_on()

Thomas Klein (1):
      ehea: Fix IPv6 support

Tim Ansell (1):
      lguest: Add puppies which where previously missing.

Tom Tucker (1):
      SVCRDMA: Check num_sge when setting LAST_CTXT bit

Uwe Kleine-König (1):
      leds: Fix potential leds-gpio oops

Venki Pallipadi (2):
      ACPI: fix mis-merge -- invoke acpi_unlazy_tlb() only on C3 entry
      cpuidle: fix 100% C0 statistics regression

YAMAMOTO Takashi (1):
      memcgroup: fix spurious EBUSY on memory cgroup removal

Yi Yang (1):
      cpuidle: fix cpuidle time and usage overflow

Yinghai Lu (2):
      x86: fix memoryless node oops during boot
      x86: fix trim mtrr not to setup_memory two times

Yoichi Yuasa (1):
      [MIPS] Fix the installation condition of MIPS clocksource

Yoshihiro Shimoda (1):
      sh: Fix up uImage compression type

Zhang Rui (1):
      ACPI: fix a regression of ACPI device driver autoloading

Re: Linux 2.6.25-rc8

[Paul Mackerras]

Linus Torvalds writes:

> 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

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.

Re: Linux 2.6.25-rc8

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

On Tue, 1 Apr 2008 13:08:57 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> 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 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)?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux 2.6.25-rc8

[Linus Torvalds]

On Wed, 2 Apr 2008, Stephen Rothwell wrote:
> 
> 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)?

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 Andrew and Al.

In other words, at least to me it's not about "person X maintains file Y". 
It's much more about "I trust person X (perhaps within parameters Z)". And 
I don't think that's even unusual or even really unexpected.

And I think that's how we all work (and how we _should_ work), but 
sometimes people get so used to the fact that some people are fairly 
tightly associated with certain code that they think it's about the 
subsystem, not about the person.

			Linus

Re: Linux 2.6.25-rc8

[Linus Torvalds]

On Tue, 1 Apr 2008, Linus Torvalds wrote:
> 
> And I think that's how we all work (and how we _should_ work), but 
> sometimes people get so used to the fact that some people are fairly 
> tightly associated with certain code that they think it's about the 
> subsystem, not about the person.

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

Re: Linux 2.6.25-rc8

[Linus Torvalds]

On Wed, 2 Apr 2008, Paul Mackerras wrote:
> Linus Torvalds writes:
> 
> > 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
> 
> We (the arch maintainers) could try to do the bulk of the defconfig
> updates at about -rc2 or -rc3 time, if you'd prefer.

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

Re: Linux 2.6.25-rc8

[Adrian Bunk]

On Wed, Apr 02, 2008 at 07:50:28AM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 2 Apr 2008, Paul Mackerras wrote:
> > Linus Torvalds writes:
> > 
> > > 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
> > 
> > We (the arch maintainers) could try to do the bulk of the defconfig
> > updates at about -rc2 or -rc3 time, if you'd prefer.
> 
> 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_.
>...

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 
reasonable configurations with a script that takes only one day to run.

> 		Linus

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

Re: Linux 2.6.25-rc8

[Adrian Bunk]

On Tue, Apr 01, 2008 at 08:03:45PM -0700, Linus Torvalds wrote:
>...
> 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 Andrew and Al.
>...

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?

Etc.

> 			Linus

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

Re: Linux 2.6.25-rc8

[Paul Mackerras]

Linus Torvalds writes:

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

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.

Re: Linux 2.6.25-rc8

[Josh Boyer]

On Thu, 2008-04-03 at 15:08 +1100, Paul Mackerras wrote:
> Linus Torvalds writes:
> 
> > 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. 
> 
> 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.

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.

Of course, that might not be possible for other architectures to do.

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

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

Re: Linux 2.6.25-rc8

[Sam Ravnborg]

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