Linux 2.6.9-rc1

Linux 2.6.9-rc1

[Linus Torvalds]

Ok,
 tons of patches merged, with me being away for a week, and also the
normal pent-up patch demand after any stable kernel. Special thanks as
always to Andrew, who synced up 200+ patches (he's attributed in the
sign-off lines, but not in the appended shortlog, so I just wanted to
point that out).

Changes all over: arm, ppc, sparc, acpi, i2c, usb, fbcon, ntfs, xfs, nfs,
cpufreq, agp, sata, network drivers - you name it. Most of the changes are
fairly small, but there's a lot of them.

Administrative trivia, and one thing I agonized over: should I make the
patches relative to 2.6.8 or 2.6.8.1? I decided that since there is
nothing that says that a "basic bug-fix" releases for a previous release
might not happen _after_ we've done a -rc release for the next version, I
can't sanely do patches against a bugfix release.

Thus the 2.6.9-rc1 patch is against plain 2.6.8. If you have 2.6.8.1, you
need to undo the .1 patch, and apply the big one. BK users and tar-balls 
don't see that particular confusion, of course ;)

		Linus

-----

Summary of changes from v2.6.8 to v2.6.9-rc1
============================================

<felixb:sgi.com>:
  o [XFS] Removed xfs_iflush_all and all usages of vn_purge, except one
    in clear_inode path.
  o [XFS] Restored xfs_iflush_all, which is still used to finish
    reclaims

<herry:sgi.com>:
  o [XFS] Add support for unsetting realtime flag on realtime file
    which has no extents allocated.

Adrian Bunk:
  o 2.6.8-rc1-mm1: 8139too: uninline rtl8139_start_thread
  o #define inline as __attribute__((always_inline)) also for gcc >=
    3.4
  o istallion: gcc-3.5 fixes
  o mxser.c: gcc-3.5 fixes
  o radio-maestro.c: gcc-3.5 fixes
  o cciss /proc dependency fix

Adrian Cox:
  o I2C: bus driver for multiple PowerPCs

Alan Cox:
  o [libata] improve translation of ATA errors to SCSI sense codes
  o Fix HPT374 merge problem
  o missing CPU descriptors

Alan Stern:
  o USB: Fix NULL-pointer bug in dummy_hcd
  o USB: Make removable-LUN support a non-test option in the
    g_file_storage driver
  o USB: Remove unneeded unusual_devs.h entry
  o USB: unusual_devs.h update
  o USB: unusual_devs.h update
  o USB: Don't track endpoint halts in usbcore
  o USB: Disallow probing etc. for suspended devices

Alexander Malysh:
  o I2C: new device for sis630

Andi Kleen:
  o gcc-3.5 fixes

Andrea Arcangeli:
  o do_general_protection doesn't disable irq

Andrew Chew:
  o [libata sata_nv] fix leak on error

Andrew Morton:
  o fix via-velocity oopses
  o via-velocity warning fixes
  o I2C: scx200_i2c build fix
  o libata build fix
  o make sync_dirty_buffer() return something useful
  o memory-backed inodes fix
  o err2-6: hashbin_remove_this() locking fix
  o send_IPI_mask_bitmask() build fix
  o Writeback page range hint
  o Concurrent O_SYNC write support
  o mark IS_ERR as unlikely()
  o IS_ERR() unlikeliness cleanup
  o net/Kconfig crc16 warning fix

Andrey Panin:
  o fix visws kernel build
  o CRC16 renaming in VIA Velocity ethernet driver

Andries E. Brouwer:
  o minix block usage counting fix

Andy Fleming:
  o update gianfar ethernet driver

Aneesh Kumar:
  o alpha: print the symbol of pc and ra during Oops

Anton Altaparmakov:
  o NTFS: Add support for readv/writev and aio_read/aio_write
  o NTFS: Change ntfs_write_inode to return 0 on success and -errno on
    error and create a wrapper ntfs_write_inode_vfs that does not have
    a return value and use the wrapper for the VFS super_operations
    write_inode function.
  o NTFS: Implement fsync, fdatasync, and msync both for files
    (fs/ntfs/file.c) and directories (fs/ntfs/dir.c).
  o NTFS: 2.1.16 - Implement access time updates in
    fs/ntfs/inode.c::ntfs_write_inode
  o NTFS: Implement bitmap modification code (fs/ntfs/bitmap.[hc]). 
    This includes functions to set/clear a single bit or a run of bits.
  o NTFS: Wrap the new bitmap.[hc] code in #ifdef NTFS_RW / #endif
  o NTFS: Rename run_list to runlist everywhere to bring in line with
    libntfs
  o NTFS: Rename map_runlist() to ntfs_map_runlist()
  o NTFS: Rename vcn_to_lcn() to ntfs_vcn_to_lcn()
  o NTFS: Complete "run list" to "runlist" renaming
  o NTFS: Move a NULL check to before the first use of the pointer
  o NTFS: Add fs/ntfs/attrib.[hc]::ntfs_find_vcn()
  o NTFS: Fix compilation with gcc-2.95 in attrib.c::ntfs_find_vcn(). 
    (Adrian Bunk)
  o NTFS: Implement cluster (de-)allocation code
    (fs/ntfs/lcnalloc.[hc])
  o NTFS: Minor update to fs/ntfs/bitmap.c to only perform rollback if
    at least one bit has actually been changed.
  o NTFS: Fix fs/ntfs/lcnalloc.c::ntfs_cluster_alloc() to use
    LCN_RL_NOT_MAPPED rather than LCN_ENOENT as runlist terminator. 
    Also, make it not create a LCN_RL_NOT_MAPPED element at the
    beginning.
  o NTFS: Fix fs/ntfs/debug.c::ntfs_debug_dump_runlist() for the
    previous removal of LCN_EINVAL which was not used in the kernel
    NTFS driver.
  o NTFS: Only need two spare runlist elements when reallocating memory
    in fs/ntfs/lcnalloc.c::ntfs_cluster_alloc(), not three since we no
    longer add a starting element.
  o NTFS: - Load attribute definition table from $AttrDef at mount time
  o NTFS: 2.1.17 - Fix bugs in mount time error code paths

Anton Blanchard:
  o ppc64: reduce stack overflow warning threshold
  o ppc64: remove old asm offsets
  o ppc64: POWER4 oprofile update
  o ppc64: disable oprofile debug messages
  o ppc64: allow oprofile module to be safely unloaded
  o ppc64: add missing EXPORT_SYMBOLS for oprofile
  o ppc64: Fix oprofile error messages
  o Fix gcc 3.5 compile issue in mm/mempolicy.c

Antonino Daplas:
  o fbcon: EDD-based blacklisting
  o fbcon: ifferentiate bits_per_pixel from color depth
  o fbdev: set color fields correctly
  o fbdev: ATTN: Maintainers - Set correct hardware capabilities
  o rivafb: Do not tap VGA ports if not X86
  o i810fb fixes
  o fbdev: find correct logo for directcolor < 24bpp
  o rivafb: kill riva_chip_info and riva_chips
  o Video Mode Handling - Linked list of video modes
  o Video Mode Handling - Save per-display graphics/display settings
  o Video Mode Handling - Delete entries from mode list
  o Video Mode Handling - Reduce memory footprint of fbdev
  o fbdev: do the deletion of mode entries at fbdev level
  o fbdev: support for bold attribute for monochrome framebuffers
  o fbdev: use 8-bit DAC for capable hardware
  o rivafb: directcolor mode and miscellaneous fixes
  o epson1355fb: salvage epson1355 code from James' tree
  o neofb: salvage neofb from James' tree
  o sgivwfb: salvage sgivwfb from James' tree
  o tdfxfb: salvage tdfxfb from James' tree

Arjan van de Ven:
  o mark LOOP_CHANGE_FD as an ULONG compat ioctl

Arnd Bergmann:
  o [WATCHDOG] v2.6.8.1 compat_ioctl-patch
  o fix reading string module parameters in sysfs
  o clean up __always_inline__ usage

Arthur Othieno:
  o s390: Use include/asm-generic/dma-mapping-broken.h

Badari Pulavarty:
  o direct-io: size the BIOs more accurately
  o DIO pages-in-io accounting fix

Ben Dooks:
  o [ARM PATCH] 1995/1: S3C2410 - Clock controls
  o [ARM PATCH] 1991/1: S3C2410 - irq updates
  o [ARM PATCH] 1993/3:  S3C2410 DMA Support
  o [ARM PATCH] 2025/1: S3C2410 - default platform devices
  o [ARM PATCH] 2026/1: S3C2410 - header text for
    arch/arm/mach-s3c2410/s3c2410.h
  o [ARM PATCH] 2027/1: S3C2410 - initial documentation

Benjamin Herrenschmidt:
  o ppc32: Fix booting on some OldWolrd Macs
  o ppc32: remove hardcoded offsets from ppc asm

Benno:
  o kbuild: Use POSIX headers for ntoh functions

Bjorn Helgaas:
  o PCI: Document pci_disable_device()

Brian King:
  o blk_queue_free_tags() fix
  o blk_resize_tags() fix
  o handle blk_queue_tags_resize() allocation failures

Bruce Allan:
  o kNFSd: fix brokenness with fsid= export option

Bálint Márton:
  o get_random_bytes() returns the same on every boot

Cal Peake:
  o [IPV4]: Delete bogus newline in first TcpExt procsfs line
  o fix /proc/net/netstat output

Carl Spalletta:
  o remove dead prototypes

Chris Mason:
  o add BH_Eopnotsupp for testing async barrier failures
  o reiserfs v3 barrier support

Chris Wright:
  o rlimit-based mlocks for unprivileged users

Christian Borntraeger:
  o remove sync() from panic

Christoph Hellwig:
  o convert skge to pci_driver API (2nd try)
  o allow modular mv64340_eth
  o fix compiler warnings in mv64340_eth
  o remove dead code from mv64340_eth
  o [ATM]: Missing static in atm
  o [NET]: Add missing struct net_device forward decl to skbuff.h
  o [NET]: Missing header includes and forward declarations
  o [XFS] avoid using pid_t in ioctl ABI
  o idr.c: remove stale comment
  o split generic_file_aio_write into buffered and direct I/O parts

Christoph Lameter:
  o gettimeofday nanoseconds patch

Corey Minyard:
  o IPMI Watchdog handling updates
  o IPMI driver updates

Coywolf Qi Hunt:
  o kbuild: Remove wildcard on KBUILD_OUTPUT
  o kbuild: remove obsolete HEAD in kbuild

Dan Aloni:
  o d_unhash consolidation

Dave Boutcher:
  o ppc64: mf_proc file position fix

Dave Hansen:
  o ppc64: include profile.c in kernel/irq.c
  o ibmveth: race fixes
  o break out zone free list initialization

Dave Jiang:
  o [ARM PATCH] 1963/1: Intel XScale IOP310 removal
  o [ARM PATCH] 2018/1: Fixed Patch 2017

Dave Jones:
  o [CPUFREQ] new Dothan variant for speedstep-centrino
  o [CPUFREQ] Stop powernow-k7 printk'ing tab characters
  o [CPUFREQ] Fix sparse NULL ptr warning
  o [CPUFREQ] Trailing whitespace removal in longrun driver
  o [CPUFREQ] Fix FSB calculation in powernow-k7
  o [CPUFREQ] fix double "out-of-sync" warning on resume
  o [CPUFREQ] fix userspace resume support
  o [CPUFREQ] Make powernow-k7 debug printk a runtime option
  o [CPUFREQ] REmove more trailing whitespace
  o [CPUFREQ] Remove out of date comment from powernow-k7 This has had
    significant amount of testing since it got merged, and nothing
    nasty has actually ever happened.
  o [CPUFREQ] fix whitespace after merge
  o [CPUFREQ] reorder cpufreq.c for inlining
  o [CPUFREQ] fix CONFIG_ACPI_PROCESSOR="m",
    CONFIG_X86_POWERNOW_K{7,8}="y" build issue Fix the build dependency
    between powernow-k{7,8} and acpi/processor.o by adding a
    CONFIG_X86_POWERNOW_K{7,8}_ACPI bool, just like SPEEDSTEP_CENTRINO
    does it. See http://forums.gentoo.org/viewtopic.php?t=186887 for a
    bugreport.
  o [CPUFREQ] powernowk8_cpu_exit may not be __exit but can be
    __devexit
  o [CPUFREQ] Fix up some comments in longhaul
  o [CPUFREQ] abstract out powersaver code in longhaul driver
  o [CPUFREQ] disable interrupts around transitions in longhaul
  o [CPUFREQ] Longhaul compile fixes
  o [CPUFREQ] speedstep-smi: GET_SPEEDSTEP_FREQS may return bogus
    values
  o [CPUFREQ] speedstep-centrino: ignore 0xffff'ed P-States
  o [CPUFREQ] speedstep-ich SMT support
  o [CPUFREQ] A reduce-Jeremy's-mail patch
  o [CPUFREQ] speedstep-centrino: Remove unnecessary vendor checks
  o [CPUFREQ] fix HT oops on speedstep-ich system
  o [AGPGART] License updates
  o [CPUFREQ] compile fix
  o [CPUFREQ] Whitespace cleanup for centrino speedstep
  o [CPUFREQ] Better fix for previous speedstep-ich breakage
  o [CPUFREQ] Whitespace/CodingStyle fixes for speedstep-ich
  o [AGPGART] Delete confusing message when not using onboard i815 gfx
  o [AGPGART] Trailing whitespace cleanup
  o [AGPGART] Sparse trivial warning fixes
  o [AGPGART] SiS 635 support
  o [AGPGART] Fix MVP3 typo
  o Cset exclude: davej@redhat.com|ChangeSet|20040809142517|56351
  o [CPUFREQ] fix powernow-k8 compilation [bug 3180]
  o [CPUFREQ] avoid re-enabling of interrupts too early during resume
  o [CPUFREQ] deprecate proc_intf, and inform of removal ~2005-01-01
  o [CPUFREQ] deprecate proc_sys_intf, and inform users of removal
    ~2005-01-01
  o [CPUFREQ] Support VIA C3 Nehemiah's with 200MHz FSB
  o [CPUFREQ] fix typo on gx-suspmod.c

David Brownell:
  o USB: add CONFIG_USB_SUSPEND
  o USB: usb hub docs and locktree()
  o USB: usb_get_descriptor, more error checks
  o USB: hid intervals
  o USB: ehci and buggy BIOS handoff
  o USB: autoconf for gadget serial
  o USB: add <linux/usb_otg.h>

David Eger:
  o radeonfb: cleanup and little fixes

David Gibson:
  o orinoco merge preliminaries - squash backwards compatibility
  o orinoco merge preliminaries - rearrange code
  o orinoco merge preliminaries - use netdev_priv()
  o orinoco merge preliminaries - use ALIGN()
  o orinoco merge preliminaries - use ARRAY_SIZE()
  o orinoco merge preliminaries - spam stoppers
  o orinoco merge preliminaries - comment/whitespace/spelling updates
  o orinoco merge preliminaries - use BUG_ON()
  o orinoco merge preliminaries - make things static
  o orinoco merge preliminaries - miscelaneous
  o orinoco merge preliminaries - use name/version macros
  o orinoco merge preliminaries - remove unneeded #includes
  o orinoco merge preliminaries - don't typedef structs
  o orinoco merge preliminaries - more HW data
  o orinoco merge preliminaries - update authorship information
  o ppc64: C99 initializers in INIT_THREAD
  o ppc64: bolted SLB entry for iSeries

David S. Miller:
  o [IPV4]: Remove all references to IP_ROUTE_NAT support
  o [IPV4]: Move inetdev/ifa locking over to RCU
  o [IPV4]: Kill inetdev_lock, no longer needed
  o [IPV4]: Fix theoretical loop on SMP in ip_evictor()
  o [IPV6]: ip6_evictor() has same problem as ip_evictor()
  o [NETFILTER]: Convert SCTP conntrack over to ip_ct_refresh_acct()
  o [NETFILTER]: Export ip_conntrack_count for ip_conntrack_standalone
  o [NETFILTER]: Need to export ip_ct_log_invalid to modules
  o [NET]: Add skb_header_pointer, and use it where possible
  o [TCP]: When fetching srtt from metrics, do not forget to set
    rtt_seq
  o [IPV4/IPV6]: Fix direct user pointer deref in xfrm icmp changes
  o [NETFILTER]: Mark tcp_options skb arg as const
  o [VLAN]: __vlan_hwaccel_rx() needs to use dev_kfree_skb_any
  o [SUNGEM]: Fix locking in gem_interrupt()
  o [PKT_SCHED]: Fix unused label warning in ingress_init()
  o [SPARC64]: Fix PCI IOMMU invalid iopte handling
  o [SPARC64]: Revamped memcpy infrastructure
  o [SPARC64]: Fix bugs in new U1memcpy code
  o [SPARC64]: Kill bogus __strlen symbol and strncmp inline cruft
  o [SPARC64]: Implement little-endian bitops using normal ones
  o [SPARC64]: Durrrr, missed signal handling fix from 2.4.x
  o [SPARC64]: Update defconfig

David Vrabel:
  o [ARM PATCH] 2013/1: IXP4xx: Make clock monotonic

David Woodhouse:
  o [1/3] Split pci quirks array to allow separate declarations
  o [2/3] PCI quirks -- PPC
  o [3/3] PCI quirks -- i386
  o PCI quirks -- parisc
  o PCI quirks -- ppc64
  o PCI quirks -- other architectures

Davide Libenzi:
  o ptrace single-stepping fix
  o Don't use SYSGOOD for ptrace singlestep

Dean Roehrich:
  o [XFS] Fix lock leak in xfs_free_file_space

Deepak Saxena:
  o I2C: Add Intel IXP2000 GPIO-based I2C adapter
  o [5/3][ARM] PCI quirks update for ARM
  o Remove spaces from PCI IDE pci_driver.name field
  o Remove spaces from PCI I2C pci_driver.name fields
  o Remove spaces from PCI gameport pci_driver.name fields
  o Remove spaces from Skystar2 pci_driver.name field

Dimitri Sivanich:
  o Move cache_reap out of timer context
  o slab: locking optimization for cache_reap

Dipankar Sarma:
  o RCU - cpu-offline-cleanup
  o RCU - cpu offline fix
  o RCU: low latency rcu
  o rcu: clean up code
  o rcu: fix spaces in rcupdate.h
  o rcu: introduce call_rcu_bh()
  o rcu: use call_rcu_bh() in route cache
  o rcu: document RCU api
  o rcu: abstracted RCU dereferencing

Domen Puncer:
  o remove old ifdefs net/eepro100.c
  o USB: use list_for_each() in class/audio.c
  o USB: use list_for_each() in class/usb-midi.c
  o USB: use list_for_each() in core/devices.c
  o PCI: use list_for_each() i386/pci/pcbios.c
  o PCI: use list_for_each() i386/pci/common.c
  o PCI: use list_for_each() drivers/pci/setup-bus.c

Dominik Brodowski:
  o I2C: activate SMBus device on hp d300l

Douglas Gilbert:
  o [libata] fix INQUIRY handling

Duncan Sands:
  o USB: fix deadlock in hub_reset
  o USB: usbfs: drop the device semaphore in proc_bulk and proc_control
  o USB: usbfs: check the buffer size in proc_bulk

Eric Sandeen:
  o [XFS] Add filesystem size limit even when XFS_BIG_BLKNOS is in
    effect; limited by page cache index size (16T on ia32)
  o [XFS] Code checks to trap access to fsb zero

Eugene Surovegin:
  o ppc32: export __dma_sync & __dma_sync_page

Evgeniy Polyakov:
  o w1: attributes split, timeout unit changed
  o w1: Added w1_read_block() and w1_write_block() callbacks
  o w1: Added w1_check_family()
  o w1: Changed printing format for slave names
  o w1: Changed define for W1_FAMILY_SMEM
  o w1: Netlink update - changed event generating/processing
  o w1: Debug output cleanup. memcpy instead of direct structure
    copying
  o w1: Spelling fix
  o w1: Added  w1_smem.c - driver for simple 64bit ROM devices
  o w1: Added driver for Dallas' DS9490* USB <-> W1 master
  o w1: Added dynamic slave removal mechanism. Fixed bug when we have
    multiple slave with different families

François Romieu:
  o [netdrvr epic100] minor cleanups
  o [netdrvr epic100] napi 1/3 - just shuffle some code around
  o [netdrvr epic100] napi 2/3 - receive path
  o [netdrvr epic100] napi 3/3 - transmit path
  o [netdrvr epic100] napi fixes
  o epic100: spin_unlock_irqrestore avoidance
  o epic100: code removal in irq handler
  o r8169: napi support
  o r8169: cosmetic renaming of a register
  o r8169: janitoring
  o r8169: ethtool .set_settings
  o r8169: ethtool .get_{settings/link}
  o r8169: link handling and phy reset rework
  o r8169: initial link setup rework
  o r8169: gcc bug workaround
  o r8169: tx lock removal
  o via-velocity: PCI ID move
  o via-velocity: uniformize use of OWNED_BY_NIC
  o via-velocity: velocity_receive_frame diets
  o via-velocity: Rx buffers allocation rework
  o via-velocity: Rx copybreak
  o via-velocity: ordering of Rx descriptors operations
  o via-velocity: unneeded forward declarations
  o via-velocity: use common crc16 code for WOL
  o [VLAN]: Missing Kconfig help

Friedrich Lobenstock:
  o [WATCHDOG] pcwd-watchdog.txt-patch

Ganesh Varadarajan:
  o USB: fix for ipaq.c

Ganesh Venkatesan:
  o e1000 - ethtool support (register dump, interrupt
  o e1000 - Enable TSO
  o e1000 - Use vmalloc for data structures not shared
  o e1000 - TSO fixes (in preparation for IPv6 TSO)
  o e1000 - Avoid infinite loop while trying to
  o e1000 - include work down in tx path to decide when
  o e1000 - Use pci_dma_sync_single_[for_device|for_cpu]
  o e1000 - Shutdown PHY while bringing the interface
  o e1000 - add compiler hints (likely/unlikely), check
  o e1000 - more DPRINTK messages to syslog
  o e1000 - suspend/resume fix from alex@zodiac.dasalias.org
  o e1000 - white space and related cleanup
  o e100 - restore speed/duplex/autoneg settings after the completion
    of the diagnostic tests
  o e100 - Support for Intel(R) PRO/100 VE Network Connection (82562)
    adapter
  o e100 - fix stat counters rx_length_error and rx_over_errors
  o e100 - Support to load device firmware
  o e100 - Auto MDI/MDI-X support
  o e100 - driver version update

Glen Overby:
  o [XFS] Permit buffered writes to the real-time subvolume

Greg Howard:
  o Altix system controller communication driver

Greg Kroah-Hartman:
  o USB: fix build error in the cyberjack driver
  o PCI: update pci.ids from sf.net site
  o PCI Hotplug: fix build warnings due to msleep() patches
  o USB: fix build error from previous patch
  o USB: replace old usb-skeleton driver with a rewritten and simpler
    version
  o USB: convert a lot of usb drivers from MODULE_PARM to module_param
  o PCI: fix compiler warning in quirks file, and other minor quirks
    cleanup
  o PCI: clean up code formatting of quirks.c
  o PCI: oops, forgot to check in the pci.h changes so that the quirk
    cleanups will work
  o USB: finish up the last of MODULE_PARM to module_param conversions
  o MODULE: add byte type of module paramater, like the comments say we
    support
  o I2C: convert all drivers from MODULE_PARM to module_param
  o I2C: fix up the order of bus drivers in the Kconfig and Makefile
  o I2C: rename i2c-sensor.c file to prepare for Rudolf's VRM patch
  o MODULE: delete local static copy of param_set_byte as we now have a
    real version of it
  o USB: fix up ub.c due to usb_endpoint_running() going away
  o USB: fix up gadget driver usage of MODULE_PARM
  o W1: fix some improper '{' style code
  o W1: removed some unneeded global symbols from the w1_smem module
  o PCI Hotplug: fix compiler warnings in pciehp driver
  o USB: hook the ub driver up to the sysfs tree so that tools like
    udev work better

Hannes Reinecke:
  o Enable all events for initramfs

Harald Welte:
  o [NETFILTER]: ip_nat_snmp call skb_make_writable()
  o [NETFILTER]: ipt_ULOG fix for last packet delay
  o [NETFILTER]: Use new module_param() api
  o [NETFILTER]: Fix mutex declaration
  o [NETFILTER]: Use slab cache for ip_conntrack_expect
  o [NETFILTER]: Connection based accounting
  o [NETFILTER]: Move /proc/net/ip_conntrack to seq_file
  o [NETFILTER]: New ip_sctp match
  o [NETFILTER]: Make 'helper' list of ip_nat_core static
  o [NETFILTER]: init_conntrack() optimization
  o [NETFILTER]: Move error tracking into conntrack protocol helper
  o [NETFILTER]: Add conntrack runtime statistics
  o [NETFILTER]: Add tcp window tracking
  o [NETFILTER]: Missing sysctl.h bits from tcp window tracking changes
  o USB: Hackish fix for cyberjack driver
  o [NETFILTER]: New ip_conntrack_sctp
  o [NETFILTER]: Fix broken debug assertion

Herbert Xu:
  o Fix successive calls to spin_lock_irqsave in sk98lin
  o [IPV4]: Fix race in inetdev RCU handling
  o [IPV6]: Add missing XFRM select in Kconfig
  o [XFRM_USER]: Fill in x->props algo fields
  o [IPV6]: Fix aalg check in esp
  o [IPSEC]: Move encap check back down to esp4.c
  o [IRDA]: Trivial optimization in inetdev handling
  o [IPV4]: inetdev ifa_list handling fixes outside of net/ipv4
  o [IPV4]: inetdev ifa_list handling fixes for s390 drivers
  o [IPV4]: Make inet_select_addr() logic clearer
  o [IPV4]: Simplify ifa free handling code
  o [XFRM]: Kill unused flow_hash
  o [IPSEC]: Call xfrm6_rcv in xfrm6_tunnel_rcv
  o [IPSEC]: Use xfrm4_rcv in xfrm4_tunnel
  o [IPSEC]: Modularise xfrm_tunnel
  o [IPSEC]: Revert pskb change for x->type->output

Hideaki Yoshifuji:
  o [IPV6] don't try to insert same local route multiple times
  o [IPV6] export rt6_ins() as ip6_ins_rt()
  o [IPV6] addrconf_dst_alloc() to allocate new route for local address
  o [IPV4,IPV6] set idev/rt6i_idev to loopback instead of NULL, to omit
    checking if it is non-NULL
  o [IPV6] ensure rt6i_idev is non-NULL when setting up new rt6_info{}
  o [IPV6] take rt6i_idev into account when looking up routes
  o [IPV6] refer inet6 device via corresponding local route from
    address structure
  o [XFRM] Fix selector comparison against icmp{,v6} flows
  o [IPV4] XFRM: don't probe icmp type/code for hdrincl sockets
  o [DECONET]: Fix build with SYSCTL=n
  o [IPV6]: Use offsetof()
  o [IPV6]: Improve readability in ip6_flowlabel.c

Hollis Blanchard:
  o ppc64: HVSI driver

Ian Abbott:
  o USB: ftdi_sio doesn't re-assert DTR modem control line
  o USB: Add support for FT2232C chip to ftdi_sio

Ian Campbell:
  o I2C: algorithm and bus driver for PCA9564

Ingo Molnar:
  o context-switching overhead in X, ioport()

Iñaky Pérez-González:
  o aio.c: rename 'struct timeout' to 'struct aio_timeout'

Jan Blunck:
  o ext2_readdir() filp->f_pos fix

Janice M. Girouard:
  o new device driver to enable the IBM Multiport Serial Adapter

Jean Delvare:
  o I2C: Fix debug in w83781d driver
  o I2C: update the lm83 driver
  o I2C: port smsc47m1 to 2.6
  o I2C: fix for previous lm83 driver update

Jeff Garzik:
  o [libata] transfer mode cleanup
  o [libata] fix completion bug, better debug output
  o [libata] convert set-xfer-mode operation to use ata_queued_cmd
  o [libata] transfer mode bug fixes and type cleanup
  o [libata sata_promise] convert to using packets for non-data
    taskfiles
  o [libata sata_sx4] deliver non-data taskfiles using Promise packet
    format
  o [libata] pio/dma flag bug fix, and cleanup
  o [libata] update IDENTIFY DEVICE path to use ata_queued_cmd
  o [libata] ATAPI work - PIO xfer, completion function
  o [PCI, libata] Fix "combined mode" PCI quirk for ICH6
  o [libata ata_piix] make sure AHCI is disabled, if h/w is used by
    this driver
  o [libata] flags cleanup
  o [libata] ATAPI work - cdb len, new taskfile protocol, cleanups
  o [libata] (cosmetic) minimize diff with 2.4.x libata
  o Fix NFS client screw-up in fcntl f_op removal
  o [libata] support commands SYNCHRONIZE CACHE, VERIFY, VERIFY(16)
  o [libata] fix PIO data xfer on big endian
  o [libata] ATAPI PIO data xfer
  o [libata] add ioctl infrastructure
  o [libata] fix error recovery reference count
  o [ata] remove 'packed' attributed from struct ata_prd

Jens Axboe:
  o disk barriers: core
  o disk barriers: IDE
  o disk barriers: scsi
  o disk barriers: devicemapper
  o disk barriers: MD
  o ext3 barrier support
  o cdrom event notification fixes
  o update SG_IO command table

Jeremy Fitzhardinge:
  o [CPUFREQ] Recognise another Dothan variant in speedstep driver

Jesper Juhl:
  o inlining errors in drivers/scsi/aic7xxx/aic79xx_osm.c
  o fix inline related gcc 3.4 build failures in
    drivers/net/wan/dscc4.c

Jesse Barnes:
  o ACPI for 2.6

Jindrich Makovicka:
  o More HPT374 driver merge woes

Johann Cardon:
  o USB: New unusual_devs.h entry

John Levon:
  o fix OProfile events with zero event values

John Rose:
  o PCI: rpaphp build break - remove eeh register

Jon Neal:
  o USB: net2280 minor fixes

Jon Oberheide:
  o [CRYPTO]: Email update in crypto/arc4.c

Jose R. Santos:
  o Make i/dhash_entries cmdline work as it use to

Juergen Stuber:
  o USB: LEGO USB Tower, move reset from probe to open

Kalev Lember:
  o natsemi netpoll support

Karol Kozimor:
  o PCI: ASUS L3C SMBus fixup

Keith Owens:
  o Make i386 die() more resilient against recursive errors
  o i386 oops output: dump preceding code

Kevin Corry:
  o devicemapper: use an IDR tree for tracking minors

Kronos:
  o fbdev Kconfig dependency fixes

Kumar Gala:
  o add new ethernet driver 'gianfar'

Len Brown:
  o Cset exclude: torvalds@evo.osdl.org|ChangeSet|20040401021818|60003
  o [ACPI] ACPICA 20040402 from Bob Moore
  o [ACPI] ACPICA 20040427 from Bob Moore
  o [ACPI] ACPICA 20040514 from Bob Moore
  o [ACPI] ACPICA 20040527 from Bob Moore
  o [ACPI] ACPICA 20040615 from Bob Moore
  o [ACPI] update EC GPE handler to new ACPICA handler type
  o [ACPI] fix return-from-sleep PM/ACPI state conversion bug (David
    Shaohua Li)
  o [ACPI] enable Embedded Controller (EC)'s General Purpose Event
    (GPE) from David Shaohua Li
  o [ACPI] enable GPE for ECDT (David Shaohua Li)
  o [ACPI] reserve IOPORTS for ACPI (David Shaohua Li)
    http://bugzilla.kernel.org/show_bug.cgi?id=2641
  o [ACPI] reserve EBDA for Dell BIOS that neglects to. (David Shaohua
    Li) http://bugme.osdl.org/show_bug.cgi?id=2990
  o [ACPI] fix ability to set thermal trip points (Hugo Haas, Stefan
    Seyfried) eg. # echo -n "100:90:80:70:60:50" >
    /proc/acpi/thermal_zone/THRM/trip_points
    http://bugzilla.kernel.org/show_bug.cgi?id=2588
  o [ACPI] /proc/acpi/thermal_zone/THRM/cooling_mode Add concept of
    (mandatory) "critical", when (optional) "passive" and "active" are
    not present.  (Zhenyu Z Wang)
    http://bugzilla.kernel.org/show_bug.cgi?id=1770
  o [ACPI] save/restore ELCR on suspend/resume (David Shaohua Li)
    http://bugzilla.kernel.org/show_bug.cgi?id=2643
  o [ACPI] add SMP suport to processor driver (Venkatesh Pallipadi)
    http://bugzilla.kernel.org/show_bug.cgi?id=2615
  o [ACPI] Tell the BIOS Linux can handle Enhanced Speed Step (EST).
    (Venkatesh Pallipadi)
    http://bugzilla.kernel.org/show_bug.cgi?id=2712
  o [ACPI] IOAPIC suspend/resume (David Shaohua Li)
    http://bugzilla.kernel.org/show_bug.cgi?id=3037
  o [ACPI] ACPI bus support for wakeup GPE (David Shaohua Li)
    http://bugzilla.kernel.org/show_bug.cgi?id=1415
  o [ACPI] Create /proc/acpi/wakeup to allow enabling the optional
    wakeup event sources. (David Shaohua Li)
    http://bugzilla.kernel.org/show_bug.cgi?id=1415
  o [ACPI] Enable run-time CM button/LID events (David Shaohua Li)
    http://bugzilla.kernel.org/show_bug.cgi?id=1415
  o [ACPI] ACPICA 20040715 from Bob Moore
  o [ACPI] S3 is independent of CONFIG_X86_PAE (David Shaohua Li)
  o [ACPI] synchronize_kernel for idle-loop unload (Zwane Mwaikambo)
    http://bugzilla.kernel.org/show_bug.cgi?id=1716
  o [ACPI] fix build warning (Andrew Morton)
  o [ACPI] BIOS workaround allowing devices to use reserved IO ports
    Author: David Shaohua Li
    http://bugzilla.kernel.org/show_bug.cgi?id=3049
  o [ACPI] acpi for asus update from Karol Kozimor
  o [ACPI] acpi_bus_register_driver() now return a count consistent
    with pnp_register_driver() and pci_register_driver()
  o [ACPI] init wakeup devcies only if ACPI enabled (David Shaohua Li)
  o [ACPI] clean out blacklist entries that do nothing
  o [ACPI] Enter ACPI mode earlier Fixes two common boot failures due
    to buggy SMM BIOS code
  o fix main.c build warning
  o [ACPI] ia64 build fix

Lennert Buytenhek:
  o PCI: more New PCI vendor/device ID for Radisys ENP-2611 board

Linas Vepstas:
  o ppc64: fix eeh_memcpy_toio() prototype

Linda Xie:
  o PCI Hotplug: rpaphp_add_slot.patch
  o PCI Hotplug: rpaphp_get_power_level bug fix

Linus Torvalds:
  o Make 'WRITE_BUFFER' require CAP_RAWIO capability
  o Fix stupid thinkos in the fcntl f_op removal code
  o Linux 2.6.8.1
  o Add another Intel cache descriptor entry
  o Make some single-bit bitfields unsigned
  o Run 'indent' on BusLogic driver to keep Alan sane
  o Fix i2c-keywest compile
  o Don't use signed one-bit bitfields
  o sparse: don't use signed single-bit bitfields
  o Fix up 0/NULL confusion
  o Remove pointless cast-as-lvalue usage from modedb.c
  o Use inline function instead of macro
  o Use F_SETLK instead of F_SETLK64 in nfs locking code
  o Linux 2.6.9-rc1

Luca Risolia:
  o USB: New entry in MAINTAINERS
  o USB: SN9C10[12] driver update
  o USB: SN9C10[12] driver minor update
  o USB: SN9C10[12] driver update
  o include "compiler.h" in videodev.h

Manfred Spraul:
  o ipc: Add refcount to ipc_rcu_alloc
  o ipc: remove sem_revalidate
  o ipc: enforce SEMVMX limit for undo
  o cleanup of ipc/msg.c

Marcel Holtmann:
  o USB: fix ub driver

Margit Schubert-While:
  o prism54 Clean up dev ids totally

Mark Broadbent:
  o IO-APIC debug message reduction

Martin J. Bligh:
  o warning on NUMA-Q

Masahide Nakamura:
  o [IPV6] XFRM: decode icmpv6 session
  o [IPV6] XFRM: probe icmpv6 type/code when sending packets via raw
    socket
  o [IPV4] XFRM: decode icmp session
  o [IPV4] XFRM: probe icmp type/code when sending packets via raw
    socket

Matt Mackall:
  o move duplicate BUG and WARN_ON bits to asm-generic
  o Fix CON_BUF_SIZE usage
  o vprintk support
  o vprintk for ext2 errors
  o vprintk for ext3 errors
  o Fix netpoll cleanup on abort without dev

Matt Porter:
  o ppc32: optimize/fix timer_interrupt loop
  o ppc32: make PPC40x large tlb mapping optional
  o ppc32: add docs for noltlbs and nobats parameters
  o ppc32: fix warnings on Ebony MTD build

Matthew Dharm:
  o USB Storage: fix Genesys Logic based on info from vendor
  o USB Storage: improve debugging output in usb-storage
  o USB Storage: cleanups, mostly

Matthew Wilcox:
  o PA-RISC sound updates
  o Kconfig updates for PA-RISC

Michael Opdenacker:
  o [ARM PATCH] 2023/1: platform_device definitions no longer needed in
    include/asm-arm/hardware.h

Mika Kukkonen:
  o Fix warnings drivers/net/sk98lin/skaddr.c

Mikael Pettersson:
  o arch/i386/kernel/smp.c gcc341 inlining fix

Mike Kravetz:
  o proc fs task name locking fix

Mike Miller:
  o cciss: fixes to 32/64-bit conversions
  o cciss: zero out buffer in passthru ioctls for HP utilities
  o cciss: /proc fixes
  o cciss: cylinder calculation fix
  o cciss: id change for V100 controller
  o cciss: V100 PCI ID fix again
  o cciss: pdev->intr fix
  o cciss: read_ahead bumped to 1024
  o cciss update 8 maintainers update for HP

Nabil Sayegh:
  o USB: ipaq module: product id for HTC Himalaya

Nathan Bryant:
  o [ACPI] restore PCI Interrupt Link Devices upon resume

Nathan Fontenot:
  o ppc64: fix enable_surveillance() for power5

Nathan Lynch:
  o ppc64: tweak schedule_timeout in __cpu_die

Nathan Scott:
  o [XFS] Sync up with the 2.4 fix for updating i_size under i_sem
  o [XFS] Update documentation
  o [XFS] Export blk_get_backing_dev_info for filesystems to use
  o [XFS] Revert to using a separate inode for metadata buffers once
    more
  o [XFS] Remove unneeded escape from printed string.  From Chris
    Wedgwood
  o [XFS] sparse: remove unneeded casts for user buffers.  From Chris
    Wedgwood
  o [XFS] sparse: annotate source for user pointers.  From Chris
    Wedgwood
  o [XFS] sparse: annotate quota source for user pointers.  From Chris
    Wedgwood
  o [XFS] sparse: annotate vfs interfaces for user pointers.  From
    Chris Wedgwood
  o [XFS] sparse: fix warnings in debug/tracing code.  From Chris
    Wedgwood
  o [XFS] Fix a possible data loss issue after an unaligned unwritten
    extent write.
  o [XFS] Fix xfs_off_t to be signed, not unsigned; valid warnings
    emitted after stricter compilation options used by some OSDL folks.
  o [XFS] xfs_Gqm_init cannot fail, dont check return value
  o [XFS] sparse: fix header include order to get cpp macros defined
    correctly.  From Chris Wedgwood.
  o [XFS] sparse: rework previous mods to fix warnings in DMAPI code
  o [XFS] sparse: fix warnings in IO path tracing code.  From Chris
    Wedgwood
  o [XFS] sparse: fix uses of NULL in place of zero and vice versa
  o [XFS] sparse: fix remaining NULL vs zero uses
  o [XFS] Fix signed/unsigned issues in xfs_reserve_blocks routine
  o [XFS] Fix accidental reverting of sync write preallocations
  o [XFS] Fix a blocksize-smaller-than-pagesize hang when writing
    buffers with a shared page.
  o [XFS] Remove several macros which are no longer used anywhere
  o [XFS] Use sparse whitespace approach that Al took to be more
    consistent.  Couple more sparse fixes
  o [XFS] Add a realtime inheritance bit for directory inodes so new
    files can be automatically created as realtime files.
  o [XFS] Add 32bit ioctl translation

Neil Brown:
  o multipath readahead fix fix
  o nfsd: force server-side TCP when NFSv4 enabled
  o nfsd: nfsd is missing a put_group_info in the auth_null
  o nfsd: make cache_init initialize reference count to 1
  o nfsd: simplify auth_domain_lookup
  o nfsd: fix ip_map cache reference count leak
  o nfsd: basic v4 ACL definitions
  o nfsd: POSIX<->NFSv4 acl translation for nfsd
  o nfsd: ACL support for the NFSv4 server
  o kNFSd: get rid of open_private_file
  o kNFSd: minor memory leak fix
  o kNFSd: fix two xdr-encode bugs for readdirplus reply
  o kNFSd: fix race with flushing nfsd cache
  o knfsd: fix server permission handling

Nick Piggin:
  o make shrinker_sem an rwsem

Nicolas Boichat:
  o Rivafb I2C fixes

Nicolas Kaiser:
  o [CRYPTO]: Typo in crypto/Kconfig
  o [CRYPTO]: Typo in crypto/twofish.c
  o [CRYPTO]: Typo in crypto/aes.c
  o [CRYPTO]: Typo in crypto/scatterwalk.c
  o [CRYPTO]: Typo in crypto/blowfish.c
  o [CRYPTO]: Typo in crypto/tcrypt.h

Nicolas Pitre:
  o [ARM PATCH] 1866/4: kernel support for iWMMXt present on some
    XScale cores
  o [ARM PATCH] 1909/1: add a cached definition of ioremap

Nishanth Aravamudan:
  o USB: pxa2xx_udc.c: replace schedule_timeout() with msleep()
  o USB: ov511: replace schedule_timeout() with msleep()
  o USB: auerswald: replace schedule_timeout() with msleep()
  o USB: usbnet: replace schedule_timeout() with msleep()
  o PCI Hotplug: cpci_hotplug_core: replace schedule_timeout() with
    msleep()
  o PCI Hotplug: ibmphp: remove long_delay
  o PCI Hotplug: ibmphp_core: replace long_delay() with msleep()
  o PCI Hotplug: ibmphp_hpc: replace long_delay() with msleep()
  o PCI Hotplug: shpchp_hpc: replace schedule_timeout() with msleep()
  o I2C: i2c-keywest: replace schedule_timeout() with msleep()
  o I2C: i2c-algo-pcf: replace schedule_timeout() with msleep()
  o I2C: i2c-ite: replace schedule_timeout() with msleep()
  o I2C: i2c-nforce2: replace schedule_timeout() with msleep()
  o I2C: scx200_acb: replace schedule_timeout() with msleep()
  o PCI: replace schedule_timeout() with msleep()

Nobuyuki AKIYAMA:
  o NMI trigger switch support for debugging(updated)

Oliver Neukum:
  o USB: ACM USB modem on Kernel 2.6.8-rc2

Olof Johansson:
  o ppc64: switch screen_info init to C99

Patrick McHardy:
  o [RBTREE]: Add rb_last()
  o [NET_SCHED]: Replace eligible list by rbtree in HFSC scheduler
  o [NET_SCHED]: Replace actlist by rbtrees in HFSC scheduler
  o [NET_SCHED]: O(1) children vtoff adjustment in HFSC scheduler
  o [PKT_SCHED]: cacheline-align qdisc data in qdisc_create()
  o [PKT_SCHED]: Resolve race condition with module unload in
    qdisc_create()
  o [PKT_SCHED]: Remove unnecessary memsets in packet schedulers
  o [XFRM]: Mark some functions/data static
  o [PKT_SCHED]: Fix class leak in CBQ scheduler
  o [PKT_SCHED]: Missing dev_put in error path

Paul Clements:
  o nbd: fix struct request race condition

Paul Gortmaker:
  o Remove obsolete code in 8390 driver

Paul Mackerras:
  o PPC64 Segment table code cleanup - move to arch/ppc64/mm
  o PPC64 Segment table code cleanup - kill bitfields
  o PPC64 Segment table code cleanup - assorted cleanups
  o PPC64 Segment table code cleanup - remove check duplication
  o PPC64 Segment table code cleanup - replace flush_stab() with
    switch_stab()
  o ppc32: handle misaligned string/multiple insns
  o ppc32: emulate obsolete instructions
  o ppc32: Fix bug in altivec emulation
  o ppc64: set time-related systemcfg fields
  o ppc64: use platform numbering of cpus for hypervisor calls
  o ppc64: use cpu_present_map in ppc64
  o ppc64: rework secondary SMT thread setup at boot
  o ppc64: remove unnecessary cpu maps
  o ppc64: set tbl->it_type in iommu code
  o ppc64: Don't call scheduler on offline cpu
  o ppc64: fix idle loop for offline cpu
  o ppc64: log firmware errors during boot
  o ppc64 Fix unbalanced pci_dev_put in EEH code
  o ppc64: Reduce verbosity of RTAS error logs
  o ppc64: rtas_call was calling kmalloc too early
  o ppc64: better little-endian bitops
  o ppc64: Extend ioremap/iounmap infrastructure
  o ppc64: Use correct buffer size in RTAS call
  o ppc64: use struct list_head for hose_list

Pavel Machek:
  o [CPUFREQ] Typo fixes
  o [CPUFREQ] Fix up deprecation notices

Pavel Roskin:
  o kbuild: Bogus "has no CRC" in external module builds

Pete Zaitcev:
  o USB: add ub driver

Phil Dibowitz:
  o USB: Debug fix in pl2303

Rajesh Venkatasubramanian:
  o prio_tree: kill vma_prio_tree_init()
  o prio_tree: iterator + vma_prio_tree_next cleanup

Ralf Bächle:
  o New driver for MV64340 GigE
  o [netdrvr mv643xx] rename from mv64340 to mv643xx
  o GT96100 update
  o [4/3] PCI quirks -- MIPS

Ram Pai:
  o readahead: simplify recent fixes
  o readahead fixes

Randy Dunlap:
  o kconfig: save kernel version in .config file
  o fix warnings in scripts/binoffset.c
  o scripts/patch-kernel: use EXTRAVERSION
  o tg3 section fix
  o awe_wave (OSS): too much __exit

Raphael Zimmerer:
  o PCI: fix PCI access mode dependences in arch/i386/Kconfig
  o PCI: fix PCI access mode dependences in arch/i386/Kconfig again
  o Support for Exar XR17C158 Octal UART

Rik van Riel:
  o token based thrashing control
  o increase per-user mlock limit default to 32k

Roger Luethi:
  o Restructure reset code
  o fix mc_filter on big-endian arch
  o Remove lingering PHY special casing
  o Rewrite PHY detection
  o Remove options, full_duplex parameters
  o Fix Tx engine race for good
  o Media mode rewrite
  o Small fixes and clean-up
  o Add WOL support
  o PCI: saved_config_space -> u32
  o proc_pid_cmdline() race fix

Roland McGrath:
  o Fix x86-64 singlestep through sigreturn system call

Rudolf Marek:
  o I2C: automatic VRM detection part1
  o I2C: automatic VRM detection part2

Russell King:
  o [MMC] Add MMC core support
  o [MMC] Add Kconfig/Makefile changes for MMC support
  o [MMC] Add ARM MMCI Primecell driver
  o [MMC] Add PXA MMC interface support
  o [MMC] Fix PXA MMC interface issues
  o [MMC] MMCI updates
  o [MMC] Fix some review points from Jens Axboe
  o [MMC] Fix PXA MCI driver name
  o [MMC] Use a consistent naming to refer to mmc_request,
    mmc_blk_request and request structures to avoid confusion.
  o [MMC] Fix end of request handling
  o [ARM] Move bootmem_init() call into paging_init()
  o [ARM] Add ARM AMBA CLCD framebuffer driver
  o [ARM] Add CLCD support for Versatile platform
  o [ARM] Add CLCD support for Integrator/CP platform
  o [ARM] Add CLCD support for IM-PD/1 board
  o [ARM] Fix Integrator CPUFREQ support
  o [ARM] Deprecate virt_to_bus/bus_to_virt
  o [ARM] Use bit 30 for PREEMPT_ACTIVE, delete unused TIF_USED_FPU
  o [ARM] Remove unnecessary get_user/put_user checks
  o [ARM] Update mach-types
  o [ARM] Add a structure name to pxa_dma_desc
  o [MMC] Update PXAMCI for later kernels
  o [MMC] Fix race condition in MMCI write-path data channel
  o [MMC] Avoid potential oops in MMCI
  o [MMC] Cleanup: Make MMCI debug macro take host, format and
    arguments
  o [MMC] MMCI optimisations

Ryan S. Arnold:
  o HVCS fixes

Sam Ravnborg:
  o kbuild: Check for undefined symbols in vmlinux
  o kbuild/sparc: Use new generic mksysmap script to generate
    System.map
  o kbuild: Selective compile of targets in scripts/
  o kbuild: Use LINUXINCLUDE to specify include/ directory
  o kbuild: Accept absolute paths in clean-files and introduce
    clean-dirs
  o kbuild: Separate out host-progs handling
  o kbuild: Introduce hostprogs-y, deprecate host-progs
  o kbuild: Replace host-progs with hostprogs-y
  o kbuild: Fix hostprogs-y
  o kbuild: __crc_* symbols in System.map
  o kbuild: Generate *.lds instead of *.lds.s
  o kbuild/all archs: Rename *.lds.s to *.lds
  o Cset exclude: adobriyan@mail.ru|ChangeSet|20040815084554|35832
  o bk: ignore arch/*/kernel/vmlinux.lds
  o kconfig/all archs: Introduce Kconfig.debug
  o kbuild: Allow external modules to use host-progs with no warning
  o kbuild/ia64: Fix breakage in arch/ia64/kernel/Makefile
  o kbuild: Fix parallel build in a distclean'ed tree
  o kbuild: make C=2 now force sparse to be run for all .c files
  o kbuild: Remove check for undefined symbols in vmlinux
  o kbuild: add comments to Makefile.clean
  o kbuild/all archs: added CHECKFLAGS
  o kbuild: Consolidated cc support function
  o kbuild/all archs: Utilise the cc-* functions

Samuel Thibault:
  o Subject: cdrom.c get_last_written fixup

Santiago Leon:
  o ibmveth: module tag fixes
  o ibmveth: hypervisor return value fix
  o ibmveth: add memory barrier for hypervisor synchronisation

Sascha Hauer:
  o [ARM PATCH] 1955/3: Motorola i.MX architecture support

Scott Feldman:
  o e100: use NAPI mode all the time

Sean Neakums:
  o kill UDF registration/unregistration messages

Shai Fultheim:
  o percpu: cpu_gdt_table
  o percpu: init_tss
  o percpu: cpu_tlbstate

Srivatsa Vaddagiri:
  o ppc64: Fix v_regs pointer setup

Stephen Hemminger:
  o [sparse] minor #if complaint
  o module_param for acenic
  o acenic - don't print eth%d in messages
  o [EBTABLES]: Remove deprecated use of MODULE_PARM
  o [NET]: Enhanced version of net_random()
  o [ATALK]: Fix build with SYSCTL=n

Stephen Rothwell:
  o ppc64 iSeries virtual DVD-RAM

Suparna Bhattacharya:
  o Fix writeback page range to use exact limits
  o mpage writepages range limit fix
  o filemap_fdatawrite range interface

Takashi Iwai:
  o i810_audio: Fix the error path of resource management

Thierry Vignaud:
  o fix compiling oldconfig with gcc-3.5

Timothy Shimmin:
  o [XFS] Fix up handling of SB versionnum when filesystem on disk has
    newer bit features than the kernel.

Tony Lindgren:
  o [ARM PATCH] 2005/1: OMAP update 1/6: Add McBSP support
  o [ARM PATCH] 2006/1: OMAP update 2/6: Board support files for OMAP
    H2 and H3
  o [ARM PATCH] 2007/1: OMAP update 3/6: Arch files
  o [ARM PATCH] 2008/1: OMAP update 4/6: Include files
  o [ARM PATCH] 2009/1: OMAP update 5/6: Remove old OMAP bus
  o [ARM PATCH] 2010/1: OMAP update 6/6: Add leds support for H2

Trond Myklebust:
  o Fix posix file locking (1-9)
  o NLM: Fix a bug which causes a newly granted lock to be immediately
    unlocked on the server side if blocking has occurred.
  o RPC: Reduce stack utilization for all synchronous NFS operations by
    using a dynamically allocated rpc_task structure instead of
    allocating one on the stack.  This reduces stack utilization by
  o NFSv4: ask the server to send us more readdir records per RPC call
  o RPC: Add missing variable initialization in rpc_clone_client()
  o NFSv3/v4: be more efficient when doing ACCESS RPC calls. Always ask
    for the full set of permissions.
  o NFSv4: Optimizing away the case of negative dentries in
    nfs_open_revalidate() avoids several atomicity problems.
  o NFSv4: Fix the symlink overflow bug
  o RPC: Improved buffer overrun checking in call_verify
  o RPCSEC_GSS: Remove an unused parameter
  o NFSv4: OK, so it's trivial and probably superfluous, but I don't
    see why we shouldn't be slightly stricter here, so I'm just going
    to keep sending this until I'm told to stop.... Make sure that
    unmapped errors are approximately in the range of defined NFS4
    errors.
  o RPCSEC_GSS: Missing newline in dprintk
  o RPCSEC_GSS: Add the spkm3 common and client-side code
  o NFS: Break the nfs_wreq_lock into per-mount locks. This helps
    prevent a heavy read and write workload on one mount point from
    interfering with workloads on other mount points.
  o NFS: Clean up the logic that handles recovery from a failed mount
    request. Get rid of nfs_put_super.
  o NFS: In 2.4, NFS O_DIRECT used the VFS's O_DIRECT logic to provide
    direct I/O support for NFS files.  The 2.4 VFS O_DIRECT logic was
    block based, thus the NFS client had to provide a minimum allowable
    blocksize for O_DIRECT reads and writes on NFS files. 
  o NFS: While the storage container for NFS file handles must be able
    to store 128 bytes, usually NFS servers don't use file handles that
    are more than 32 bytes in size.  This patch creates an efficient
    mechanism for comparing file handles that ignores the unused bytes
    in a file handle.
  o NFS: Now that file handle comparison ignores the unused parts of
    the file handle container, there is no longer any need to clear the
    file handle container before copying in a file handle.  This allows
    us to remove a 128 byte memset() from several hot paths.
  o KCONFIG: In the kernel help for NFSv3 & NFSv4 client support both
    are listed as "the newer version ... of the NFS protocol".
    Obviously both can't be the newer version at the same time, so
    here's a patch to correct the text in such a way that only v4 is
    listed as the newer version. Patch is against 2.6.7-rc3 - please
    consider including it.
  o NFSv2: In the NFSv3 RFC, the sattr3 structure passed in the SETATTR
    call allows for the client to request that the mtime and/or atime
  o NFSv4: Fix up the exception handling. Ensure we always handle
    NFS4ERR_DELAY properly.
  o NFSv4: Clean up the reboot recovery. Ensure that we exclude
    stateful
  o NFSv4: On server reboot we need to recover byte-range locks
  o NFSv4: Prime SETCLIENTID call for the delegation callback info
  o NFSv2/v3/v4: Place NFS nfs_page shared data into a single structure
    that hangs off filp->private_data. As a side effect, this also
    cleans up the NFSv4 private file state info.
  o NFSv4: More cleanups of the NFSv4 state
  o NFSv4: don't retry CREATE operations if the server returns
    NFS4ERR_DELAY on the GETATTR call.
  o NFSv2/v3/v4: Make the rpc_ops->getattr method take a filehandle
    rather than an inode argument. Fix up nfs_instantiate() and
    _nfs4_do_open to use this since doing a new lookup might be racy.
  o NFSv4: Basic code for managing delegation state
  o NFSv4: Add support for a delegation callback server
  o NFSv4: XDR cleanups in preparation for delegations
  o NFSv4: Further XDR cleanups in preparation for delegations
  o NFSv4: Service delegation recall requests from the server
  o NFSv4: More delegation recall code
  o NFSv4: Recover delegations on server reboot
  o NFSv4: Delegated open
  o NFSv4: More aggressive caching if we have a delegation
  o NFSv4: return all delegations we hold if the server issues a
    NFS4ERR_CB_PATH_DOWN error.
  o NFSv4: Enable delegations by actually telling the server about our
    recall ability.
  o RPC,NFSv4: NFSv4 operations that create or destroy state on the
    server are not allowed to be interrupted as that may result in the
    client and server disagreeing.

Venkatesh Pallipadi:
  o [CPUFREQ] Adding SMP capability to MSR based Enhanced Speedstep

Vernon Mauery:
  o PCI Hotplug: acpiphp extension for 2.6.7, part 1
  o PCI Hotplug: acpiphp extension for 2.6.7 part 2

William Lee Irwin III:
  o [ACPI] acpi_system_write_wakeup_device() has the wrong return type
    and is missing the __user attribution from its buffer argument.
  o [RXRPC]: Fix build with SYSCTL=n
  o sparc: remove undefined symbol

Wim Van Sebroeck:
  o [WATCHDOG] v2.6.8.1 cpu5wdt.c-nonseekable_open-patch
  o [WATCHDOG] v2.6.8.1 watchdog-llseek-patch

Zou Nanhai:
  o fix might-sleep-in-atomic while dumping elf

Zwane Mwaikambo:
  o x86: move PIT code to timer_pit

Re: Linux 2.6.9-rc1 (compile stats)

[John Cherry]

Errors in the allyesconfig build were related to the nfsroot.c error. 
See Russell King's patch ([PATCH] 2.6.9-rc1 compile fix: nfsroot.c).
Russell's patch is also PLM patch #3272 - in case you would like to
schedule any STP tests against it.

-------------------------------------------------------------------

Linux 2.6 Compile Statistics (gcc 3.2.2)
Warnings/Errors Summary

Kernel         bzImage    bzImage  bzImage  modules  bzImage   modules
             (defconfig)  (allno)  (allyes) (allyes) (allmod) (allmod)
-----------  -----------  -------- -------- -------- -------- ---------
2.6.9-rc1      0w/0e       0w/0e    77w/10e   4w/0e   3w/0e     68w/0e
2.6.8.1        0w/0e       0w/0e    78w/ 0e   4w/0e   1w/0e     72w/0e
2.6.8          0w/0e       0w/0e    78w/ 0e   4w/0e   1w/0e     72w/0e
2.6.8-rc4      0w/0e       0w/0e    78w/ 0e   4w/0e   1w/0e     72w/0e
2.6.8-rc3      0w/0e       0w/0e    78w/ 0e   4w/0e   1w/0e     72w/0e
2.6.8-rc2      0w/0e       0w/0e    85w/ 0e   5w/0e   1w/0e     79w/0e
2.6.8-rc1      0w/0e       0w/0e    87w/ 0e   5w/0e   1w/0e     82w/0e
2.6.7          0w/0e       0w/0e   108w/ 0e   5w/0e   2w/0e    102w/0e
2.6.7-rc3      0w/0e       0w/0e   108w/ 0e   5w/0e   2w/0e    104w/0e
2.6.7-rc2      0w/0e       0w/0e   110w/ 0e   5w/0e   2w/0e    106w/0e
2.6.7-rc1      0w/0e       0w/0e   111w/ 0e   6w/0e   2w/0e    107w/0e
2.6.6          0w/0e       0w/0e   123w/ 0e   7w/0e   4w/0e    121w/0e
2.6.6-rc3      0w/0e       0w/0e   124w/ 0e   7w/0e   5w/0e    121w/0e
2.6.6-rc2      0w/0e       0w/0e   122w/ 0e   7w/0e   4w/0e    121w/0e
2.6.6-rc1      0w/0e       0w/0e   125w/ 0e   7w/0e   4w/0e    123w/0e
2.6.5          0w/0e       0w/0e   134w/ 0e   8w/0e   4w/0e    132w/0e
2.6.5-rc3      0w/0e       0w/0e   135w/ 0e   8w/0e   4w/0e    132w/0e
2.6.5-rc2      0w/0e       0w/0e   135w/ 0e   8w/0e   3w/0e    132w/0e
2.6.5-rc1      0w/0e       0w/0e   138w/ 0e   8w/0e   3w/0e    135w/0e
2.6.4          1w/0e       0w/0e   145w/ 0e   7w/0e   3w/0e    142w/0e
2.6.4-rc2      1w/0e       0w/0e   148w/ 0e   7w/0e   3w/0e    145w/0e
2.6.4-rc1      1w/0e       0w/0e   148w/ 0e   7w/0e   3w/0e    145w/0e
2.6.3          1w/0e       0w/0e   142w/ 0e   9w/0e   3w/0e    142w/0e
2.6.3-rc4      1w/0e       0w/0e   142w/ 0e   9w/0e   3w/0e    142w/0e
2.6.3-rc3      1w/0e       0w/0e   145w/ 7e   9w/0e   3w/0e    148w/0e
2.6.3-rc2      1w/0e       0w/0e   141w/ 0e   9w/0e   3w/0e    144w/0e
2.6.3-rc1      1w/0e       0w/0e   145w/ 0e   9w/0e   3w/0e    177w/0e
2.6.2          1w/0e       0w/0e   152w/ 0e  12w/0e   3w/0e    187w/0e
2.6.2-rc3      0w/0e       0w/0e   152w/ 0e  12w/0e   3w/0e    187w/0e
2.6.2-rc2      0w/0e       0w/0e   153w/ 8e  12w/0e   3w/0e    188w/0e
2.6.2-rc1      0w/0e       0w/0e   152w/ 0e  12w/0e   3w/0e    187w/0e
2.6.1          0w/0e       0w/0e   158w/ 0e  12w/0e   3w/0e    197w/0e
2.6.1-rc3      0w/0e       0w/0e   158w/ 0e  12w/0e   3w/0e    197w/0e
2.6.1-rc2      0w/0e       0w/0e   166w/ 0e  12w/0e   3w/0e    205w/0e
2.6.1-rc1      0w/0e       0w/0e   167w/ 0e  12w/0e   3w/0e    206w/0e
2.6.0          0w/0e       0w/0e   170w/ 0e  12w/0e   3w/0e    209w/0e

Web page with links to complete details:
   http://developer.osdl.org/cherry/compile/
Daily compiles (ia32): 
   http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
Latest changes in Linus' bitkeeper tree:
   http://linux.bkbits.net:8080/linux-2.5

John

Re: Linux 2.6.9-rc1

[Pierre Ossman]

The MMC patches included in 2.6.9-rc1 missed drivers/Kconfig. A 'source 
"drivers/mmc/Kconfig"' is needed.
drivers/Makefile is ok though.

Rgds
Pierre Ossman

Re: Linux 2.6.9-rc1

[Russell King]

On Tue, Aug 24, 2004 at 06:41:58PM +0200, Pierre Ossman wrote:
> The MMC patches included in 2.6.9-rc1 missed drivers/Kconfig.

Not really.  The presently supported MMC interfaces only exist on ARM,
and ARM doesn't use drivers/Kconfig.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: Linux 2.6.9-rc1

[Pierre Ossman]

Russell King wrote:

>On Tue, Aug 24, 2004 at 06:41:58PM +0200, Pierre Ossman wrote:
>  
>
>>The MMC patches included in 2.6.9-rc1 missed drivers/Kconfig.
>>    
>>
>
>Not really.  The presently supported MMC interfaces only exist on ARM,
>and ARM doesn't use drivers/Kconfig.
>
>  
>
Ok, didn't know that.
Could it be added anyway? I'm writing a driver for a PC based SD/MMC 
card reader that relies on the routines. Would save me the trouble of 
having a patch for just the Kconfig. :)

Re: Linux 2.6.9-rc1

[Alexander Gran]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Dienstag, 24. August 2004 09:49 schrieb Linus Torvalds:
>   o e1000 - suspend/resume fix from alex@zodiac.dasalias.org

Its alex@zodiac.dnsalias.org just if someone wants to comment on that issue

regards
Alex
- -- 
Encrypted Mails welcome.
PGP-Key at http://zodiac.dnsalias.org/misc/pgpkey.asc | Key-ID: 0x6D7DD291
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBK3/L/aHb+2190pERAsFTAJ9QikilHy5ID//mFCaJ1rkcPyqa+gCfSYww
zfxhvROM13SXrnIouex55cY=
=p3bN
-----END PGP SIGNATURE-----

Re: Linux 2.6.9-rc1

[Matt Mackall]

On Tue, Aug 24, 2004 at 12:49:24AM -0700, Linus Torvalds wrote:
> Administrative trivia, and one thing I agonized over: should I make the
> patches relative to 2.6.8 or 2.6.8.1? I decided that since there is
> nothing that says that a "basic bug-fix" releases for a previous release
> might not happen _after_ we've done a -rc release for the next version, I
> can't sanely do patches against a bugfix release.
> 
> Thus the 2.6.9-rc1 patch is against plain 2.6.8. If you have 2.6.8.1, you
> need to undo the .1 patch, and apply the big one. BK users and tar-balls 
> don't see that particular confusion, of course ;)

Phew, I was worried about that. Can I get a ruling on how you intend
to handle a x.y.z.1 to x.y.z.2 transition? I've got a tool that I'm
looking to unbreak. My preference would be for all x.y.z.n patches to
be relative to x.y.z.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Linux 2.6.9-rc1

[Linus Torvalds]

On Tue, 24 Aug 2004, Matt Mackall wrote:
> 
> Phew, I was worried about that. Can I get a ruling on how you intend
> to handle a x.y.z.1 to x.y.z.2 transition? I've got a tool that I'm
> looking to unbreak. My preference would be for all x.y.z.n patches to
> be relative to x.y.z.

Hmm.. I have no strong preferences. There _is_ obviously a well-defined 
ordering from x.y.z.1 -> x.y.z.2 (unlike the -rcX releases that don't have 
any ordering wrt the bugfixes), so either interdiffs or whole new full 
diffs are totally "logical". We just have to chose one way or the other, 
and I don't actually much care.

Any reason for your preference? 

		Linus

Re: Linux 2.6.9-rc1

[Chris Meadors]

On Tue, 2004-08-24 at 12:23 -0700, Linus Torvalds wrote:
> 
> Hmm.. I have no strong preferences. There _is_ obviously a well-defined 
> ordering from x.y.z.1 -> x.y.z.2 (unlike the -rcX releases that don't have 
> any ordering wrt the bugfixes), so either interdiffs or whole new full 
> diffs are totally "logical". We just have to chose one way or the other, 
> and I don't actually much care.
> 
> Any reason for your preference? 

I'm not the original poster, but after a little thought I agreed with
his preference.  If the -rcs are going to be based on the non-bugfixed
releases, it follows that the next full patch will also have to be off
of the previous full release.

If each bugfix built on the last, instead of the full release, that
would be a number of patch files that I'd have to keep around, and then
undo when patching up to the next release.  If each bugfix included all
the previous bugfixes, it would just be one patch I'd have to undo.

-- 
Chris

Re: Linux 2.6.9-rc1

[Florian Weimer]

* Linus Torvalds:

> On Tue, 24 Aug 2004, Matt Mackall wrote:
>> 
>> Phew, I was worried about that. Can I get a ruling on how you intend
>> to handle a x.y.z.1 to x.y.z.2 transition? I've got a tool that I'm
>> looking to unbreak. My preference would be for all x.y.z.n patches to
>> be relative to x.y.z.
>
> Hmm.. I have no strong preferences. There _is_ obviously a well-defined 
> ordering from x.y.z.1 -> x.y.z.2 (unlike the -rcX releases that don't have 
> any ordering wrt the bugfixes), so either interdiffs or whole new full 
> diffs are totally "logical". We just have to chose one way or the other, 
> and I don't actually much care.

It would be slightly more consistent to diff .2 against .1 because
this is what already happens when a new x.y.z release is published.

Re: Linux 2.6.9-rc1

[Josh Boyer]

On Tue, 2004-08-24 at 14:54, Florian Weimer wrote:
> * Linus Torvalds:
> 
> > On Tue, 24 Aug 2004, Matt Mackall wrote:
> >> 
> >> Phew, I was worried about that. Can I get a ruling on how you intend
> >> to handle a x.y.z.1 to x.y.z.2 transition? I've got a tool that I'm
> >> looking to unbreak. My preference would be for all x.y.z.n patches to
> >> be relative to x.y.z.
> >
> > Hmm.. I have no strong preferences. There _is_ obviously a well-defined 
> > ordering from x.y.z.1 -> x.y.z.2 (unlike the -rcX releases that don't have 
> > any ordering wrt the bugfixes), so either interdiffs or whole new full 
> > diffs are totally "logical". We just have to chose one way or the other, 
> > and I don't actually much care.
> 
> It would be slightly more consistent to diff .2 against .1 because
> this is what already happens when a new x.y.z release is published.

Yes, but the -rcX releases aren't done that way.  It's mostly how you
view things.  From a users point of view, do I want to download x.y.z
and apply patches .1 through .N?  Or do I want to download x.y.z and
apply 1 patch to get me to the x.y.z.N level?

Personally, I prefer the "one patch to rule them all" method. :)

josh

Re: Linux 2.6.9-rc1

[Jesper Juhl]

On Tue, 24 Aug 2004, Josh Boyer wrote:

> On Tue, 2004-08-24 at 14:54, Florian Weimer wrote:
> > * Linus Torvalds:
> > 
> > > On Tue, 24 Aug 2004, Matt Mackall wrote:
> > >> 
> > >> Phew, I was worried about that. Can I get a ruling on how you intend
> > >> to handle a x.y.z.1 to x.y.z.2 transition? I've got a tool that I'm
> > >> looking to unbreak. My preference would be for all x.y.z.n patches to
> > >> be relative to x.y.z.
> > >
> > > Hmm.. I have no strong preferences. There _is_ obviously a well-defined 
> > > ordering from x.y.z.1 -> x.y.z.2 (unlike the -rcX releases that don't have 
> > > any ordering wrt the bugfixes), so either interdiffs or whole new full 
> > > diffs are totally "logical". We just have to chose one way or the other, 
> > > and I don't actually much care.
> > 
> > It would be slightly more consistent to diff .2 against .1 because
> > this is what already happens when a new x.y.z release is published.
> 
> Yes, but the -rcX releases aren't done that way.  It's mostly how you
> view things.  From a users point of view, do I want to download x.y.z
> and apply patches .1 through .N?  Or do I want to download x.y.z and
> apply 1 patch to get me to the x.y.z.N level?
> 
> Personally, I prefer the "one patch to rule them all" method. :)
> 
I agree, that would be my personal preference as well. Stick to what's 
currently done with the -rc, -mm etc patches - make x.y.z.2 be based on 
x.y.z, much easier on users. 
Also, the x.y.z.N patches are also most likely going to be pretty small 
even if diff'ed against x.y.z, so why burden the user with having to apply 
a series of patches?

--
Jesper Juhl

Re: Linux 2.6.9-rc1

[Tim Schmielau]

On Tue, 24 Aug 2004, Linus Torvalds wrote:

> Hmm.. I have no strong preferences. There _is_ obviously a well-defined 
> ordering from x.y.z.1 -> x.y.z.2 (unlike the -rcX releases that don't have 
> any ordering wrt the bugfixes), so either interdiffs or whole new full 
> diffs are totally "logical". We just have to chose one way or the other, 
> and I don't actually much care.
> 
> Any reason for your preference? 

I'd also vote for the x.y.z.2 to be based on x.y.z, because it's 
consistent with common practice. Currently all patches that I know of
that have an EXTRAVERSION are based on the corresponding kernels with
empty EXTRAVERSION. Be it -pre, -rc, -mm, -ac or whatever.

Tim

Re: Linux 2.6.9-rc1

[Matt Mackall]

On Tue, Aug 24, 2004 at 12:23:42PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 24 Aug 2004, Matt Mackall wrote:
> > 
> > Phew, I was worried about that. Can I get a ruling on how you intend
> > to handle a x.y.z.1 to x.y.z.2 transition? I've got a tool that I'm
> > looking to unbreak. My preference would be for all x.y.z.n patches to
> > be relative to x.y.z.
> 
> Hmm.. I have no strong preferences. There _is_ obviously a well-defined 
> ordering from x.y.z.1 -> x.y.z.2 (unlike the -rcX releases that don't have 
> any ordering wrt the bugfixes), so either interdiffs or whole new full 
> diffs are totally "logical". We just have to chose one way or the other, 
> and I don't actually much care.

Agreed.
 
> Any reason for your preference? 

Less code on my end, mostly. Which is equivalent to less fiddling for
people patching manually. Going from x.y.z.4 to x.y.(z+1) requires
looping through a bunch more intermediate versions which is tedious
for tracking -tip.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Linux 2.6.9-rc1

[Martin J. Bligh]

--Linus Torvalds <torvalds@osdl.org> wrote (on Tuesday, August 24, 2004 12:23:42 -0700):
> On Tue, 24 Aug 2004, Matt Mackall wrote:
>> 
>> Phew, I was worried about that. Can I get a ruling on how you intend
>> to handle a x.y.z.1 to x.y.z.2 transition? I've got a tool that I'm
>> looking to unbreak. My preference would be for all x.y.z.n patches to
>> be relative to x.y.z.
> 
> Hmm.. I have no strong preferences. There _is_ obviously a well-defined 
> ordering from x.y.z.1 -> x.y.z.2 (unlike the -rcX releases that don't have 
> any ordering wrt the bugfixes), so either interdiffs or whole new full 
> diffs are totally "logical". We just have to chose one way or the other, 
> and I don't actually much care.
> 
> Any reason for your preference? 

>From an automated tool point of view, it's easier to build a kernel
with just tarball + 1 patch (I have much the same issues as Matt to deal
with) ... also it works the same way as the current -rc releases, etc, 
so it's consistent.

M.

Re: Linux 2.6.9-rc1

[Dave Hansen]

On Tue, 2004-08-24 at 14:22, Martin J. Bligh wrote:
> >From an automated tool point of view, it's easier to build a kernel
> with just tarball + 1 patch (I have much the same issues as Matt to deal
> with) ... also it works the same way as the current -rc releases, etc, 
> so it's consistent.

The post-releases have tarballs all by themselves, though.  So, you
shouldn't really have anything to worry about for any of the post
releases, unless you're using something like ketchup which skips the
tarballs in favor of patching.  

-- Dave

Re: Linux 2.6.9-rc1

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.58.0408241221390.17766@ppc970.osdl.org>
By author:    Linus Torvalds <torvalds@osdl.org>
In newsgroup: linux.dev.kernel
> 
> Hmm.. I have no strong preferences. There _is_ obviously a well-defined 
> ordering from x.y.z.1 -> x.y.z.2 (unlike the -rcX releases that don't have 
> any ordering wrt the bugfixes), so either interdiffs or whole new full 
> diffs are totally "logical". We just have to chose one way or the other, 
> and I don't actually much care.
> 
> Any reason for your preference? 
> 

I concur with this preference, and for this reason:

Right now I'm treating x.y.z.w as a strange form of -pre, -rc, or
-test kernels.

Dealing with the various forms of the kernel naming scheme would
become even more complex if point releases were handled differently.

	-hpa

Re: Linux 2.6.9-rc1

[Dâniel Fraga]

In article <Pine.LNX.4.58.0408241221390.17766@ppc970.osdl.org>,
	Linus Torvalds <torvalds@osdl.org> writes:

> Any reason for your preference? 

	Linus, sorry but I can't agree with your decision.
    
    I'm not a developer, just an user and for me at least, there's no
sense in supplying a patch related do 2.6.8 instead of 2.6.8.1.

	I always update my kernel when the official patch is announced and
I'd expect to follow a well defined order (2.6.8 -> 2.6.8.1 ->
2.6.9...).

	Suppose we had 2.6.8.1, 2.6.8.2, 2.6.8.3 until 2.6.8.10. Should I
remove 10 patches just to update to 2.6.9? For me it's a waste of time.

	I know you kernel developers use BK or some other method, but...

	Thanks.

-- 
http://Processo.tk (1001 dias)
http://U-br.tk
Linux 2.6.7
São Paulo - SP

Re: Linux 2.6.9-rc1

[Daniel Andersen]

Dâniel Fraga wrote:
> In article <Pine.LNX.4.58.0408241221390.17766@ppc970.osdl.org>,
> 	Linus Torvalds <torvalds@osdl.org> writes:
> 
> 
>>Any reason for your preference? 
> 
> 
> 	Linus, sorry but I can't agree with your decision.
>     
>     I'm not a developer, just an user and for me at least, there's no
> sense in supplying a patch related do 2.6.8 instead of 2.6.8.1.
> 
> 	I always update my kernel when the official patch is announced and
> I'd expect to follow a well defined order (2.6.8 -> 2.6.8.1 ->
> 2.6.9...).
> 
> 	Suppose we had 2.6.8.1, 2.6.8.2, 2.6.8.3 until 2.6.8.10. Should I
> remove 10 patches just to update to 2.6.9? For me it's a waste of time.
> 
> 	I know you kernel developers use BK or some other method, but...
> 
> 	Thanks.
> 

As Linus initially said, there is the possibility of releasing a bug-fix 
patch 2.6.8.2 *after* 2.6.9 has been released. This can make things very 
confusing when patch-2.6.9 is against 2.6.8.1 and not 2.6.8.2 (or 
2.6.8). So if we use a rule of always patching against the first x.y.Z 
release (and not the last x.y.z.W by the time the new x.y.Z is released) 
we can assure consistence in the patch management.

Daniel Andersen
--

Re: Linux 2.6.9-rc1

[Dâniel Fraga]

In article <412BD946.1080908@linux-user.net>,
	Daniel Andersen <anddan@linux-user.net> writes:

> As Linus initially said, there is the possibility of releasing a bug-fix 
> patch 2.6.8.2 *after* 2.6.9 has been released. This can make things very 

	Why does this could happen? Do you agree with me that when 2.6.9 is
released, all future versions should be based on 2.6.9? Or it's a BK
issue I don't know?

> confusing when patch-2.6.9 is against 2.6.8.1 and not 2.6.8.2 (or 
> 2.6.8). So if we use a rule of always patching against the first x.y.Z 
> release (and not the last x.y.z.W by the time the new x.y.Z is released) 
> we can assure consistence in the patch management.

	Ok, I understand the problem. But isn't it possible to avoid
releasing some 2.6.8.x version after 2.6.9? I mean, I'm not
understanding why this could happen.

	Ps: sorry if this question is silly, but I didn't get the point why
2.6.8.2 could be released after 2.6.9.

-- 
http://Processo.tk (1001 dias)
http://U-br.tk
Linux 2.6.7
São Paulo - SP

Re: Linux 2.6.9-rc1

[H. Peter Anvin]

Followup to:  <805tv1-ec2.ln1@tux.abusar.org>
By author:    fraga@abusar.org ( =?ISO-8859-1?Q?D=E2niel?= Fraga)
In newsgroup: linux.dev.kernel
> 
> 	Ok, I understand the problem. But isn't it possible to avoid
> releasing some 2.6.8.x version after 2.6.9? I mean, I'm not
> understanding why this could happen.
> 
> 	Ps: sorry if this question is silly, but I didn't get the point why
> 2.6.8.2 could be released after 2.6.9.
> 

Because people don't want to upgrade to 2.6.9 for some reason (too big
of a change.)  Kind of like why we're still supporting 2.4, 2.2 and
(to some degree) 2.0.

	-hpa

Re: Linux 2.6.9-rc1

[Bill Davidsen]

Dâniel Fraga wrote:
> In article <412BD946.1080908@linux-user.net>,
> 	Daniel Andersen <anddan@linux-user.net> writes:
> 
> 
>>As Linus initially said, there is the possibility of releasing a bug-fix 
>>patch 2.6.8.2 *after* 2.6.9 has been released. This can make things very 
> 
> 
> 	Why does this could happen? Do you agree with me that when 2.6.9 is
> released, all future versions should be based on 2.6.9? Or it's a BK
> issue I don't know?
> 
> 
>>confusing when patch-2.6.9 is against 2.6.8.1 and not 2.6.8.2 (or 
>>2.6.8). So if we use a rule of always patching against the first x.y.Z 
>>release (and not the last x.y.z.W by the time the new x.y.Z is released) 
>>we can assure consistence in the patch management.
> 
> 
> 	Ok, I understand the problem. But isn't it possible to avoid
> releasing some 2.6.8.x version after 2.6.9? I mean, I'm not
> understanding why this could happen.
> 
> 	Ps: sorry if this question is silly, but I didn't get the point why
> 2.6.8.2 could be released after 2.6.9.
> 
Say an evil bug is discovered in 2.6.8.1 about the time people find out 
that cdrecord and vmware don't run on 2.6.9 and Oracle causes a massive 
memory leak. Since the developers seem to totally disregard pre-release 
testing with any 3rd party or closed source software, this isn't totally 
out of the question.

So out comes 2.6.8.2 to protect the honor and virtue of all the users 
who run 3rd party software for some silly reason like needing it to make 
a living.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Linux 2.6.9-rc1

[Stephen Wille Padnos]

Dâniel Fraga wrote:

>	I always update my kernel when the official patch is announced and
>I'd expect to follow a well defined order (2.6.8 -> 2.6.8.1 ->
>2.6.9...).
>
>	Suppose we had 2.6.8.1, 2.6.8.2, 2.6.8.3 until 2.6.8.10. Should I
>remove 10 patches just to update to 2.6.9? For me it's a waste of time.
>  
>
You wouldn't have to.  The patch method from 2.6.8.x to 2.6.8.x+1 would 
be this:
unpatch 2.6.8.x
patch 2.6.8.x+1

Actually, going from any patch sublevel to any other is the same two 
steps: remove the last patch level, patch to the new level.

- Steve

Re: Linux 2.6.9-rc1

[Dâniel Fraga]

In article <412BDC86.8000608@sover.net>,
	Stephen Wille Padnos <spadnos@sover.net> writes:

> You wouldn't have to.  The patch method from 2.6.8.x to 2.6.8.x+1 would 
> be this:
> unpatch 2.6.8.x
> patch 2.6.8.x+1
> Actually, going from any patch sublevel to any other is the same two 
> steps: remove the last patch level, patch to the new level.

	Ok, I got it. So we have to do this:
    
1) If I have 2.6.8 and I want upgrade it to 2.6.8.1, I apply the
2.6.8.1 patch

2) If I have 2.6.8.1 and I want upgrade it to 2.6.8.2, I have to remove
2.6.8.1, so it can go back to 2.6.8 and I can apply the 2.6.8.2
directly on the 2.6.8 kernel. This is valid for any 2.6.8.x version for
instance...

3) Finally, if I have 2.6.8.x kernel and I want upgrade it to 2.6.9, I
can just remove the 2.6.8.x patch and apply 2.6.9 on 2.6.8 as I'm used
to do.

	Ok, it seems reasonable now. Thank you very much.

-- 
http://Processo.tk (1001 dias)
http://U-br.tk
Linux 2.6.7
São Paulo - SP

Re: Linux 2.6.9-rc1

[Geert Uytterhoeven]

On Tue, 24 Aug 2004, Linus Torvalds wrote:
> On Tue, 24 Aug 2004, Matt Mackall wrote:
> > Phew, I was worried about that. Can I get a ruling on how you intend
> > to handle a x.y.z.1 to x.y.z.2 transition? I've got a tool that I'm
> > looking to unbreak. My preference would be for all x.y.z.n patches to
> > be relative to x.y.z.
>
> Hmm.. I have no strong preferences. There _is_ obviously a well-defined
> ordering from x.y.z.1 -> x.y.z.2 (unlike the -rcX releases that don't have
> any ordering wrt the bugfixes), so either interdiffs or whole new full
> diffs are totally "logical". We just have to chose one way or the other,
> and I don't actually much care.
>
> Any reason for your preference?

I prefer diffs between x.y.z.w-1 and x.y.z.w. x.y.z.{...,w-1,w,w+1,...} is one
stream of development, x.y.{...,z-1,z,z+1,...} is another one.

BTW, I always found it pretty rare that the rc patches weren't like that.
`unpatching' w-1 and `patching' w afterwards isn't fun if you have local
changes.

Gr{oetje,eeting}s,

						Geert

P.S. Personally I wouldn't suffer from unpatching and patching, since I use
     merging (using a script that does recursive merges with RCS merge). But if
     I would not be an architecture maintainer but just a plain user who
     sometimes does a few hacks (or applies some patches from others) on his
     kernel, I would just want to apply the x.y.z.w-1-to-x.y.z.w patch, fixup
     the (hopefully few) rejects, and be happy...
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Linux 2.6.9-rc1

[Bill Davidsen]

Linus Torvalds wrote:
> 
> On Tue, 24 Aug 2004, Matt Mackall wrote:
> 
>>Phew, I was worried about that. Can I get a ruling on how you intend
>>to handle a x.y.z.1 to x.y.z.2 transition? I've got a tool that I'm
>>looking to unbreak. My preference would be for all x.y.z.n patches to
>>be relative to x.y.z.
> 
> 
> Hmm.. I have no strong preferences. There _is_ obviously a well-defined 
> ordering from x.y.z.1 -> x.y.z.2 (unlike the -rcX releases that don't have 
> any ordering wrt the bugfixes), so either interdiffs or whole new full 
> diffs are totally "logical". We just have to chose one way or the other, 
> and I don't actually much care.
> 
> Any reason for your preference? 

It should work like a bk, so two kinds of logic aren't needed.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Linux 2.6.9-rc1

[Chris Wedgwood]

On Tue, Aug 24, 2004 at 12:49:24AM -0700, Linus Torvalds wrote:

> Jens Axboe:
>   o disk barriers: core
>   o disk barriers: IDE
>   o disk barriers: scsi
>   o disk barriers: devicemapper
>   o disk barriers: MD
>   o ext3 barrier support

What are the implications here when using an external journal?

When the log is external the writes can still be reordered and create
potential problems surely?  (ie. write <fs-stuff> <journal thing>
<fs-stuff> and since the <journal thing> is on a separate disk the
ordering will be messed up)...


  --cw

Re: Linux 2.6.9-rc1

[H. Peter Anvin]

Linus Torvalds wrote:
> Ok,
>  tons of patches merged, with me being away for a week, and also the
> normal pent-up patch demand after any stable kernel. Special thanks as
> always to Andrew, who synced up 200+ patches (he's attributed in the
> sign-off lines, but not in the appended shortlog, so I just wanted to
> point that out).
> 
> Changes all over: arm, ppc, sparc, acpi, i2c, usb, fbcon, ntfs, xfs, nfs,
> cpufreq, agp, sata, network drivers - you name it. Most of the changes are
> fairly small, but there's a lot of them.
> 
> Administrative trivia, and one thing I agonized over: should I make the
> patches relative to 2.6.8 or 2.6.8.1? I decided that since there is
> nothing that says that a "basic bug-fix" releases for a previous release
> might not happen _after_ we've done a -rc release for the next version, I
> can't sanely do patches against a bugfix release.
> 
> Thus the 2.6.9-rc1 patch is against plain 2.6.8. If you have 2.6.8.1, you
> need to undo the .1 patch, and apply the big one. BK users and tar-balls 
> don't see that particular confusion, of course ;)
> 

The kernel.org scripts I am pretty sure will assume 2.6.9-rc1 are against 
2.6.8, not 2.6.8.1.

	-hpa

Re: Linux 2.6.9-rc1

[Randy.Dunlap]

On Tue, 24 Aug 2004 14:48:30 -0700 H. Peter Anvin wrote:

| Linus Torvalds wrote:
| > Ok,
| >  tons of patches merged, with me being away for a week, and also the
| > normal pent-up patch demand after any stable kernel. Special thanks as
| > always to Andrew, who synced up 200+ patches (he's attributed in the
| > sign-off lines, but not in the appended shortlog, so I just wanted to
| > point that out).
| > 
| > Changes all over: arm, ppc, sparc, acpi, i2c, usb, fbcon, ntfs, xfs, nfs,
| > cpufreq, agp, sata, network drivers - you name it. Most of the changes are
| > fairly small, but there's a lot of them.
| > 
| > Administrative trivia, and one thing I agonized over: should I make the
| > patches relative to 2.6.8 or 2.6.8.1? I decided that since there is
| > nothing that says that a "basic bug-fix" releases for a previous release
| > might not happen _after_ we've done a -rc release for the next version, I
| > can't sanely do patches against a bugfix release.
| > 
| > Thus the 2.6.9-rc1 patch is against plain 2.6.8. If you have 2.6.8.1, you
| > need to undo the .1 patch, and apply the big one. BK users and tar-balls 
| > don't see that particular confusion, of course ;)
| > 
| 
| The kernel.org scripts I am pretty sure will assume 2.6.9-rc1 are against 
| 2.6.8, not 2.6.8.1.

Hey, I'll chime in and make it unanimous.  Maybe easier scripting like
Matt said, but definitely makes more sense (less surprise) for users
IMO.

--
~Randy

Re: Linux 2.6.9-rc1

[Chris Friesen]

I've run into a problem enabling CONFIG_IEEE1394_SBP2_PHYS_DMA for ppc64.  The
sbp2_handle_physdma_write() and _read() functions use bus_to_virt(), which 
doesn't appear to exist for ppc64.  Turning off the debug config parm enables 
the compile to proceed.

Chris

Re: Linux 2.6.9-rc1

[Matthias Andree]

On Tue, 24 Aug 2004, Linus Torvalds wrote:

>  tons of patches merged, with me being away for a week, and also the
> normal pent-up patch demand after any stable kernel. Special thanks as

For reasons I haven't yet fully understood, 2.6.9-rc1 appears to break
Amanda for me. amcheck passes, but amdump waits forever for data from
other machines while dumping. Older kernels appear to be fine.

Have there been relevant networking or security changes since 2.6.8.1?

Re: Linux 2.6.9-rc1

[Joshua Kwan]

Linus Torvalds wrote:
> Harald Welte:
...
>   o [NETFILTER]: Make 'helper' list of ip_nat_core static
...

I suspect that this changeset[1] somehow caused this to happen (many 
times) in dmesg:

ASSERT net/ipv4/netfilter/ip_nat_helper.c:428 &ip_nat_lock writelocked

It seems to be working properly (NATting two machines behind a local 
network to the Internet.)

Just FYI.

-- 
Joshua Kwan

[1] http://linux.bkbits.net:8080/linux-2.6/cset@1.1803.21.9

Re: Linux 2.6.9-rc1

[Harald Welte]

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

On Wed, Aug 25, 2004 at 11:52:30AM -0700, Joshua Kwan wrote:
> Linus Torvalds wrote:
> >Harald Welte:
> ...
> >  o [NETFILTER]: Make 'helper' list of ip_nat_core static
> ...
> 
> I suspect that this changeset[1] somehow caused this to happen (many 
> times) in dmesg:
> 
> ASSERT net/ipv4/netfilter/ip_nat_helper.c:428 &ip_nat_lock writelocked

yes, indeed.

> It seems to be working properly (NATting two machines behind a local 
> network to the Internet.)

The 'problem' is that we try to get a readlock while we're already
protected under a write lock.

Please see the following [quite trivial, but yet untested] patch:

--- linux-2.6.9-rc1/net/ipv4/netfilter/ip_nat_core.c	2004-08-25 22:22:36.450340504 +0200
+++ linux-2.6.9-rc1-find_helper/net/ipv4/netfilter/ip_nat_core.c	2004-08-25 22:28:37.668273271 +0200
@@ -635,7 +635,7 @@
 
 	/* If there's a helper, assign it; based on new tuple. */
 	if (!conntrack->master)
-		info->helper = ip_nat_find_helper(&reply);
+		info->helper = __ip_nat_find_helper(&reply);
 
 	/* It's done. */
 	info->initialized |= (1 << HOOK2MANIP(hooknum));
--- linux-2.6.9-rc1/net/ipv4/netfilter/ip_nat_helper.c	2004-08-25 22:22:36.453340376 +0200
+++ linux-2.6.9-rc1-find_helper/net/ipv4/netfilter/ip_nat_helper.c	2004-08-25 22:27:47.880335112 +0200
@@ -421,12 +421,18 @@
 }
 
 struct ip_nat_helper *
+__ip_nat_find_helper(const struct ip_conntrack_tuple *tuple)
+{
+	return LIST_FIND(&helpers, helper_cmp, struct ip_nat_helper *, tuple);
+}
+
+struct ip_nat_helper *
 ip_nat_find_helper(const struct ip_conntrack_tuple *tuple)
 {
 	struct ip_nat_helper *h;
 
 	READ_LOCK(&ip_nat_lock);
-	h = LIST_FIND(&helpers, helper_cmp, struct ip_nat_helper *, tuple);
+	h = __ip_nat_find_helper(tuple);
 	READ_UNLOCK(&ip_nat_lock);
 
 	return h;
--- linux-2.6.9-rc1/net/ipv4/netfilter/ip_nat_standalone.c	2004-08-25 22:22:36.461340035 +0200
+++ linux-2.6.9-rc1-find_helper/net/ipv4/netfilter/ip_nat_standalone.c	2004-08-25 22:29:30.047102589 +0200
@@ -394,4 +394,5 @@
 EXPORT_SYMBOL(ip_nat_mangle_tcp_packet);
 EXPORT_SYMBOL(ip_nat_mangle_udp_packet);
 EXPORT_SYMBOL(ip_nat_used_tuple);
+EXPORT_SYMBOL(ip_nat_find_helper);
 MODULE_LICENSE("GPL");

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

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

Re: Linux 2.6.9-rc1

[Henrik Nordstrom]

On Wed, 25 Aug 2004, Harald Welte wrote:

> The 'problem' is that we try to get a readlock while we're already
> protected under a write lock.
>
> Please see the following [quite trivial, but yet untested] patch:
>
> EXPORT_SYMBOL(ip_nat_used_tuple);
> +EXPORT_SYMBOL(ip_nat_find_helper);

Why this new exported symbol?

Regards
Henrik

Re: Linux 2.6.9-rc1

[Harald Welte]

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

On Wed, Aug 25, 2004 at 11:35:05PM +0200, Henrik Nordstrom wrote:
> On Wed, 25 Aug 2004, Harald Welte wrote:
> 
> >The 'problem' is that we try to get a readlock while we're already
> >protected under a write lock.
> >
> >Please see the following [quite trivial, but yet untested] patch:
> >
> >EXPORT_SYMBOL(ip_nat_used_tuple);
> >+EXPORT_SYMBOL(ip_nat_find_helper);
> 
> Why this new exported symbol?

Because other code that is not yet in the kernel needs it (like
ct_sync).  That's one of the reasons to get the API's straightened out
:)

> Regards
> Henrik

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

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

Re: Linux 2.6.9-rc1

[David S. Miller]

On Wed, 25 Aug 2004 22:32:06 +0200
Harald Welte <laforge@netfilter.org> wrote:

Harald, a question about this fix.

> +__ip_nat_find_helper(const struct ip_conntrack_tuple *tuple)
> +{
> +	return LIST_FIND(&helpers, helper_cmp, struct ip_nat_helper *, tuple);
> +}
> +
> +struct ip_nat_helper *
>  ip_nat_find_helper(const struct ip_conntrack_tuple *tuple)
>  {
>  	struct ip_nat_helper *h;
>  
>  	READ_LOCK(&ip_nat_lock);
> -	h = LIST_FIND(&helpers, helper_cmp, struct ip_nat_helper *, tuple);
> +	h = __ip_nat_find_helper(tuple);
>  	READ_UNLOCK(&ip_nat_lock);
>  

So we're converting over to using __ip_nat_find_helper().

> +EXPORT_SYMBOL(ip_nat_find_helper);

And adding an export of ip_nat_find_helper (ie. without the two underscore
prefix).  Why?

If we need to export one, then we need to export both.

Re: Linux 2.6.9-rc1

[Joshua Kwan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David S. Miller wrote:
| And adding an export of ip_nat_find_helper (ie. without the two underscore
| prefix).  Why?
|
| If we need to export one, then we need to export both.

Exporting both was the only way I could get it to compile. On the other
hand, the fix seems to have worked without any further repercussions.

- --
Joshua Kwan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQS1Ve6OILr94RG8mAQLEIhAAqzFjNVxhFmCvj2nYwbMa8l3I7SJdzrFf
ge1Rua8ktQMOemVebWuReQLsAYm70MCS/JJujAk25raZVTNHtzazNd/bJ03pbjnO
xcUVt+JK1OzWJcoQYvzJRhDGzrY7GHn/93P0DK5+ROSYBAUVzBT6rO67cJBpsM7V
t4PVpgMFVpw/sP53sR3uyUSotSPVIHrXnsplyiAvCxhz+y14zwRI9QEhKmRVzjhb
PlJBooRMmB0rb6l1JATAp3EVpJsA6CBczMd0nsQV478r05OVZkkWcTHT5IlFv2Dr
k3tDotHKK0FQuqDHULQeuqVWP9Sl35Zp/hEzZQNjywptC0LG7e3x21N/BahuqqaJ
w+CkunMK4QkmizJNgMHC/CDeaJP1ZlhV9G0V7pTwojjatO4TmQFEtNbaVhaQziCv
0wx2qeM4nASFyiXwcWR1WSZ4K37NRVYNPlpeAo9QKaW54HZ/tar44bqAMfuAtaqP
yBNxAT58daPrOT2/ePnbzEMReueMiaWDBoJuzoHxhZ6thbubviYT0iitHKagckeU
JKKZsKi9t4SJydDZ2pjbFx9bzO4EC6sgjB7YT/1N6ulubu8DFsZYNEfax3n8NgNX
zmeaVYD/ezUjE5dKXU45PB0KhySDx396x2nh5kcbXPl0NcB8oRX5Hrh/KgOlEbEa
allwXmgYrYA=
=d+1T
-----END PGP SIGNATURE-----

Re: Linux 2.6.9-rc1

[Harald Welte]

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

On Wed, Aug 25, 2004 at 04:44:01PM -0700, David S. Miller wrote:
> On Wed, 25 Aug 2004 22:32:06 +0200
> Harald Welte <laforge@netfilter.org> wrote:
> 
> Harald, a question about this fix.

Sorry about not commenting on this initially.

> So we're converting over to using __ip_nat_find_helper().
>
> And adding an export of ip_nat_find_helper (ie. without the two underscore
> prefix).  Why?
> 
> If we need to export one, then we need to export both.

yes, we're using __ip_nat_find_helper from within the NAT core (which is
one module built from multiple .o files), and we export ip_nat_find_helper
for other kernel modules, such as helpers and ct_sync (none of it is in
mainline kernel yet).

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

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

Re: Linux 2.6.9-rc1

[Mark Lord]

On the one system I have tried this kernel on, it hangs solid
just after successful DHCP negotiation (userland) on Debian-Sarge.
System is using SMP kernel on SMP board with a single P3-750 CPU.

Reconfiguring the kernel to exclude the net-filter stuff fixes it for me.

The 2.6.8-rc4 kernel was the previous version on the same machine,
and did not have this problem.

I'm kinda under deadline right now for something else,
so I haven't taken time to chase it any further.

Cheers
-- 
Mark Lord
(hdparm keeper & the original "Linux IDE Guy")

Re: Linux 2.6.9-rc1

[David S. Miller]

On Wed, 25 Aug 2004 23:14:07 -0700
"David S. Miller" <davem@redhat.com> wrote:

> 
> Known problem, tonights BK sync has the fix.  Included below for
> your convenience:

Duh, the actual patch this time.
:)

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/08/25 20:20:04-07:00 laforge@netfilter.org 
#   [NETFILTER]: Fix ip_nat_find_helper() locking.
#   
#   Signed-off-by: Harald Welte <laforge@netfilter.org>
#   Signed-off-by: David S. Miller <davem@redhat.com>
# 
# net/ipv4/netfilter/ip_nat_standalone.c
#   2004/08/25 20:19:30-07:00 laforge@netfilter.org +2 -0
#   [NETFILTER]: Fix ip_nat_find_helper() locking.
# 
# net/ipv4/netfilter/ip_nat_helper.c
#   2004/08/25 20:19:30-07:00 laforge@netfilter.org +7 -1
#   [NETFILTER]: Fix ip_nat_find_helper() locking.
# 
# net/ipv4/netfilter/ip_nat_core.c
#   2004/08/25 20:19:30-07:00 laforge@netfilter.org +1 -1
#   [NETFILTER]: Fix ip_nat_find_helper() locking.
# 
# include/linux/netfilter_ipv4/ip_nat_helper.h
#   2004/08/25 20:19:30-07:00 laforge@netfilter.org +3 -0
#   [NETFILTER]: Fix ip_nat_find_helper() locking.
# 
diff -Nru a/include/linux/netfilter_ipv4/ip_nat_helper.h b/include/linux/netfilter_ipv4/ip_nat_helper.h
--- a/include/linux/netfilter_ipv4/ip_nat_helper.h	2004-08-25 23:15:04 -07:00
+++ b/include/linux/netfilter_ipv4/ip_nat_helper.h	2004-08-25 23:15:04 -07:00
@@ -44,6 +44,9 @@
 extern struct ip_nat_helper *
 ip_nat_find_helper(const struct ip_conntrack_tuple *tuple);
 
+extern struct ip_nat_helper *
+__ip_nat_find_helper(const struct ip_conntrack_tuple *tuple);
+
 /* These return true or false. */
 extern int ip_nat_mangle_tcp_packet(struct sk_buff **skb,
 				struct ip_conntrack *ct,
diff -Nru a/net/ipv4/netfilter/ip_nat_core.c b/net/ipv4/netfilter/ip_nat_core.c
--- a/net/ipv4/netfilter/ip_nat_core.c	2004-08-25 23:15:04 -07:00
+++ b/net/ipv4/netfilter/ip_nat_core.c	2004-08-25 23:15:04 -07:00
@@ -635,7 +635,7 @@
 
 	/* If there's a helper, assign it; based on new tuple. */
 	if (!conntrack->master)
-		info->helper = ip_nat_find_helper(&reply);
+		info->helper = __ip_nat_find_helper(&reply);
 
 	/* It's done. */
 	info->initialized |= (1 << HOOK2MANIP(hooknum));
diff -Nru a/net/ipv4/netfilter/ip_nat_helper.c b/net/ipv4/netfilter/ip_nat_helper.c
--- a/net/ipv4/netfilter/ip_nat_helper.c	2004-08-25 23:15:04 -07:00
+++ b/net/ipv4/netfilter/ip_nat_helper.c	2004-08-25 23:15:04 -07:00
@@ -421,12 +421,18 @@
 }
 
 struct ip_nat_helper *
+__ip_nat_find_helper(const struct ip_conntrack_tuple *tuple)
+{
+	return LIST_FIND(&helpers, helper_cmp, struct ip_nat_helper *, tuple);
+}
+
+struct ip_nat_helper *
 ip_nat_find_helper(const struct ip_conntrack_tuple *tuple)
 {
 	struct ip_nat_helper *h;
 
 	READ_LOCK(&ip_nat_lock);
-	h = LIST_FIND(&helpers, helper_cmp, struct ip_nat_helper *, tuple);
+	h = __ip_nat_find_helper(tuple);
 	READ_UNLOCK(&ip_nat_lock);
 
 	return h;
diff -Nru a/net/ipv4/netfilter/ip_nat_standalone.c b/net/ipv4/netfilter/ip_nat_standalone.c
--- a/net/ipv4/netfilter/ip_nat_standalone.c	2004-08-25 23:15:04 -07:00
+++ b/net/ipv4/netfilter/ip_nat_standalone.c	2004-08-25 23:15:04 -07:00
@@ -394,4 +394,6 @@
 EXPORT_SYMBOL(ip_nat_mangle_tcp_packet);
 EXPORT_SYMBOL(ip_nat_mangle_udp_packet);
 EXPORT_SYMBOL(ip_nat_used_tuple);
+EXPORT_SYMBOL(ip_nat_find_helper);
+EXPORT_SYMBOL(__ip_nat_find_helper);
 MODULE_LICENSE("GPL");

2.6.9-rc1: missing netfilter help texts

[Adrian Bunk]

The following new netfilter options lack help texts:
- IP_NF_CT_ACCT
- IP_NF_MATCH_SCTP
- IP_NF_CT_PROTO_SCTP

Could someone add the help texts?

TIA
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: [netfilter-core] 2.6.9-rc1: missing netfilter help texts

[Harald Welte]

[-- Attachment #1.1: Type: text/plain, Size: 780 bytes --]

On Tue, Aug 31, 2004 at 07:34:25PM +0200, Adrian Bunk wrote:
> The following new netfilter options lack help texts:
> - IP_NF_CT_ACCT
> - IP_NF_MATCH_SCTP
> - IP_NF_CT_PROTO_SCTP
> 
> Could someone add the help texts?

Patch to add help texts attached, as well as a second, incremental patch
to sort entries into reasonable order

Signed-off-by: Harald Welte <laforge@netfilter.org>

> Adrian

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #1.2: linux-2.6.9-rc1-nfhelp1.diff --]
[-- Type: text/plain, Size: 1639 bytes --]

diff -Nru --exclude .depend --exclude '*.o' --exclude '*.ko' --exclude '*.ver' --exclude '.*.flags' --exclude '*.orig' --exclude '*.rej' --exclude '*.cmd' --exclude '*.mod.c' --exclude '*~' linux-2.6.9-rc1-plain/net/ipv4/netfilter/Kconfig linux-2.6.9-rc1-nfhelp/net/ipv4/netfilter/Kconfig
--- linux-2.6.9-rc1-plain/net/ipv4/netfilter/Kconfig	2004-08-31 20:24:43.000000000 +0200
+++ linux-2.6.9-rc1-nfhelp/net/ipv4/netfilter/Kconfig	2004-08-31 20:29:12.000000000 +0200
@@ -631,14 +631,35 @@
 config IP_NF_CT_ACCT
 	bool "Connection tracking flow accounting"
 	depends on IP_NF_CONNTRACK
+	help
+	  If this option is enabled, the connection tracking code will
+	  keep per-flow packet and byte counters.
+
+	  Those counters can be used for flow-based accounting or the
+	  `connbytes' match.
+
+	  If unsure, say `N'.
 
 config IP_NF_MATCH_SCTP
 	tristate  'SCTP protocol match support'
 	depends on IP_NF_IPTABLES
+	help
+	  With this option enabled, you will be able to use the iptables
+	  `sctp' match in order to match on SCTP source/destination ports
+	  and SCTP chunk types.
+
+	  If you want to compile it as a module, say M here and read
+	  Documentation/modules.txt.  If unsure, say `N'.
 
 config IP_NF_CT_PROTO_SCTP
 	tristate  'SCTP protocol connection tracking support (EXPERIMENTAL)'
 	depends on IP_NF_CONNTRACK && EXPERIMENTAL
+	help
+	  With this option enabled, the connection tracking code will
+	  be able to do state tracking on SCTP connections.
+
+	  If you want to compile it as a module, say M here and read
+	  Documentation/modules.txt.  If unsure, say `N'.
 
 endmenu
 

[-- Attachment #1.3: linux-2.6.9-rc1-nfhelp2.diff --]
[-- Type: text/plain, Size: 11631 bytes --]

diff -Nru --exclude .depend --exclude '*.o' --exclude '*.ko' --exclude '*.ver' --exclude '.*.flags' --exclude '*.orig' --exclude '*.rej' --exclude '*.cmd' --exclude '*.mod.c' --exclude '*~' linux-2.6.9-rc1-nfhelp/net/ipv4/netfilter/Kconfig linux-2.6.9-rc1-nfhelp2/net/ipv4/netfilter/Kconfig
--- linux-2.6.9-rc1-nfhelp/net/ipv4/netfilter/Kconfig	2004-08-31 20:30:50.000000000 +0200
+++ linux-2.6.9-rc1-nfhelp2/net/ipv4/netfilter/Kconfig	2004-08-31 20:36:46.000000000 +0200
@@ -5,6 +5,7 @@
 menu "IP: Netfilter Configuration"
 	depends on INET && NETFILTER
 
+# connection tracking, helpers and protocols
 config IP_NF_CONNTRACK
 	tristate "Connection tracking (required for masq/NAT)"
 	---help---
@@ -19,6 +20,28 @@
 
 	  To compile it as a module, choose M here.  If unsure, say N.
 
+config IP_NF_CT_ACCT
+	bool "Connection tracking flow accounting"
+	depends on IP_NF_CONNTRACK
+	help
+	  If this option is enabled, the connection tracking code will
+	  keep per-flow packet and byte counters.
+
+	  Those counters can be used for flow-based accounting or the
+	  `connbytes' match.
+
+	  If unsure, say `N'.
+
+config IP_NF_CT_PROTO_SCTP
+	tristate  'SCTP protocol connection tracking support (EXPERIMENTAL)'
+	depends on IP_NF_CONNTRACK && EXPERIMENTAL
+	help
+	  With this option enabled, the connection tracking code will
+	  be able to do state tracking on SCTP connections.
+
+	  If you want to compile it as a module, say M here and read
+	  Documentation/modules.txt.  If unsure, say `N'.
+
 config IP_NF_FTP
 	tristate "FTP protocol support"
 	depends on IP_NF_CONNTRACK
@@ -86,7 +109,7 @@
 
 	  To compile it as a module, choose M here.  If unsure, say N.
 
-# The simple matches.
+# The matches.
 config IP_NF_MATCH_LIMIT
 	tristate "limit match support"
 	depends on IP_NF_IPTABLES
@@ -274,7 +297,42 @@
 
 	  To compile it as a module, choose M here.  If unsure, say N.
 
-# The targets
+config IP_NF_MATCH_ADDRTYPE
+	tristate  'address type match support'
+	depends on IP_NF_IPTABLES
+	help
+	  This option allows you to match what routing thinks of an address,
+	  eg. UNICAST, LOCAL, BROADCAST, ...
+	
+	  If you want to compile it as a module, say M here and read
+	  Documentation/modules.txt.  If unsure, say `N'.
+
+config IP_NF_MATCH_REALM
+	tristate  'realm match support'
+	depends on IP_NF_IPTABLES
+	select NET_CLS_ROUTE
+	help
+	  This option adds a `realm' match, which allows you to use the realm
+	  key from the routing subsytem inside iptables.
+	
+	  This match pretty much resembles the CONFIG_NET_CLS_ROUTE4 option 
+	  in tc world.
+	
+	  If you want to compile it as a module, say M here and read
+	  Documentation/modules.txt.  If unsure, say `N'.
+
+config IP_NF_MATCH_SCTP
+	tristate  'SCTP protocol match support'
+	depends on IP_NF_IPTABLES
+	help
+	  With this option enabled, you will be able to use the iptables
+	  `sctp' match in order to match on SCTP source/destination ports
+	  and SCTP chunk types.
+
+	  If you want to compile it as a module, say M here and read
+	  Documentation/modules.txt.  If unsure, say `N'.
+
+# `filter', generic and specific targets
 config IP_NF_FILTER
 	tristate "Packet filtering"
 	depends on IP_NF_IPTABLES
@@ -295,6 +353,56 @@
 
 	  To compile it as a module, choose M here.  If unsure, say N.
 
+config IP_NF_TARGET_LOG
+	tristate "LOG target support"
+	depends on IP_NF_IPTABLES
+	help
+	  This option adds a `LOG' target, which allows you to create rules in
+	  any iptables table which records the packet header to the syslog.
+
+	  To compile it as a module, choose M here.  If unsure, say N.
+
+config IP_NF_TARGET_ULOG
+	tristate "ULOG target support"
+	depends on IP_NF_IPTABLES
+	---help---
+	  This option adds a `ULOG' target, which allows you to create rules in
+	  any iptables table. The packet is passed to a userspace logging
+	  daemon using netlink multicast sockets; unlike the LOG target
+	  which can only be viewed through syslog.
+
+	  The apropriate userspace logging daemon (ulogd) may be obtained from
+	  <http://www.gnumonks.org/projects/ulogd/>
+
+	  To compile it as a module, choose M here.  If unsure, say N.
+
+config IP_NF_TARGET_TCPMSS
+	tristate "TCPMSS target support"
+	depends on IP_NF_IPTABLES
+	---help---
+	  This option adds a `TCPMSS' target, which allows you to alter the
+	  MSS value of TCP SYN packets, to control the maximum size for that
+	  connection (usually limiting it to your outgoing interface's MTU
+	  minus 40).
+
+	  This is used to overcome criminally braindead ISPs or servers which
+	  block ICMP Fragmentation Needed packets.  The symptoms of this
+	  problem are that everything works fine from your Linux
+	  firewall/router, but machines behind it can never exchange large
+	  packets:
+	  	1) Web browsers connect, then hang with no data received.
+	  	2) Small mail works fine, but large emails hang.
+	  	3) ssh works fine, but scp hangs after initial handshaking.
+
+	  Workaround: activate this option and add a rule to your firewall
+	  configuration like:
+
+	  iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
+	  		 -j TCPMSS --clamp-mss-to-pmtu
+
+	  To compile it as a module, choose M here.  If unsure, say N.
+
+# NAT + specific targets
 config IP_NF_NAT
 	tristate "Full NAT"
 	depends on IP_NF_IPTABLES && IP_NF_CONNTRACK
@@ -408,6 +516,7 @@
 	default IP_NF_NAT if IP_NF_AMANDA=y
 	default m if IP_NF_AMANDA=m
 
+# mangle + specific targets
 config IP_NF_MANGLE
 	tristate "Packet mangling"
 	depends on IP_NF_IPTABLES
@@ -478,55 +587,34 @@
 
 	  To compile it as a module, choose M here.  If unsure, say N.
 
-config IP_NF_TARGET_LOG
-	tristate "LOG target support"
+# raw + specific targets
+config IP_NF_RAW
+	tristate  'raw table support (required for NOTRACK/TRACE)'
 	depends on IP_NF_IPTABLES
 	help
-	  This option adds a `LOG' target, which allows you to create rules in
-	  any iptables table which records the packet header to the syslog.
-
-	  To compile it as a module, choose M here.  If unsure, say N.
-
-config IP_NF_TARGET_ULOG
-	tristate "ULOG target support"
-	depends on IP_NF_IPTABLES
-	---help---
-	  This option adds a `ULOG' target, which allows you to create rules in
-	  any iptables table. The packet is passed to a userspace logging
-	  daemon using netlink multicast sockets; unlike the LOG target
-	  which can only be viewed through syslog.
-
-	  The apropriate userspace logging daemon (ulogd) may be obtained from
-	  <http://www.gnumonks.org/projects/ulogd/>
-
-	  To compile it as a module, choose M here.  If unsure, say N.
-
-config IP_NF_TARGET_TCPMSS
-	tristate "TCPMSS target support"
-	depends on IP_NF_IPTABLES
-	---help---
-	  This option adds a `TCPMSS' target, which allows you to alter the
-	  MSS value of TCP SYN packets, to control the maximum size for that
-	  connection (usually limiting it to your outgoing interface's MTU
-	  minus 40).
-
-	  This is used to overcome criminally braindead ISPs or servers which
-	  block ICMP Fragmentation Needed packets.  The symptoms of this
-	  problem are that everything works fine from your Linux
-	  firewall/router, but machines behind it can never exchange large
-	  packets:
-	  	1) Web browsers connect, then hang with no data received.
-	  	2) Small mail works fine, but large emails hang.
-	  	3) ssh works fine, but scp hangs after initial handshaking.
-
-	  Workaround: activate this option and add a rule to your firewall
-	  configuration like:
+	  This option adds a `raw' table to iptables. This table is the very
+	  first in the netfilter framework and hooks in at the PREROUTING
+	  and OUTPUT chains.
+	
+	  If you want to compile it as a module, say M here and read
+	  <file:Documentation/modules.txt>.  If unsure, say `N'.
+	  help
 
-	  iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-	  		 -j TCPMSS --clamp-mss-to-pmtu
+config IP_NF_TARGET_NOTRACK
+	tristate  'NOTRACK target support'
+	depends on IP_NF_RAW
+	depends on IP_NF_CONNTRACK
+	help
+	  The NOTRACK target allows a select rule to specify
+	  which packets *not* to enter the conntrack/NAT
+	  subsystem with all the consequences (no ICMP error tracking,
+	  no protocol helpers for the selected packets).
+	
+	  If you want to compile it as a module, say M here and read
+	  <file:Documentation/modules.txt>.  If unsure, say `N'.
 
-	  To compile it as a module, choose M here.  If unsure, say N.
 
+# ARP tables
 config IP_NF_ARPTABLES
 	tristate "ARP tables support"
 	help
@@ -579,87 +667,5 @@
 
 	  To compile it as a module, choose M here.  If unsure, say N.
 
-config IP_NF_TARGET_NOTRACK
-	tristate  'NOTRACK target support'
-	depends on IP_NF_RAW
-	depends on IP_NF_CONNTRACK
-	help
-	  The NOTRACK target allows a select rule to specify
-	  which packets *not* to enter the conntrack/NAT
-	  subsystem with all the consequences (no ICMP error tracking,
-	  no protocol helpers for the selected packets).
-	
-	  If you want to compile it as a module, say M here and read
-	  <file:Documentation/modules.txt>.  If unsure, say `N'.
-
-config IP_NF_RAW
-	tristate  'raw table support (required for NOTRACK/TRACE)'
-	depends on IP_NF_IPTABLES
-	help
-	  This option adds a `raw' table to iptables. This table is the very
-	  first in the netfilter framework and hooks in at the PREROUTING
-	  and OUTPUT chains.
-	
-	  If you want to compile it as a module, say M here and read
-	  <file:Documentation/modules.txt>.  If unsure, say `N'.
-	  help
-
-config IP_NF_MATCH_ADDRTYPE
-	tristate  'address type match support'
-	depends on IP_NF_IPTABLES
-	help
-	  This option allows you to match what routing thinks of an address,
-	  eg. UNICAST, LOCAL, BROADCAST, ...
-	
-	  If you want to compile it as a module, say M here and read
-	  Documentation/modules.txt.  If unsure, say `N'.
-
-config IP_NF_MATCH_REALM
-	tristate  'realm match support'
-	depends on IP_NF_IPTABLES
-	select NET_CLS_ROUTE
-	help
-	  This option adds a `realm' match, which allows you to use the realm
-	  key from the routing subsytem inside iptables.
-	
-	  This match pretty much resembles the CONFIG_NET_CLS_ROUTE4 option 
-	  in tc world.
-	
-	  If you want to compile it as a module, say M here and read
-	  Documentation/modules.txt.  If unsure, say `N'.
-
-config IP_NF_CT_ACCT
-	bool "Connection tracking flow accounting"
-	depends on IP_NF_CONNTRACK
-	help
-	  If this option is enabled, the connection tracking code will
-	  keep per-flow packet and byte counters.
-
-	  Those counters can be used for flow-based accounting or the
-	  `connbytes' match.
-
-	  If unsure, say `N'.
-
-config IP_NF_MATCH_SCTP
-	tristate  'SCTP protocol match support'
-	depends on IP_NF_IPTABLES
-	help
-	  With this option enabled, you will be able to use the iptables
-	  `sctp' match in order to match on SCTP source/destination ports
-	  and SCTP chunk types.
-
-	  If you want to compile it as a module, say M here and read
-	  Documentation/modules.txt.  If unsure, say `N'.
-
-config IP_NF_CT_PROTO_SCTP
-	tristate  'SCTP protocol connection tracking support (EXPERIMENTAL)'
-	depends on IP_NF_CONNTRACK && EXPERIMENTAL
-	help
-	  With this option enabled, the connection tracking code will
-	  be able to do state tracking on SCTP connections.
-
-	  If you want to compile it as a module, say M here and read
-	  Documentation/modules.txt.  If unsure, say `N'.
-
 endmenu
 

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

RE: Linux 2.6.9-rc1

[Sartorelli, Kevin]

Daniel Andersen wrote:
> As Linus initially said, there is the possibility of releasing 
> a bug-fix patch 2.6.8.2 *after* 2.6.9 has been released.

So, in this case, which would be considered the latest stable kernel to be used in production?  I can see this getting to a stage where you just pick and hope :-(

Cheers
Kevin

Re: Linux 2.6.9-rc1

[Daniel Andersen]

Sartorelli, Kevin wrote:
> Daniel Andersen wrote:
> 
>>As Linus initially said, there is the possibility of releasing 
>>a bug-fix patch 2.6.8.2 *after* 2.6.9 has been released.
> 
> 
> So, in this case, which would be considered the latest stable kernel to be used in production?  I can see this getting to a stage where you just pick and hope :-(
> 
> Cheers
> Kevin

This would normally be 2.6.9(.w). I did not point it out but Linus said 
-rc kernels.
Lately there has been some talk about removing deprecated features (eg. 
devfs, cryptoloop) which makes me think. Linus, is there a chance that 
there will be a x.y.z.W release of an old kernel after the next x.y.Z.w 
has been released and no longer is -rc? For example releasing a 2.6.8.2 
after 2.6.9 has been released and no longer is a 2.6.9-rcX.

In this case Kevin would have a point.

Daniel Andersen
--

Re: Linux 2.6.9-rc1

[Linus Torvalds]

On Wed, 25 Aug 2004, Daniel Andersen wrote:
>
>					 Linus, is there a chance that 
> there will be a x.y.z.W release of an old kernel after the next x.y.Z.w 
> has been released and no longer is -rc? For example releasing a 2.6.8.2 
> after 2.6.9 has been released and no longer is a 2.6.9-rcX.

I don't see the point of such a release, so I'd say "no". Once we have a 
stable kernel, we make updates to _that_ one, not older ones.

HOWEVER - there may well be exceptions to this brought on by distribution 
usage etc. For example, if some distribution ends up basing it's work on 
(say) 2.6.8.1, and we later find a bug, we might release a 2.6.8.2 even 
though we might have done a 2.6.9 or even 2.6.10 later - just as a way to 
support the existing users who take a long time to update.

I consider that a pretty remote possibility, though. It's a lot more 
likely that the distribution-maker itself just does it's own patch on top 
of whatever release he started off with.

		Linus

Re: Linux 2.6.9-rc1

[Martin J. Bligh]

>>					 Linus, is there a chance that 
>> there will be a x.y.z.W release of an old kernel after the next x.y.Z.w 
>> has been released and no longer is -rc? For example releasing a 2.6.8.2 
>> after 2.6.9 has been released and no longer is a 2.6.9-rcX.
> 
> I don't see the point of such a release, so I'd say "no". Once we have a 
> stable kernel, we make updates to _that_ one, not older ones.
> 
> HOWEVER - there may well be exceptions to this brought on by distribution 
> usage etc. For example, if some distribution ends up basing it's work on 
> (say) 2.6.8.1, and we later find a bug, we might release a 2.6.8.2 even 
> though we might have done a 2.6.9 or even 2.6.10 later - just as a way to 
> support the existing users who take a long time to update.
> 
> I consider that a pretty remote possibility, though. It's a lot more 
> likely that the distribution-maker itself just does it's own patch on top 
> of whatever release he started off with.

My assumption would be that once 2.6.9 is released, it's not uber-stable
immediately ... so it'd be nice to keep at least one minor rev back
going on the bugfix stream (eg 2.6.8.X) .... for people who want an 
uber-stable kernel. Doing more than 1 back would indeed seem 
counter-productive.

That said it's unlikely there would still be urgent fixes for 2.6.8 a few
weeks after it was released, but it seems like the right thing to do, at
least in principle (maybe for a security fix, or something).

M.

Re: Linux 2.6.9-rc1

[Roman Zippel]

Hi,

On Wed, 25 Aug 2004, Martin J. Bligh wrote:

> My assumption would be that once 2.6.9 is released, it's not uber-stable
> immediately ... so it'd be nice to keep at least one minor rev back
> going on the bugfix stream (eg 2.6.8.X) .... for people who want an 
> uber-stable kernel. Doing more than 1 back would indeed seem 
> counter-productive.

In this case it would make more sense to get 2.6.9.1 released as quickly 
as possible instead of trying to fix old releases.
An important aspect to keep in mind is that 2.6.8.1 is an official release 
and people (which not necessarily read lkml and don't complain yet) expect 
being able to upgrade from one release to the next by applying a single 
incremental patch. Making an official patch release against some earlier 
release will certainly cause confusion.

bye, Roman

Re: Linux 2.6.9-rc1

[Denis Vlasenko]

> > My assumption would be that once 2.6.9 is released, it's not uber-stable
> > immediately ... so it'd be nice to keep at least one minor rev back
> > going on the bugfix stream (eg 2.6.8.X) .... for people who want an
> > uber-stable kernel. Doing more than 1 back would indeed seem
> > counter-productive.
>
> In this case it would make more sense to get 2.6.9.1 released as quickly
> as possible instead of trying to fix old releases.

Think about a user who can't risk moving to 2.6.9.1.
[S]he wants to use 2.6.8.n+1 which have only one more fix.
-- 
vda

Re: Linux 2.6.9-rc1

[Geert Uytterhoeven]

On Thu, 26 Aug 2004, Denis Vlasenko wrote:
> > > My assumption would be that once 2.6.9 is released, it's not uber-stable
> > > immediately ... so it'd be nice to keep at least one minor rev back
> > > going on the bugfix stream (eg 2.6.8.X) .... for people who want an
> > > uber-stable kernel. Doing more than 1 back would indeed seem
> > > counter-productive.
> >
> > In this case it would make more sense to get 2.6.9.1 released as quickly
> > as possible instead of trying to fix old releases.
>
> Think about a user who can't risk moving to 2.6.9.1.
> [S]he wants to use 2.6.8.n+1 which have only one more fix.

Then that user can apply the single fix for the problem he's interested in.
People are doing that with whatever old (= not the latest) kernel they're
running right now.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Linux 2.6.9-rc1

[Horst von Brand]

Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> said:

[...]

> Think about a user who can't risk moving to 2.6.9.1.
> [S]he wants to use 2.6.8.n+1 which have only one more fix.

They get a distribution kernel, which presumably has survived extensive
beating.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Linux 2.6.9-rc1

[Denis Vlasenko]

On Friday 27 August 2004 15:45, Horst von Brand wrote:
> Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> said:
>
> [...]
>
> > Think about a user who can't risk moving to 2.6.9.1.
> > [S]he wants to use 2.6.8.n+1 which have only one more fix.
>
> They get a distribution kernel, which presumably has survived extensive
> beating.

"Train goes from A to B..."
"But, teacher, why does it go to B?"

I said that some person may use 2.6.8.n in a critical application
and dare not change *anything* except that one known good bugfix.

Are you trying to say that such person cannot possibly exist?
--
vda

Re: Linux 2.6.9-rc1

[Bill Davidsen]

Sartorelli, Kevin wrote:
> Daniel Andersen wrote:
> 
>>As Linus initially said, there is the possibility of releasing 
>>a bug-fix patch 2.6.8.2 *after* 2.6.9 has been released.
> 
> 
> So, in this case, which would be considered the latest stable kernel to be used in production?  I can see this getting to a stage where you just pick and hope :-(

Do you have some other way to get a kernel now? Do you go to a new 
kernel right after it's released? Not to mention the question of which 
patches do you apply as they come out? I like np, but I have used ck and 
mm (and heavily used aa and ac when they were available).

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Linux 2.6.9-rc1

[David Mansfield]

I think the point is that the rc releases make all the difference.  Linus
is deciding what kernel to base the first rc against.  So:

2.6.9-rc1 has to be based on something, either 2.6.8 or 2.6.8.1 in this 
case.  

Whatever 2.6.9-rc1 is based on is what 2.6.9 will need to be based on
(I think).

And since, certainly, 2.6.8.2 may come out *after* 2.6.9-rc1, but *before*
2.6.9 final, it seems that 2.6.9-rc1 must be based on 2.6.8 to
prevent some weird 'shifting sands' type issues where no-one would know
what kernel to base their rc and final against.

My 2cents.


David