Linux 2.6.32-rc3

Linux 2.6.32-rc3

[Linus Torvalds]

Yes, it's really -rc3, because I'm skipping -rc2 entirely.

Or not "entirely". As too many people pointed out, I had been somewhat 
less than careful, and the 2.6.32-rc1 release actually called itself -rc2 
in the Makefile. As a result, I don't want to make a 2.6.32-rc2 release, 
since any bug-reports etc would then be met with the inevitable confusion: 
do you mean -rc2 as in the Makefile (ie really -rc1) or -rc2 as in the 
tagged release.

So I'm avoiding that confusion entirely, and consider the -rc1 release to 
have also been -rc2, and thus a week later we're now at -rc3. And let's 
hope that I won't have that particular "senior moment" any more. Although 
I'm sure I can screw up releases some other way.

Anyway. On to the actual changes.  It's actually been fairly calm, 
although I'm not sure exactly why. Regardless, I'm not going to complain, 
or look the gift horse in the mouth. The shortlog is appended (quite 
often, the -rc2 shortlogs are still big enough that I skip them).

The biggest change in the diff is the e1000 network driver update, but the 
bulk of that is actually just whitespace changes thanks to running it 
through lindent along with dropping dead PCIe code (the PCIe support is in 
the e1000e driver).

Apart from that single driver update (which is almost 60% of the diffs), 
there's a fair number of one-liners, but also some DRM updates (mainly the 
experimental radeon driver but also a capability to specify modes etc), 
some pcmcia and serial updates, ext4 and btrfs, etc. With a smattering of 
ACPI, sound and network code to fill in the cracks.

The appended shortlog probably gives a reasonable view into it, but one 
thing that might be worth mention (despite being fairly small) is that 
there's been some IO latency tweaking in the block layer (CFS scheduler). 
I'm hoping that ends up being one of those noticeable things, where people 
might actually notice better responsiveness. Give it a try.

		Linus

---
Aaro Koskinen (1):
      iop3xx: ATU and PCI memory configuration corrected

Adam Jackson (4):
      drm/edid: const cleanup
      drm/edid: Ignore bad standard timings.
      drm/edid: Detailed standard timing blocks have six timings, not five.
      drm/edid: Fix standard timing parse for EDID <= 1.2

Ajay Kumar Gupta (1):
      omap: Add missing mux pin for EHCI phy reset line

Ajit Khaparde (1):
      be2net: Workaround to fix a bug in Rx Completion processing.

Alan Jenkins (3):
      sony-laptop: Don't unregister the SPIC driver if it wasn't registered
      sony-laptop: check for rfkill hard block at load time
      sony-laptop: re-read the rfkill state when resuming from suspend

Albert Herranz (1):
      sdio: pass whitelisted cis funce tuples to sdio drivers

Alex Chiang (1):
      ACPI: dock: fix "sibiling" typo

Alex Deucher (5):
      drm/radeon/kms/r600: clamp vram to aperture size
      drm/radeon/kms: fix some bugs in vline reloc
      drm/radeon/kms/r600: add support for vline relocs
      drm/radeon/kms/r600: fix forcing pci mode on agp cards
      drm/radeon/r600: fix offset handling in CS parser

Alexander Beregalov (1):
      cciss: fix build when !PROC_FS

Alexey Dobriyan (4):
      cpqarray: switch to seq_file
      dac960: switch to seq_file
      const: constify remaining file_operations
      headers: remove sched.h from poll.h

Alexey Starikovskiy (3):
      ACPI: EC: Restart command even if no interrupts from EC
      ACPI: EC: Rewrite DMI checks
      ACPI: EC: Don't parse DSDT for EC early init on Compal

Amerigo Wang (1):
      drm: create gitignore file for radeon

Andrew Morton (3):
      net/ipv4/tcp.c: fix min() type mismatch warning
      drivers/input/input.c: fix CONFIG_PM=n warning
      revert "m68k: convert to asm-generic/hardirq.h"

Andrew Patterson (3):
      cciss: Remove sysfs entries for logical drives on driver cleanup.
      cciss: Use one scan thread per controller and fix hang during rmmod
      cciss: Allow triggering of rescan of logical drive topology via sysfs entry

Andy Spencer (1):
      sscanf(): fix %*s%n

Angelo Arrifano (2):
      omap: Fix wrong jtag_id for 850
      omap: Fix a OMAP_MPUIO_VBASE typo for 850

Anton Vorontsov (1):
      3c59x: Rework suspend and resume

Arjan van de Ven (5):
      net: Add explicit bound checks in net/socket.c
      wext: Add bound checks for copy_from_user
      x86: Provide an alternative() based cmpxchg64()
      ACPI: Fix bound checks for copy_from_user in the acpi /proc code
      SFI: remove __init from sfi_verify_table

Atis Elsts (1):
      net: Use sk_mark for routing lookup in more places

Atsushi Nemoto (1):
      serial_txx9: use container_of() instead of direct cast

Barry Song (1):
      ASoC: fix kconfig order of Blackfin drivers

Ben Dooks (11):
      s3cmci: use resource_size() instead of local macro
      s3cmci: update probe to use new platform id list
      s3cmci: change GPIO to gpiolib from S3C24XX specific calls
      s3cmci: change to use dev_pm_ops
      s3cmci: fix direct write to interrupt mask
      s3cmci: add debugfs support for examining driver and hardware state
      s3cmci: add SDIO IRQ support
      s3cmci: Kconfig selection for PIO/DMA/Both
      s3cmci: DMA fixes
      s3cmci: make SDIO IRQ hardware IRQ support build-time configurable
      s3cmci: add better support for no card detect or write protect available

Ben Greear (1):
      ixgbe patch to provide NIC's tx/rx counters via ethtool

Bjorn Helgaas (1):
      ACPI: fix bus scanning memory leaks

Breno Leitao (1):
      icom: convert space to tabs

Chaithrika U S (1):
      ASoC: DaVinci: Correct McASP FIFO initialization

Choi, David (1):
      drivers/net: ks8851_mll ethernet network driver

Chris Ball (2):
      Btrfs: Fix setting umask when POSIX ACLs are not enabled
      Btrfs: Use CONFIG_BTRFS_POSIX_ACL to enable ACL code

Chris Mason (1):
      Btrfs: take i_mutex before generic_write_checks

Christian Lamparter (1):
      ar9170: fix bug in iq-auto calibration value calculation

Christoph Hellwig (5):
      Btrfs: fix arguments to btrfs_wait_on_page_writeback_range
      Btrfs: remove duplicates of filemap_ helpers
      block: use normal I/O path for discard requests
      block: allow large discard requests
      afs: remove cache.h

Chuck Ebbert (1):
      serial: add parameter to force skipping the test for the TXEN bug

Cliff Cai (1):
      ASoC: Blackfin: fix inverted handling of SPORT0 on PORT F/G

Curt Wohlgemuth (3):
      ext4: Make sure ext4_dirty_inode() updates the inode in no journal mode
      ext4: Handle nested ext4_journal_start/stop calls without a journal
      ext4: Fix build warning in ext4_dirty_inode()

Dan Williams (2):
      iop33x: update defconfig (default atu to on)
      iop: downgrade maintenance status

Daniel T Chen (3):
      ALSA: hda - Add HP Pavilion dv4t-1300 to MSI whitelist
      ALSA: intel8x0 - Mute External Amplifier by default for Sony VAIO VGN-T350P
      ALSA: intel8x0 - Mute External Amplifier by default for Sony VAIO VGN-B1VP

Dave Airlie (11):
      drm/radeon/kms: enable r600 tv outputs.
      drm/radeon/kms: enable dac load detection by default.
      drm/radeon/kms: don't require up to 64k allocations. (v2)
      fb: change rules for global rules match.
      drm/kms: start adding command line interface using fb.
      drm/radeon/kms: remove unneeded master create/destroy functions.
      drm/r600: get values from the passed in IB not the copy.
      drm/kms: protect against fb helper not being created.
      drm/radeon/kms: fix for the extra pages copying.
      drm/kms: make fb helper work for all drivers.
      drm/r600: fix memory leak introduced with 64k malloc avoidance fix.

David Brown (1):
      ARM: 5739/1: ARM: allow empty ATAG_CORE

David S. Miller (1):
      net: Make setsockopt() optlen be unsigned.

Dmitry Artamonow (1):
      ARM: 5734/1: arm: fix compilation of entry-common.S for older CPUs

Don Skidmore (1):
      e1000: cleanup unused prototype

Eric Dumazet (6):
      sched_clock: Fix atomicity/continuity bug by using cmpxchg64()
      net: Fix sock_wfree() race
      net: restore tx timestamping for accelerated vlans
      pktgen: Fix delay handling
      tg3: Remove prev_vlan_tag from struct tx_ring_info
      net: splice() from tcp to pipe should take into account O_NONBLOCK

Eric Sandeen (2):
      ext4: drop ext4dev compat
      ext4: retry failed direct IO allocations

Frank Mayhar (1):
      ext4: Avoid updating the inode table bh twice in no journal mode

Frans Pop (1):
      e1000e/igb/ixgbe: Don't report an error if devices don't support AER

Giuliano Pochini (1):
      ALSA: echoaudio - Re-enable the line-out control for the Mia card

Greg Ungerer (1):
      ARM: 5740/1: fix valid_phys_addr_range() range check

H Hartley Sweeten (1):
      fs/bio.c: move EXPORT* macros to line after function

Hartley Sweeten (1):
      ARM: 5735/1: sa1111: CodingStyle cleanups

Hirokazu Takata (5):
      m32r: fix tme_handler
      m32r: export delay loop symbols
      m32r: define ioread* and iowrite* macros
      m32r: add rtc_lock variable
      m32r: Fix set_memory() for DISCONTIGMEM

Hiroshi DOYU (3):
      omap: mailbox: Execute softreset at startup
      omap: mailbox: Flush posted write when acking mailbox irq
      omap: Fix wrong condition check in while loop for mailbox and iommu2

Huang Shijie (1):
      mm/rmap.c: fix comment

Huang Weiyi (2):
      MIPS: BCM63xx: Remove duplicated #include
      MIPS: Remove duplicated #include

Igor Perminov (1):
      mac80211: Fix [re]association power saving issue on AP side

Jan Kara (1):
      ext4: Update documentation about quota mount options

Jarek Poplawski (1):
      ax25: Fix possible oops in ax25_make_new

Jarkko Nikula (1):
      omap: Fix MMC gpio_wp for BeagleBoard C2 and above

Jaswinder Singh Rajput (2):
      ARM: Remove unused CONFIG SA1100_H3XXX
      ARM: includecheck fix: mach-davinci, board-dm365-evm.c

Jean Delvare (12):
      sound: Make keywest_driver static
      net: Fix wrong sizeof
      i2c: Move misc devices documentation
      max6875: Discard obsolete detect method
      ds2482: Discard obsolete detect method
      ltc4215/ltc4245: Discard obsolete detect methods
      leds: leds-pca9532 - Drop unused module parameters
      Staging: IIO: tsl2561: Drop unused module parameters
      mfd: AB3100 drop unused module parameters
      i2c: Minor documentation update
      i2c: Hide probe errors caused by ACPI resource conflicts
      macintosh: Don't assume i2c device probing always succeeds

Jeff Hansen (1):
      bridge: Fix double-free in br_add_if.

Jens Axboe (7):
      cciss: cciss_host_attr_groups should be const
      cfq-iosched: add a knob for desktop interactiveness
      cfq-iosched: implement slower async initiate and queue ramp up
      cfq-iosched: rename 'desktop' sysfs entry to 'low_latency'
      cfq-iosched: use assigned slice sync value, not default
      cfq-iosched: don't delay async queue if it hasn't dispatched at all
      Revert "Seperate read and write statistics of in_flight requests"

Jerome Glisse (2):
      drm/radeon/kms: Convert RV515 to new init path and associated cleanup
      drm/radeon/kms: Convert R520 to new init path and associated cleanup

Jesse Brandeburg (12):
      e1000: drop dead pcie code from e1000
      e1000: remove unused functions
      e1000: use netif_tx_disable
      e1000: stop timers at appropriate times
      e1000: test link state conclusively
      e1000: fix tx waking queue after queue stopped during shutdown
      e1000: two workarounds were incomplete, fix them
      e1000: remove races when changing mtu
      e1000: drop redunant line of code, cleanup
      e1000: updated whitespace and comments
      e1000: drop unused functionality for eeprom write/read
      e1000: fix namespacecheck warnings

Jiri Pirko (2):
      ixgbe: correct the parameter description
      bonding: set primary param via sysfs

Jiri Slaby (1):
      Char: vt_ioctl, fix BKL imbalance

Joe Perches (1):
      MAINTAINERS: ARM/Palm file patterns

Johannes Berg (5):
      cfg80211: wext: don't display BSSID unless associated
      cfg80211: don't set privacy w/o key
      cfg80211: always get BSS
      mac80211: improve/fix mlme messages
      wext: add back wireless/ dir in sysfs for cfg80211 interfaces

John Fastabend (3):
      net: fix vlan_get_size to include vlan_flags size
      net: fix nlmsg len size for skb when error bit is set.
      net: fix double skb free in dcbnl

Josef Bacik (2):
      Btrfs: proper -ENOSPC handling
      Btrfs: fix data space leak fix

Josh Stone (1):
      ext4: Add a stub for mpage_da_data in the trace header

Jouni Malinen (1):
      mac80211_hwsim: Fix initial beacon timer configuration

Juha Leppanen (1):
      atm: dereference of he_dev->rbps_virt in he_init_group()

Julia Lawall (3):
      arch/arm/plat-iop: Use DIV_ROUND_CLOSEST
      Btrfs: introduce missing kfree
      MIPS: SMTC: Remove duplicate structure field initialization

Jun'ichi Nomura (1):
      Add a tracepoint for block request remapping

KAMEZAWA Hiroyuki (4):
      memcg: fix refcnt going negative
      cgroup: catch bad css refcnt at css_put
      memcg: some modification to softlimit under hierarchical memory reclaim.
      memcg: reduce check for softlimit excess

Kevin Cernekee (1):
      MIPS: MIPSxx SC: Avoid destructive invalidation on partial L2 cachelines.

Kirill A. Shutemov (2):
      ARM: 5727/1: Pass IFSR register to do_PrefetchAbort()
      ARM: 5728/1: Proper prefetch abort handling on ARMv6 and ARMv7

Len Brown (1):
      acpi_pad: build only on X86

Leo Chen (2):
      ARM: 5732/1: remove redundant include file
      ARM: 5733/1: fix bcmring compile error

Linus Torvalds (4):
      Revert "x86, mce: do not compile mcelog message on AMD"
      pty: reconnect the BSD TIOCSPTLCK handling to legacy ptys
      tty: Avoid dropping ldisc_mutex over hangup tty re-initialization
      Linux 2.6.32-rc3

Linus Walleij (2):
      ARM: 5731/2: Fix U300 generic GPIO, remove ifdefs from MMCI v3
      ARM: 5738/1: Correct TCM documentation

Lukasz Marcinowski (1):
      ALSA: hda - CD-audio sound for hda-intel conexant benq laptop

Manoj Iyer (1):
      ALSA: hda - Added quirk to enable sound on Toshiba NB200

Mark Mason (1):
      MIPS: Sibyte: Fix compilation error.

Mark Salter (1):
      mn10300: fix kernel build failures when using gcc-4.x

Martin K. Petersen (3):
      block: Set max_sectors correctly for stacking devices
      block: Do not clamp max_hw_sectors for stacking devices
      block: Topology ioctls

Mattia Dongili (3):
      sony-laptop: remove device_ctrl and the SPIC mini drivers
      sony-laptop: SPIC unset IRQF_SHARED, set IRQF_DISABLED
      sony-laptop: remove _INI call at init time

Maxime Bizon (2):
      MIPS: BCM63xx: Add serial driver for bcm63xx integrated UART.
      MIPS: BCM63xx: Add PCMCIA & Cardbus support.

Michael Buesch (1):
      b43: Always use block-I/O for the PIO data registers

Michael Chan (1):
      cnic: Fix NETDEV_UP event processing.

Michal Schmidt (1):
      skge: use unique IRQ name

Michal Szalata (1):
      rt2x00: Thrustmaster FunAccess WIFI USB and rt73usb

Miguel de Barros (1):
      ALSA: hda - Analog Devices AD1984A add HP Touchsmart model

Mikael Pettersson (2):
      drm: fix drm_fb_helper warning when !CONFIG_MAGIC_SYSRQ
      drm: fix radeon DRM warnings when !CONFIG_DEBUG_FS

Mike Frysinger (1):
      asm-generic/gpio.h: pull in linux/kernel.h for might_sleep()

Mike McCormack (1):
      skge: Make sure both ports initialize correctly

Mingming Cao (4):
      ext4: release reserved quota when block reservation for delalloc retry
      ext4: Split uninitialized extents for direct I/O
      ext4: Use end_io callback to avoid direct I/O fallback to buffered I/O
      ext4: async direct IO for holes and fallocate support

OGAWA Hirofumi (2):
      fat/nls: Fix handling of utf8 invalid char
      fat: Check s_dirt in fat_sync_fs()

Ori Finkelman (1):
      IPv4 TCP fails to send window scale option when window scale is zero

Paul Mundt (1):
      module: fix up CONFIG_KALLSYMS=n build.

Paul Wise (1):
      vfat: change the default from shortname=lower to shortname=mixed

Peter P Waskiewicz Jr (4):
      ixgbe: Fix disabling of relaxed ordering with Tx DCA
      ixgbe: Fix backplane flow control autoneg
      ixgbe: Bump driver version number
      ixgbe: Remove ATR computation for UDP traffic

Philipp Reisner (8):
      connector: Keep the skb in cn_callback_data
      connector: Provide the sender's credentials to the callback
      connector/dm: Fixed a compilation warning
      connector: Removed the destruct_data callback since it is always kfree_skb()
      dm/connector: Only process connector packages from privileged processes
      dst/connector: Disallow unpliviged users to configure dst
      pohmelfs/connector: Disallow unpliviged users to configure pohmelfs
      uvesafb/connector: Disallow unpliviged users to send netlink packets

Rafael J. Wysocki (2):
      PM / PCMCIA: Drop second argument of pcmcia_socket_dev_suspend()
      PM / yenta: Fix cardbus suspend/resume regression

Rakib Mullick (1):
      SFI: fix section mismatch warnings in sfi_core.c

Ralf Baechle (11):
      ax25: Add missing dev_put in ax25_setsockopt
      MIPS: BCM1480: Re-apply patch lost due to bad resolution of merge conflict.
      MIPS: SMP: Fix build.
      MIPS: SMP: Inline arch_send_call_function_{single_ipi,ipi_mask}
      MIPS: Sibyte: Get rid of BKL.
      MIPS: Excite: Get rid of BKL.
      MIPS: VPE: Fix build after the credential changes a while ago.
      MIPS: VPE: Get rid of BKL.
      MIPS: Avoid spurious make includecheck message
      NET: mkiss: Fix typo
      Kconfig: STRIP: Remove stale bits of STRIP help text

Randy Dunlap (3):
      isdn: fix netjet/isdnhdlc build errors
      cciss: fix schedule_timeout() parameters
      docs: update patch size in SubmittingPatches

Reinette Chatre (3):
      iwlwifi: fix debugfs buffer handling
      iwlwifi: fix memory leak in command queue handling
      iwlwifi: fix 3945 ucode info retrieval after failure

Richard Röjfors (1):
      uartlite: allow building for timberdale MFD

Roel Kluin (4):
      MIPS: Decrease size of au1xxx_dbdma_pm_regs[][]
      MIPS: MSP71xx: request_irq() failure ignored in msp_pcibios_config_access()
      cyclades: fix read buffer overflow
      serial167: fix read buffer overflow

Roland Dreier (1):
      ACPI: kill overly verbose "throttling states" log messages

Ron Mercer (5):
      qlge: Fix bad bit definitions.
      qlge: Fix out of sync hardware semaphore.
      qlge: Fix spin_lock warning.
      qlge: Protect reset recovery with rtnl_lock().
      qlge: Fix error exit for probe call.

Russell King (9):
      ARM: Fix section mismatch warning in Integrator pci_v3
      ARM: Fix SA1100 Assabet/Neponset PCMCIA section mismatch warnings
      ARM: Fix SA1100 Neponset serial section mismatch
      ARM: Fix SA11x0 clocksource warning
      ARM: Fix warning: #warning syscall migrate_pages not implemented
      ARM: Fix warning: unused variable 'highmem'
      ARM: Don't allow highmem on SMP platforms without h/w TLB ops broadcast
      ARM: Fix __cpuexit section mismatch warnings
      ARM: Ensure do_cache_op takes mmap_sem

Ryusuke Konishi (2):
      nilfs2: fix missing zero-fill initialization of btree node cache
      nilfs2: fix missing initialization of i_dir_start_lookup member

Rémi Denis-Courmont (1):
      Phonet: fix mutex imbalance

Sage Weil (2):
      Btrfs: fix error cases for ioctl transactions
      Btrfs: fix deadlock with free space handling and user transactions

Samuel Thibault (1):
      x86: fix csum_ipv6_magic asm memory clobber

Sanjeev Premi (1):
      omap: iovmm: Fix compiler warning

Sascha Hauer (3):
      spi-imx: update state correctly
      spi-imx: fix initial chipselect settings
      spi-imx: setup mode_bits we can handle

Sascha Hlusiak (2):
      Revert "sit: stateless autoconf for isatap"
      sit: fix off-by-one in ipip6_tunnel_get_prl

Shaohua Li (1):
      ACPI: create Processor Aggregator Device driver

Stephen Hemminger (1):
      sky2: irqname based on pci address

Stephen M. Cameron (17):
      cciss: Remove some unused code in rebuild_lun_table()
      cciss: Dynamically allocate struct device for each logical drive as needed.
      cciss: Rearrange logical drive sysfs code to make the "changing a disk" path work.
      cciss: Handle failure of blk_init_queue gracefully in cciss_add_disk.
      cciss: Handle cases when cciss_add_disk fails.
      cciss: Handle special case for sysfs attributes of the first logical drive.
      cciss: Clear all sysfs-exposed data for deleted logical drives.
      cciss: Fix usage_count check in rebuild_lun_table when triggered via sysfs.
      cciss: Fix excessive gendisk freeing bug on driver unload.
      cciss: Silence noisy per-disk messages output by cciss_read_capacity
      cciss: Preserve all 8 bytes of LUN ID for logical drives.
      cciss: Don't check h->busy_initializing in cciss_open().
      cciss: Add lunid attribute to each logical drive in /sys
      cciss: fix some magic numbers in the raid-level decoding
      cciss: Add a "raid_level" attribute to each logical drive in /sys
      cciss: Add usage_count attribute to each logical drive in /sys
      cciss: Dynamically allocate the drive_info_struct for each logical drive.

Suresh Jayaraman (1):
      swapfile: avoid NULL pointer dereference in swapon when s_bdev is NULL

Sven Eckelmann (1):
      ALSA: ctxfi: Swapped SURROUND-SIDE mute

Takashi Iwai (7):
      ALSA: hda - Resurrect input-source mixer of ALC268 model=acer
      ALSA: Don't assume i2c device probing always succeeds
      ASoC: Fix dependency of CONFIG_SND_PXA2XX_SOC_IMOTE2
      ALSA: hda - Fix digita/analog mic auto-switching with IDT codecs
      ALSA: hda - Fix / improve ALC66x parser
      ALSA: Fix invalid __exit in sound/mips/*.c
      ALSA: usb - Use strlcat() correctly

Tejun Heo (6):
      percpu: fix unit_map[] verification in pcpu_setup_first_chunk()
      percpu: make pcpu_build_alloc_info() clear static buffers
      sparc64: implement page mapping percpu first chunk allocator
      percpu: make embedding first chunk allocator check vmalloc space size
      percpu: make pcpu_setup_first_chunk() failures more verbose
      percpu: make allocation failures more verbose

Theodore Ts'o (9):
      ext4: Use ext4_msg() for ext4_da_writepage() errors
      ext4: Fix hueristic which avoids group preallocation for closed files
      ext4: Adjust ext4_da_writepages() to write out larger contiguous chunks
      ext4: EXT4_IOC_MOVE_EXT: Check for different original and donor inodes first
      ext4, jbd2: Drop unneeded printks at mount and unmount time
      ext4: Use tracepoints for mb_history trace file
      jbd2: Use tracepoints for history file
      ext4: Fix time encoding with extra epoch bits
      ext4: fix a BUG_ON crash by checking that page has buffers attached to it

Tobias Klauser (1):
      omap: rng: Use resource_size instead of manual calculation

Tony Lindgren (4):
      omap: Fix compile for arch/arm/mach-omap2
      omap: Fix mcspi compile for 2420
      omap: Fix 44xx compile
      omap: Fix matrix_keymap_data usage

Toshihiro HANAWA (1):
      m32r: Fix IPI function calls for SMP

Troy Kisky (2):
      ASoC: DaVinci: Fix divide by zero error during 1st execution
      ASoC: Davinci: Fix race with cpu_dai->dma_data

Uwe Kleine-König (8):
      MIPS: Loongson2: Fix typo "enalbe" -> "enable"
      don't use __devexit_p to wrap meth_remove
      don't use __devexit_p to wrap sgiseeq_remove
      move virtnet_remove to .devexit.text
      spi-imx: rename source file to spi_imx.c
      spi-imx: no need to assert bits_per_word being initialized
      spi-imx: initialize complete config struct
      spi-imx: strip down chipselect function to only drive the chipselect

Vivek Goyal (1):
      cfq-iosched: delay async IO dispatch, if sync IO was just done

Zdenek Kabelac (1):
      Add missing blk_trace_remove_sysfs to be in pair with blk_trace_init_sysfs

roel kluin (1):
      bcm63xx_enet: timeout off by one in do_mdio_op()

Re: Linux 2.6.32-rc3

[James Cloos]

I wrote earlier, in a reply on the Poor desktop responsiveness with
background I/O-operations thread, that sometime between .30-rc6 and
the .31 tag all of the recent improvements in perceived performance
has been lost.

I'm happy to report that as of the cmpexch64 fix, that regression
is gone.  Performance under load -- and particularly with significant
paging -- shows a vast improvement (on my aging, 32-bit laptop).

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Linux 2.6.32-rc3

[Len Brown]

> do you mean -rc2 as in the Makefile (ie really -rc1) or -rc2 as in the 
> tagged release.

We have a similar problem with the period between, say, 2.6.X and 
2.6.Y-rc1.  The Makefile still says 2.6.X, yet during the 2.6.Y
merge window the tree is very different from 2.6.X.

This confuses things like my scripts that take a source tree tarball,
and (re)generate config files for build testing based on the tags
in the Makefile.  There is no way for the scripts to know the
post 2.6.X tree not the same as 2.6.X itself, the new configs
overwrite the old, overwrite the old results etc.

I think that BenH also had troubles with this issue and pointed
it out a while back, but you were not convinced at the time that
it was a problem worth solving.

This could be clarified if you update Makefile on the 1st commit
after 2.6.X is frozen to simply be 2.6.Y-merge or 2.6.Y-rc0
or something.  Anything but 2.6.X.

thanks,
-Len Brown, Intel Open Source Technolgy Center

Re: Linux 2.6.32-rc3

[Dirk Hohndel]

On Mon, 2009-10-05 at 21:57 -0400, Len Brown wrote:
> > do you mean -rc2 as in the Makefile (ie really -rc1) or -rc2 as in the 
> > tagged release.
> 
> We have a similar problem with the period between, say, 2.6.X and 
> 2.6.Y-rc1.  The Makefile still says 2.6.X, yet during the 2.6.Y
> merge window the tree is very different from 2.6.X.
> 
> This confuses things like my scripts that take a source tree tarball,
> and (re)generate config files for build testing based on the tags
> in the Makefile.  There is no way for the scripts to know the
> post 2.6.X tree not the same as 2.6.X itself, the new configs
> overwrite the old, overwrite the old results etc.
> 
> I think that BenH also had troubles with this issue and pointed
> it out a while back, but you were not convinced at the time that
> it was a problem worth solving.
> 
> This could be clarified if you update Makefile on the 1st commit
> after 2.6.X is frozen to simply be 2.6.Y-merge or 2.6.Y-rc0
> or something.  Anything but 2.6.X.

I have seen this request many times and it seems to make perfect sense.
The first commit applied after a release should change the version
number to "something" - and "2.6.next-rc0" sounds as good as anything
else that has been proposed so far.

/D
 
-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Mon, 5 Oct 2009, Dirk Hohndel wrote:
> On Mon, 2009-10-05 at 21:57 -0400, Len Brown wrote:
>
> > This could be clarified if you update Makefile on the 1st commit
> > after 2.6.X is frozen to simply be 2.6.Y-merge or 2.6.Y-rc0
> > or something.  Anything but 2.6.X.
> 
> I have seen this request many times and it seems to make perfect sense.

No. It makes perfect sense just because the people who think so don't 
think things through.

It doesn't help, for several reasons:

 - the step function of the Makefile change happens once per release, and 
   if you compile anything but releases, you can never rely on just the 
   revision. Was it a plain -rc, a plain release, or something in 
   between? You'll never know, just looking at the 2.6.x.y thing.

   In other words, you fundamentally have three choices:

    (a) be confused. Adding an "-rc0" won't help. You'll still be confused 
	in between releases about exactly what you're running.

    (b) use CONFIG_LOCALVERSION_AUTO=y

	Now, if 'uname -r' says 2.6.31, then you _know_ it's exactly 
	2.6.31 and nothing else. If it's a few commits after 2.6.31, it 
	will say something like '2.6.31-1-g752015d', and you know that 
	it's one commit after 2.6.31, and you'll know _which_ commit it is!

    (c) Don't compile anything but releases. 

   Those are the choices. 

 - An even _more_ fundamental reason: Linux development isn't linear. 
   There is not one "first commit" after a release, and there never will 
   be. Sure, there's a first commit that I do, but that has absolutely 
   zero relevance.

   Learn this. Until you do, you'll be confused, and you'll show your 
   confusion by saying "I want a 2.6.n+1-rc0". You'll _also_ show your 
   confusion by things like "I was bisecting a bug that happened between 
   2.6.30 and 2.6.31, and suddenly git was asking me to test a kernel that 
   said it was version 2.6.29-rc1 - so I stopped bisecting because git was 
   confused".

Who was confused? Was it git, or was it the person who thought that the 
Makefile version could be consistent in a non-linear world?

So no. I'm not going to do -rc0. Because doing that is _stupid_. And until 
you understand _why_ it's stupid, it's pointless talking about it, and 
when you _do_ understand that it's stupid, you'll agree with me.

			Linus

Re: Linux 2.6.32-rc3

[Dirk Hohndel]

On Tue, 2009-10-06 at 07:18 -0700, Linus Torvalds wrote:
> So no. I'm not going to do -rc0. Because doing that is _stupid_. And until 
> you understand _why_ it's stupid, it's pointless talking about it, and 
> when you _do_ understand that it's stupid, you'll agree with me.

I respectfully disagree.

With the proposed -rc0 there is EXACTLY ONE kernel that is called 2.6.31
- the release kernel. And everything else is called something
2.6.xx-rcY.

So we do get very useful information here - especially since the release
kernel is supposed to be reasonably stable whereas the things right
afterwards (during the merge window) are extremely likely to be
unstable.

So if you see something that identifies itself as -rc0, you know it's
from during the merge window. If you see something that calls itself
2.6.xx then you know it's a release kernel.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: Linux 2.6.32-rc3

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> So no. I'm not going to do -rc0. Because doing that is _stupid_. And 
> until you understand _why_ it's stupid, it's pointless talking about 
> it, and when you _do_ understand that it's stupid, you'll agree with 
> me.

I understand non-linear history, but still i think that it might make 
sense to make it more apparent that the tree people pull from you after 
.31 got released is a lot closer to what .32 is going to be than to .31. 
(which the name implies)

I.e. i think it's a fact that right now our release version is highly 
deceptive during the merge window. Two days into the merge window and we 
have more commits added than we add from .31-rc7 to .31-rc9 total. A 
week into the merge window we have .31 + 6000 commits merged and still 
call it v2.6.31, to the casual looker.

We can ignore that and say "hehe, you dont understand non-linear trees 
and ran git remote update blindly, too bad for you", or we might do 
something to make things more transparent and reduce the confusion. 
Personally i really want people to try our git trees, but them also be 
fully aware of the risks involved.

One option would be to make LOCALVERSION_AUTO compulsory.

Or to add a tweak to the naming, something like:

 v2.6.31
 v2.6.31+
 v2.6.32-rc1
 v2.6.32-rc1+
 ..
 v2.6.32-rc9
 v2.6.32-rc9+
 v2.6.32

Would make it clear what's going on, even in the simplified world of 
limited-size version numbers.

Or, IMHO it would also be a valid naming model to do this small tweak to 
the above naming scheme:

 v2.6.31
 v2.6.32-rc0
 v2.6.32-rc0+
 v2.6.32-rc1
 v2.6.32-rc1+
 ..
 v2.6.32-rc9
 v2.6.32-rc9+
 v2.6.32

... for the sole purpose of warning people that anything they pull after 
v2.6.31 got released is (wildly!) not vanilla v2.6.31 anymore. Not more, 
not less.

Am i confused? :-)

	Ingo

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Tue, 6 Oct 2009, Dirk Hohndel wrote:
> 
> I respectfully disagree.

.. because you don't know what the f*ck you're talking about.

> With the proposed -rc0 there is EXACTLY ONE kernel that is called 2.6.31
> - the release kernel. And everything else is called something
> 2.6.xx-rcY.

No.

That's simply not _true_.

Think it through. Deeply. 

In particular, think about all the developers who start out at known 
stable points. And they are _supposed_ to start at release points. It 
means that a lot of versions in the -rc window will NOT have that -rc0 in 
them.

In fact, even more commonly (for people who don't rebase, which should be 
the default), you'll have kernel versions in the merge window (and later) 
that will have Makefiles that talk about the previous release.

If you can't get that FUNDAMENTAL FACT, then I don't know what to say.

> So if you see something that identifies itself as -rc0, you know it's
> from during the merge window. If you see something that calls itself
> 2.6.xx then you know it's a release kernel.

No. No. And NO.

Your kind of magical thinking leads to _problems_. It's literally been a 
problem that people stop bisecting, because they notice that they start 
testing kernels that have a version number before the release they already 
tested as good. Exactly because of your kind of linear thinking.

We need _less_ linear thinking, not more. And you need to start thinking 
about other kernels than just my release tree.

		Linus

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Tue, 6 Oct 2009, Ingo Molnar wrote:
> 
> We can ignore that and say "hehe, you dont understand non-linear trees 
> and ran git remote update blindly, too bad for you", or we might do 
> something to make things more transparent and reduce the confusion. 

You are missing the point.

The only thing we can do is to teach people that the Makefile version 
isn't too important, and that it really doesn't tell very much.

Trying to tweak it to make it somehow "more meaningful" is a BAD THING, 
because it continues to spoon-feed people a lie. 

The cake is a lie. In between kernel versions, you can't rely on the 
Makefile.  You should teach yourself (and others) THAT, rather than trying 
to teach people to believe the lie even more.

Once you start believing the lie, suddenly all the subtrees will start 
thinking that now _their_ kernel versions are bad, so now they'll start to 
want to make the same idiotic changes to their Makefiles, or maybe 
they'll decide that they don't want to pull tagged releases, but the "one 
after the tag so that they'll get the updated Makefile".

And even if they don't do that idiocy, the whole "the version number is 
meaningful outside of releases" thing leads to brain damage. 

> One option would be to make LOCALVERSION_AUTO compulsory.

Yes, I could live with that. If you're compiling from a git tree, we migth 
as well show the real version.

It's the "let's make that meaningful and misleading number be even _more_ 
misleading by making people think it has meaning" magical thinking that I 
hate.

It's wrong, and it leads people to believe in things that aren't true. I 
refuse to cater to that kind of wrongheaded thinking.

I'd much rather screw up the version number entirely and add a _random_ 
number to it (so that the Makefile would say "2.6.18" after I have 
released 2.6.32) just so that people would be forced to _understand_ that 
the version number isn't as meaningful as you seem to think it is.

For example, let's take Arjan's request, that kerneloops should get -rc0.

Think about that for a few minutes. Really THINK about it. What happens?

[ Spend some time really thinking here. ]

What about people like all the networking guys who are running their 
development kernels that haven't been merged yet? Their kernels won't say 
-rc0. Are you going to ask them to do it too?

Or would you be better off teaching kerneloops about local versions?

		Linus

Re: Linux 2.6.32-rc3

[Stefan Richter]

Ingo Molnar wrote:
> I.e. i think it's a fact that right now our release version is highly 
> deceptive during the merge window.
[...]
> One option would be to make LOCALVERSION_AUTO compulsory.
> 
> Or to add a tweak to the naming, something like:
> 
>  v2.6.31
>  v2.6.31+
>  v2.6.32-rc1
>  v2.6.32-rc1+
[...]
> ... for the sole purpose of warning people that anything they pull after 
> v2.6.31 got released is (wildly!) not vanilla v2.6.31 anymore.

If this scheme is meant to be something on which people can rely on,
everybody who commits to a tree from which Linus pulls from would have
to base their branches onto those ...+ commits, always.
-- 
Stefan Richter
-=====-==--= =-=- --==-
http://arcgraph.de/sr/

Re: Linux 2.6.32-rc3

[Dirk Hohndel]

On Tue, 2009-10-06 at 08:13 -0700, Linus Torvalds wrote:
> 
> On Tue, 6 Oct 2009, Dirk Hohndel wrote:
> > 
> > I respectfully disagree.
> 
> .. because you don't know what the f*ck you're talking about.

Always a pleasure having an intellectual discourse with you.

> > With the proposed -rc0 there is EXACTLY ONE kernel that is called 2.6.31
> > - the release kernel. And everything else is called something
> > 2.6.xx-rcY.
> 
> No.
> 
> That's simply not _true_.
> 
> Think it through. Deeply. 
> 
> In particular, think about all the developers who start out at known 
> stable points. And they are _supposed_ to start at release points. It 
> means that a lot of versions in the -rc window will NOT have that -rc0 in 
> them.
> 
> In fact, even more commonly (for people who don't rebase, which should be 
> the default), you'll have kernel versions in the merge window (and later) 
> that will have Makefiles that talk about the previous release.
> 
> If you can't get that FUNDAMENTAL FACT, then I don't know what to say.

The fundamental difference in our analysis is that I believe that 1% of
the people using these kernels are developers as you describe above and
99% are people who pull from your tree and build and test.

> > So if you see something that identifies itself as -rc0, you know it's
> > from during the merge window. If you see something that calls itself
> > 2.6.xx then you know it's a release kernel.
> 
> No. No. And NO.

For people simply pulling from your git tree, I think the answer is YES.

> Your kind of magical thinking leads to _problems_. It's literally been a 
> problem that people stop bisecting, because they notice that they start 
> testing kernels that have a version number before the release they already 
> tested as good. Exactly because of your kind of linear thinking.

I think those two things are entirely unrelated. How would calling the
versions in the merge window -merge or -rc0 make any difference
whatsoever in whether people are confused by git bisect behavior?

> We need _less_ linear thinking, not more. And you need to start thinking 
> about other kernels than just my release tree.

I do - I actually track multiple trees and have my own in which I do my
own work.

That still doesn't change my believe that the VAST MAJORITY of the
people out there only track one tree. Yours.

But hey, as you have stated so eloquently, I "don't know what the f*ck
[I'm] talking about", so let's hear what others are thinking.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: Linux 2.6.32-rc3

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, 6 Oct 2009, Ingo Molnar wrote:
> > 
> > We can ignore that and say "hehe, you dont understand non-linear 
> > trees and ran git remote update blindly, too bad for you", or we 
> > might do something to make things more transparent and reduce the 
> > confusion.
> 
> You are missing the point.
> 
> The only thing we can do is to teach people that the Makefile version 
> isn't too important, and that it really doesn't tell very much.
> 
> Trying to tweak it to make it somehow "more meaningful" is a BAD 
> THING, because it continues to spoon-feed people a lie.
> 
> The cake is a lie. In between kernel versions, you can't rely on the 
> Makefile.  You should teach yourself (and others) THAT, rather than 
> trying to teach people to believe the lie even more.
> 
> Once you start believing the lie, suddenly all the subtrees will start 
> thinking that now _their_ kernel versions are bad, so now they'll 
> start to want to make the same idiotic changes to their Makefiles, or 
> maybe they'll decide that they don't want to pull tagged releases, but 
> the "one after the tag so that they'll get the updated Makefile".
> 
> And even if they don't do that idiocy, the whole "the version number 
> is meaningful outside of releases" thing leads to brain damage.

hm, i think you ignored (or missed, or found irrelevant) my first 
suggested variant:

 v2.6.31
 v2.6.31+
 v2.6.32-rc1
 v2.6.32-rc1+
 ..
 v2.6.32-rc9
 v2.6.32-rc9+
 v2.6.32

The '+' sign says that it's more than .31.

That defuses the 'lie' of trying to linerize a multi-thousand-node graph 
down into some catchy human-readable string pretty efficiently i think. 
It doesnt tell us precisely what that '+' means - it could be goodness 
or it could be badness.

_That_ i think is a lot harder to confuse with the real .31 than a 
v2.6.31-1234-g16123c4 version string.

My tweak #2, adding -rc0 indeed brings in problems, it's too artificial 
to do it right after .31 gets released - and if we dont do it then we 
cannot do it later either. (so we cannot really do it)

[ It might bring in some advantages too btw. A pull request to you for a 
  tree that is -rc0 based means it got rebased straight in the merge 
  window => bad. Such a thing would be apparent at a glance. 'Good' 
  trees should be based on some known good version of the previous 
  stable kernel cycle. ]

	Ingo

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Tue, 6 Oct 2009, Linus Torvalds wrote:
> 
> It's the "let's make that meaningful and misleading number be even _more_ 
                            ^^^^^^^^^^
> misleading by making people think it has meaning" magical thinking that I 
> hate.

That 'meaningful' was supposed to be a 'meaningless' of course.

The point really is that we have about 1 new version number per week, but 
at the same time we have an average of one _thousand_ commits merged per 
week. So at a glance, the Makefile version number doesn't mean very much.

But if the thousand commits we merged actually were nicely spread out in 
between those version numbers, it would all work really beautifully. Sure, 
the top-level version number would only give you a 1/1000 of the real 
commit information, but hey, that's kind of what you'd want, isn't it? So 
then the top-level Makefile version number would be meaningful and useful!

But that's not how it works. In fact, if we actually followed our own 
release rules ("merge window is for merging code that was written before 
the merge window even started"), no commits except for my merge commits 
should actually have that last release in their Makefile at all! 

Now, that's not actually true, because (a) people rebase and (b) even in 
the absense of rebases I do merge with people like Andrew by email, so we 
actually end up having statistics like these:

	git rev-list v2.6.31..v2.6.32-rc1 |
		while read a
		do
			git show $a:Makefile | grep SUBLEVEL.=
		done | sort | uniq -c

resulting in

     32 SUBLEVEL = 29
    383 SUBLEVEL = 30
   8795 SUBLEVEL = 31
      1 SUBLEVEL = 32

which is actually a bit sad in itself (showing just _how_ many people 
rebased their work on top of a release), but is still showing that we 
actually had 32 new commits in there that were based on a 2.6.29 kernel

And what people are suggesting with a 2.6.32-rc0 would just lead to people 
now rebasing their work NOT EVEN ON A RELEASE. They'd want to rebase it on 
top of that made-up commit (2.6.32-rc0), so now from a development 
standpoint that commit suddenly becomes more important than the release 
itself. 

Do you not see the insanity? We should have _less_ of this kind of 
thinking, not more. At least rebasing on top of a release sounds sane. Not 
this kind of "rebase on top of a magic Linus-commit" crap.

			Linus

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Tue, 6 Oct 2009, Dirk Hohndel wrote:
> 
> For people simply pulling from your git tree, I think the answer is YES.

If they only pull from my git tree, why do they even care?

And why don't you use LOCALVERSION_AUTO? Did you just not know about it?

			Linus

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Tue, 6 Oct 2009, Ingo Molnar wrote:
> 
> hm, i think you ignored (or missed, or found irrelevant) my first 
> suggested variant:

No, I didn't ignore it, it just showed that you didn't know what you were 
thinking about.

>  v2.6.31
>  v2.6.31+
> 
> The '+' sign says that it's more than .31.

No. It shows no such thing. Because it DOES NOT EXIST in other peoples 
trees until they rebase on top of mine.

Unless:

> _That_ i think is a lot harder to confuse with the real .31 than a 
> v2.6.31-1234-g16123c4 version string.

.. are you saying that it would be just some automatically generated 
thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a 
CONFIG_LOCALVERSION_AUTO_SHORTFORM?

If so, then I don't hate "v2.6.31+", but at the same time, that single 
plus-sign tells _so_much_ less than v2.6.31-1234-g16123c4 that I think 
it's really sad and crippled. 

Is it so hard to teach people what "v2.6.31-1234-g16123c4" means? It's not 
like it's very complicated, and it's not like it's not visually very 
distinct indeed from the tagged release case (which is just "v2.6.31").

I'd love to use "+" instead of "-", but I was thinking that there are 
various version things that get unhappy about special characters like 
that, so we've always used '-' as the separator (since we've always used 
it).

So I'm _entirely_ open to changing how 'CONFIG_LOCALVERSION_AUTO' works, 
or extending on that notion. 

What I'm _not_ open to doing is to add made-up commits that change the 
top-level Makefile at non-release points. Because that way really does lie 
insanity.

		Linus

Re: Linux 2.6.32-rc3

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Unless:
> 
> > _That_ i think is a lot harder to confuse with the real .31 than a 
> > v2.6.31-1234-g16123c4 version string.
> 
> .. are you saying that it would be just some automatically generated 
> thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a 
> CONFIG_LOCALVERSION_AUTO_SHORTFORM?

Yes, exactly. Not a Makefile or tag property, obviously.

> If so, then I don't hate "v2.6.31+", but at the same time, that single 
> plus-sign tells _so_much_ less than v2.6.31-1234-g16123c4 that I think 
> it's really sad and crippled.

Agreed, and in my internal testing i've made LOCALVERSION_AUTO 
compulsory long time ago.

But at least to me there's a simple benchmark: i have been confused by 
this. In one of the merge windows i thought i booted .31 vanilla while 
in fact it was a few days into the merge window already. Took me a few 
minutes to figure out why it was crashing ;-)

YMMV.

Maybe a variant of the full string:

  v2.6.31+1234-g16123c4

would be even less confusing. I tend to ignore dashes sub-consciously 
(as a 'minor versions' kind of thing) - while in this ~1 week out of the 
9 weeks of your tree's cycle it means something much more than that, and 
we dont emphasise the difference strongly enough.

But ... that's just my own experience. I also see -tip users become a 
lot more cautious for a few rc's once we go -rc1 - while they happily 
test things in the merge window (which is _way_ more dangerous than 
pretty much any post-rc1 tree you push out).

Basically IMHO the inflection point between v2.6.31 and the merge window 
is way too 'smooth', and not obviously so, and it lures people who are 
not careful enough into testing something they probably wouldnt test 
otherwise. It's a purely human thing - to a machine it's already very 
obvious what g16123c4 means - it doesnt need any of the fancy v2.6.31 
stuff either.

	Ingo

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Tue, 6 Oct 2009, Linus Torvalds wrote:
> 
> Unless:
> 
> > _That_ i think is a lot harder to confuse with the real .31 than a 
> > v2.6.31-1234-g16123c4 version string.
> 
> .. are you saying that it would be just some automatically generated 
> thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a 
> CONFIG_LOCALVERSION_AUTO_SHORTFORM?

So how about this?

It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial 
way:

 - if it is set, things work the way they always have, and you get a 
   extended kernel release like

	2.6.32-rc3-00052-g0eca52a-dirty

 - but if it is _not_ set, we'll still try to get a version from the 
   underlying SCM (we actually support git, hg and SVN right now, even if 
   some comments may say "git only"), and if the underlying SCM says it 
   has a local version, we append just "+", so you get a version number 
   like

	2.6.32-rc3+

IOW, you'd never get 2.6.32-rc0, but you'd get either the complex git 
version number (or SVN/hg/whatever), or at least "2.6.31+" with the "+" 
showing that it is more than plain 2.6.31.

The "+" could be anything else, of course. The diff is pretty obvious, you 
can argue about exactly _what_ you'd like to see as a suffix for "and then 
some".

		Linus

---
 Makefile |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index e50569a..c62b7cc 100644
--- a/Makefile
+++ b/Makefile
@@ -963,8 +963,6 @@ localver = $(subst $(space),, $(string) \
 # .scmversion is used when generating rpm packages so we do not loose
 # the version information from the SCM when we do the build of the kernel
 # from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
 ifeq ($(wildcard .scmversion),)
         _localver-auto = $(shell $(CONFIG_SHELL) \
                          $(srctree)/scripts/setlocalversion $(srctree))
@@ -972,7 +970,14 @@ else
         _localver-auto = $(shell cat .scmversion 2> /dev/null)
 endif
 
+ifdef CONFIG_LOCALVERSION_AUTO
 	localver-auto  = $(LOCALVERSION)$(_localver-auto)
+else
+	ifeq ($_localver-auto,)
+		localver-auto = $(LOCALVERSION)
+	else
+		localver-auto = $(LOCALVERSION)+
+	endif
 endif
 
 localver-full = $(localver)$(localver-auto)

Re: Linux 2.6.32-rc3

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> But at least to me there's a simple benchmark: i have been confused by 
> this. In one of the merge windows i thought i booted .31 vanilla while 
> in fact it was a few days into the merge window already. Took me a few 
> minutes to figure out why it was crashing ;-)

(Small correction: it wasnt .31 vanilla but .29 or so.)

	Ingo

Re: Linux 2.6.32-rc3

[Frans Pop]

Linus Torvalds wrote:
> Your kind of magical thinking leads to _problems_. It's literally been a
> problem that people stop bisecting, because they notice that they start
> testing kernels that have a version number before the release they
> already tested as good. Exactly because of your kind of linear thinking.

I do understand your point, but I'm not sure that it makes sense to take 
bisecting as the main criterium here. Bisection will always be confusing 
for users the first few times, whatever you put in the Makefile.

IMO it is more relevant that people who build and run pre-rc1 kernels get a 
clear distinction by default between their stable kernel and the (highly 
unstable) merge window one.
When a user compiles a kernel, the only thing that's relevant is what's in 
Makefile *at that time*, not where the branches that are merged in happen 
to originate.

Personally I always add a -rc0 in a local commit as soon as I pull any 
merge window changes (that commit gets dropped when you release -rc1).
Package versions are derived from git describe.

So I get (examples include local commits):
linux-image-2.6.31_31.g5e9d407_amd64.deb (.31 + 31 local changes)
linux-image-2.6.31.1_31.gb4adf51_amd64.deb
linux-image-2.6.32-rc0_7396-g02b51df_amd64.deb
linux-image-2.6.32-rc1_20.ge8343d5_amd64.deb
linux-image-2.6.32-rc1_154.gb157421_i386.deb
linux-image-2.6.32-rc3_18.g7e921a0_amd64.deb
linux-image-2.6.32-rc3_69.g7146bc5_amd64.deb

Of course this it makes no difference if you use 'make install', but for 
other cases I think having -rc0 in mainline first thing in the merge 
window would be useful. Especially for users who compile kernels from the 
git tarballs during the merge window (and are not aware of localversion).
Of course there are plenty of options to do whatever you want locally, but 
why not make it easy?


BTW, I've got a solution for bisection too: the versions in the Makefile 
get changed to something constant. And the package version is set equal to 
the bisection iteration. This ensures that I know exactly which kernels 
were build for the series and that I can always go back to a specific 
kernel if I need to retest for some reason.

E.g. (for a bisection covering .30-.31):
linux-image-2.6.31-bisect_1_amd64.deb
linux-image-2.6.31-bisect_2_amd64.deb
linux-image-2.6.31-bisect_3_amd64.deb
...

Cheers,
FJP

P.S. I use the deb-pkg target to build all my kernels. A wrapper script 
takes care of all the stuff mentioned above (and cross-compiling). For me 
the clean package management is worth the slight overhead.

Re: Linux 2.6.32-rc3

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, 6 Oct 2009, Linus Torvalds wrote:
> > 
> > Unless:
> > 
> > > _That_ i think is a lot harder to confuse with the real .31 than a 
> > > v2.6.31-1234-g16123c4 version string.
> > 
> > .. are you saying that it would be just some automatically generated 
> > thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a 
> > CONFIG_LOCALVERSION_AUTO_SHORTFORM?
> 
> So how about this?
> 
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial 
> way:
> 
>  - if it is set, things work the way they always have, and you get a 
>    extended kernel release like
> 
> 	2.6.32-rc3-00052-g0eca52a-dirty
> 
>  - but if it is _not_ set, we'll still try to get a version from the 
>    underlying SCM (we actually support git, hg and SVN right now, even if 
>    some comments may say "git only"), and if the underlying SCM says it 
>    has a local version, we append just "+", so you get a version number 
>    like
> 
> 	2.6.32-rc3+
> 
> IOW, you'd never get 2.6.32-rc0, but you'd get either the complex git 
> version number (or SVN/hg/whatever), or at least "2.6.31+" with the "+" 
> showing that it is more than plain 2.6.31.
> 
> The "+" could be anything else, of course. The diff is pretty obvious, 
> you can argue about exactly _what_ you'd like to see as a suffix for 
> "and then some".

Could we, for consistency's sake, make it:

 	2.6.32-rc3+00052-g0eca52a-dirty
 	2.6.32-rc3+

? Or do we want to keep the old version string alone for some reason?

The reason is that i have been confused in the past by having seen 
something like:

      2.6.29-00052-g0eca52a-dirty

and parsing out (in an admittedly weak moment) the gibberish after the 
first dash. Had it said:

      2.6.29+00052-g0eca52a-dirty

i'm sure i'd have noticed that it's not vanilla v2.6.29 - that plus sign 
stands out like a lightning rod.

	Ingo

Re: Linux 2.6.32-rc3

[Frans Pop]

Linus Torvalds wrote:

>> One option would be to make LOCALVERSION_AUTO compulsory.
> 
> Yes, I could live with that. If you're compiling from a git tree, we
> might as well show the real version.

Not sure I'd like that.Actually pretty sure I'd hate it.
It would completely break the clean mechanism I currently have (described 
in my previous post).

Enabling it by default somehow would be fine with me, but "compulsory" is a 
step to far IMO. Users should always be allowed custom schemes.

Cheers,
FJP

Re: Linux 2.6.32-rc3

[Ingo Molnar]

* Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> Ingo Molnar wrote:
> > I.e. i think it's a fact that right now our release version is highly 
> > deceptive during the merge window.
> [...]
> > One option would be to make LOCALVERSION_AUTO compulsory.
> > 
> > Or to add a tweak to the naming, something like:
> > 
> >  v2.6.31
> >  v2.6.31+
> >  v2.6.32-rc1
> >  v2.6.32-rc1+
> [...]
> > ... for the sole purpose of warning people that anything they pull after 
> > v2.6.31 got released is (wildly!) not vanilla v2.6.31 anymore.
> 
> If this scheme is meant to be something on which people can rely on, 
> everybody who commits to a tree from which Linus pulls from would have 
> to base their branches onto those ...+ commits, always.

I think you misunderstood - the + would just be a shortcut for the 
long-form precise version string.

	Ingo

Re: Linux 2.6.32-rc3

[Frans Pop]

Linus Torvalds wrote:
> And what people are suggesting with a 2.6.32-rc0 would just lead to
> people now rebasing their work NOT EVEN ON A RELEASE. They'd want to
> rebase it on top of that made-up commit (2.6.32-rc0), so now from a
> development standpoint that commit suddenly becomes more important than
> the release itself.

IMO you're looking at this from the wrong side: the developer PoV. The 
request is made from a *user* PoV.
Users very simply want to avoid that they accidentally install a merge 
window kernel over their stable kernel. IMO that makes sense.

Developers are supposed to be able to take care of themselves; the mainline 
tree should aim to make things easy for users.

I see the release versions purely as reference points. And -rc0 is 
obviously useless from that perspective, which is why it should be just a 
Makefile thing and not a tag. But -rc0 is IMO very useful to distinguish 
what kernels someone has installed.

BTW, including the commit number in the version string has a major 
disadvantage: kernels will get installed *alongside* eachother instead of 
the newer kernel replacing the older one. Result is that /boot partitions 
fill up much more quickly.

Cheers,
FJP

Re: Linux 2.6.32-rc3

[Stefan Richter]

Linus Torvalds wrote:
> So how about this?
> 
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial 
> way:
> 
>  - if it is set, things work the way they always have, and you get a 
>    extended kernel release like
> 
> 	2.6.32-rc3-00052-g0eca52a-dirty
> 
>  - but if it is _not_ set,
[...]
>    we append just "+", so you get a version number like
> 
> 	2.6.32-rc3+
[...]
> The "+" could be anything else, of course. The diff is pretty obvious, you 
> can argue about exactly _what_ you'd like to see as a suffix for "and then 
> some".

The "+" suffix is already in informal use with a different meaning.
It's customary to write "For feature XY, you need kernel 2.6.31+" as a
shorthand for "kernel 2.6.31 or any later release".
-- 
Stefan Richter
-=====-==--= =-=- --==-
http://arcgraph.de/sr/

Re: Linux 2.6.32-rc3

[Stefan Richter]

Ingo Molnar wrote:
> * Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>> Ingo Molnar wrote:
>>> One option would be to make LOCALVERSION_AUTO compulsory.
>>>
>>> Or to add a tweak to the naming, something like:
>>>
>>>  v2.6.31
>>>  v2.6.31+
[...]
>> everybody who commits to a tree from which Linus pulls from would have 
>> to base their branches onto those ...+ commits, always.
> 
> I think you misunderstood - the + would just be a shortcut for the 
> long-form precise version string.

Yep, 7 minutes later I would have seen your other post from which it
became clear even to me that it's not about magic commits but a kbuild
tweak. :-)
-- 
Stefan Richter
-=====-==--= =-=- --==-
http://arcgraph.de/sr/

Re: Linux 2.6.32-rc3

[Frans Pop]

Linus Torvalds wrote:
> - but if it is _not_ set, we'll still try to get a version from the
> underlying SCM (we actually support git, hg and SVN right now, even if
> some comments may say "git only"), and if the underlying SCM says it
> has a local version, we append just "+", so you get a version number
> like
> 
> 2.6.32-rc3+

Doesn't this leave users of the git snapshot tarballs in the cold?
That seems a serious disadvantage as different users will get different 
versions (and thus report different versions in bug reports).

The advantage of an -rc0 in the Makefile is that everybody gets it.

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Tue, 6 Oct 2009, Frans Pop wrote:
> 
> Doesn't this leave users of the git snapshot tarballs in the cold?

You can save it in .scmversion if you want to, we've supported that as a 
"export versions outside of the SCM" way since introducing 
LOCALVERSION_AUTO.

> The advantage of an -rc0 in the Makefile is that everybody gets it.

Have you missed the whole discussion about why it doesn't work?

Have you missed the point on why it is FUNDAMENTALLY WRONG to do?

You also seem to be making up more and more ludicrous examples of things 
to do. Why the f*ck cares about somebody taking a random git tree, tarring 
it up, and then building it like that?

I mean really.

		Linus

Re: Linux 2.6.32-rc3

[Stefan Richter]

Frans Pop wrote:
> Developers are supposed to be able to take care of themselves;

_People who build kernels from sources which differ from releases_ are
supposed to take care of themselves.
-- 
Stefan Richter
-=====-==--= =-=- --==-
http://arcgraph.de/sr/

[patch] kbuild: Improve version string logic

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, 6 Oct 2009, Linus Torvalds wrote:
> > 
> > Unless:
> > 
> > > _That_ i think is a lot harder to confuse with the real .31 than a 
> > > v2.6.31-1234-g16123c4 version string.
> > 
> > .. are you saying that it would be just some automatically generated 
> > thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a 
> > CONFIG_LOCALVERSION_AUTO_SHORTFORM?
> 
> So how about this?

this patch is great IMHO. I've modified it to propagate the '+' into the 
long version string as well. I've tested it with auto-version not set 
and it now gives:

 Linux europe 2.6.32-rc3+ #2 SMP Tue Oct 6 19:26:58 CEST 2009 i686 i686 i386 GNU/Linux

the -rc3+ is a clearly visible distinction. This will improve things 
when bugs are reported with LOCALVERSION_AUTO not set - we'll always 
know when a tree is not vanilla.

With autoversion set 'uname -a' gives:

 Linux europe 2.6.32-rc3+00052-g0eca52a-dirty #3 SMP Tue Oct 6 19:29:54 CEST 2009 i686 i686 i386 GNU/Linux

IMO that's intuitive too. We get whatever is described in the 
localversion in addition to the tag. The '+' clearly signals that 'set 
union' operation we've done.

So this patch solves all the problems i had with our versioning. I've 
attached it below with a changelog.

Thanks,

	Ingo

--------------->
Subject: kbuild: Improve version string logic
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 6 Oct 2009 09:31:03 -0700 (PDT)

It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
way:

 - if it is set, things work the way they always have, and you get a
   extended kernel release like:

	2.6.32-rc3+00052-g0eca52a-dirty

   ( with the difference that the extra version string is separated via
     '+' not via '-'. This improves visibility when we have additional
     changes over a vanilla tag. )

 - but if it is _not_ set, we'll still try to get a version from the
   underlying SCM (we actually support git, hg and SVN right now, even if
   some comments may say "git only"), and if the underlying SCM says it
   has a local version, we append just "+", so you get a version number
   like:

	2.6.32-rc3+

IOW, you'd never get 2.6.32-rc0, but you'd get either the complex git
version number (or SVN/hg/whatever), or at least "2.6.31+" with the "+"
showing that it is more than plain 2.6.31.

The "+" could be anything else, of course. The diff is pretty obvious, you
can argue about exactly _what_ you'd like to see as a suffix for "and then
some".

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 Makefile |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

Index: linux/Makefile
===================================================================
--- linux.orig/Makefile
+++ linux/Makefile
@@ -963,16 +963,21 @@ localver = $(subst $(space),, $(string) 
 # .scmversion is used when generating rpm packages so we do not loose
 # the version information from the SCM when we do the build of the kernel
 # from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
 ifeq ($(wildcard .scmversion),)
         _localver-auto = $(shell $(CONFIG_SHELL) \
-                         $(srctree)/scripts/setlocalversion $(srctree))
+                         $(srctree)/scripts/setlocalversion $(srctree) | sed 's/^-/+/')
 else
         _localver-auto = $(shell cat .scmversion 2> /dev/null)
 endif
 
+ifdef CONFIG_LOCALVERSION_AUTO
 	localver-auto  = $(LOCALVERSION)$(_localver-auto)
+else
+	ifeq ($_localver-auto,)
+		localver-auto = $(LOCALVERSION)
+	else
+		localver-auto = $(LOCALVERSION)+
+	endif
 endif
 
 localver-full = $(localver)$(localver-auto)

Re: Linux 2.6.32-rc3

[Len Brown]

Both Ingo and Dirk clarified and amplified my original request,
that it be easy to trivially tell the difference between stuff
_based on_ on 2.6.X, and stuff _based on_ the following merge window.

I fully understand non-linear development, I undersatnd
and use CONFIG_LOCALVERSION_AUTO, but that isn't sufficient
to solve the problem I have in my use case.

In my use-case, I develop on my desktop with a backing git tree.

When I want to do builds, I throw a tar-ball over the wall
to a remote compute engine to chew on the tree for a few hours.

The compute engine runs a relatively time-consuming serialized
script to discover all of the interesting configs to build.
It then stores those configs in a unique place associated
with that release.  It doesn't have a backing git tree,
so it uses the info in the Makefile -- 2.6.X.

Then the compute engine builds each config, and stores the
output in the same place -- 2.6.X.  On a typical build error,
I fix, send a new tar file, and unless I've changed Kconfig,
I kick off the builds without re-generating all the config files.

Even if I could get it, I generally don't want an exact -g1234
to identify the release, because 90% of the time I want to re-use
the config files that I've already built for the snapshot
the tree is based on without the repeating the time-consuming config
re-generation step.

My big problem today is that is that the new 2.6.X results
overwrites my reference configs for the real 2.6.X.

This means that if I have a development tree that is based
on the real 2.6.X (I almost always do), as soon as I build
a merge window kernel, I've lost all the golden configs
that I may want to re-use for my branch that is based
on the real 2.6.X

This also means that I've overwritten all of the
reference build results.

Maybe this use-case is stupid and simple-minded, but I'm
sure there are more stupid and more simple-minded use cases
out there that would benefit from immediately knowing the
difference in the Makefile between something based on 2.6.X
and something based on the following merge window.

thanks for listening.

-Len

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Tue, 6 Oct 2009, Stefan Richter wrote:

> Frans Pop wrote:
> > Developers are supposed to be able to take care of themselves;
> 
> _People who build kernels from sources which differ from releases_ are
> supposed to take care of themselves.

Yes. If you compile a random development kernel, you'd better then not 
come and whine to developers about how you can't tell which version it is. 
Especially when we do have things like CONFIG_LOCALVERSION_AUTO exactly 
for this case.

But it's possible that people really just weren't aware of that whole 
LOCALVERSION_AUTO thing.

			Linus

Re: Linux 2.6.32-rc3

[Theodore Tso]

On Tue, Oct 06, 2009 at 08:42:18AM -0700, Linus Torvalds wrote:
> Now, that's not actually true, because (a) people rebase and (b) even in 
> the absense of rebases I do merge with people like Andrew by email, so we 
> actually end up having statistics like these:
> 
>      32 SUBLEVEL = 29
>     383 SUBLEVEL = 30
>    8795 SUBLEVEL = 31
>       1 SUBLEVEL = 32
> 
> which is actually a bit sad in itself (showing just _how_ many people 
> rebased their work on top of a release), but is still showing that we 
> actually had 32 new commits in there that were based on a 2.6.29 kernel

It's actually not quite so bad.  If you take into account
Extraversion, the stats that you get look like this[1]:

      4 29-rc2
     28 29-rc8
    331 30
      4 30-rc2
     48 30-rc5
   3867 31
    561 31-rc1
    895 31-rc2
    190 31-rc3
    278 31-rc4
   1245 31-rc5
    521 31-rc6
    515 31-rc7
    387 31-rc8
    336 31-rc9
      1 32-rc2

That actually shows that well over half of the commit based off of
2.6.31 were actually based off of some 2.6.31-rc release, based on
something *before* 2.6.31 released.

Of the 3867 that were based on something between 2.6.31 and
2.6.31-rc1, that may be explained by people (like me) who will do a
test merge, and if the test merge has conflicts, prefer to resolve the
conflicts via a rebase and a re-run of the regression test suite, as
opposed to either (a) having the upstream maintainer (you) do handle
the merge, or (b) having two merges in the history; one merge by the
maintainer to resolve the merge conflict, and another by the upstream
maintainer when they pull in the topic branch.

Some (probably small percentage of the commits based on something
between 2.6.31 and 2.6.31-rc1 can probably be explained by on bug
fixes after an initial merge, but granted that's probably a pretty
small set.

					- Ted

\[1] Generated using:

git rev-list v2.6.31..v2.6.32-rc1 |
while read a
      do
	git show $a:Makefile | head -4 > /tmp/foo
	    awk '/^SUBLEVEL/ {printf("%s", $3)}; /^EXTRAVERSION/ {print $3}' < /tmp/foo
	    done | sort | uniq -c

Re: Linux 2.6.32-rc3

[Dirk Hohndel]

On Tue, 2009-10-06 at 09:31 -0700, Linus Torvalds wrote:
> 
> On Tue, 6 Oct 2009, Linus Torvalds wrote:
> > 
> > Unless:
> > 
> > > _That_ i think is a lot harder to confuse with the real .31 than a 
> > > v2.6.31-1234-g16123c4 version string.
> > 
> > .. are you saying that it would be just some automatically generated 
> > thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a 
> > CONFIG_LOCALVERSION_AUTO_SHORTFORM?

That's much better than what I had suggested - and it would work for
your case with multiple trees in a sane manner as well.

> IOW, you'd never get 2.6.32-rc0, but you'd get either the complex git 
> version number (or SVN/hg/whatever), or at least "2.6.31+" with the "+" 
> showing that it is more than plain 2.6.31.
> 
> The "+" could be anything else, of course. The diff is pretty obvious, you 
> can argue about exactly _what_ you'd like to see as a suffix for "and then 
> some".

The argument by Stefan Richter that '+' is already used informally as
"or later" is somewhat valid - maybe we could use an ampersand (which
originally stood for 'et cetera' - and other things). 

But then I don't know if that would confuse tons of scripts as the & has
lots of other meanings in various scripting languages.

-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: Linux 2.6.32-rc3

[Herlin R. Matos Lastres]

Linus Torvalds wrote:
> If so, then I don't hate "v2.6.31+", but at the same time, that single 
> plus-sign tells _so_much_ less than v2.6.31-1234-g16123c4 that I think 
> it's really sad and crippled.   
I agree with linus, I don't like that (+) simbol in the linux version,
I prefer only numbers.

Herlin.

Re: Linux 2.6.32-rc3

[Theodore Tso]

On Tue, Oct 06, 2009 at 06:40:28PM +0200, Ingo Molnar wrote:
> 
> Could we, for consistency's sake, make it:
> 
>  	2.6.32-rc3+00052-g0eca52a-dirty
>  	2.6.32-rc3+
> 
> ? Or do we want to keep the old version string alone for some reason?

I'm a bit concerned that changing from what we've currently had:

>       2.6.29-00052-g0eca52a-dirty

might break some packaging scripts.  I'm also personally used to that
naming scheme; in fact at the moment I'm using
2.6.32-rc1-00292-gb0390e2.  :-)

							- Ted

Re: Linux 2.6.32-rc3

[Theodore Tso]

BTW, just out of yucks, after experimenting a bit with git log
--pretty=format:%P and git-describe, here are the top parents used to
base patch commits that were merged during the recent merge window:

      5 v2.6.30
      5 v2.6.31-git3
      6 v2.6.31-git8
      6 v2.6.31-git10
      6 v2.6.31-git15
      7 v2.6.31-git6
      7 v2.6.31-git11
      8 v2.6.31-git4
      9 v2.6.31-git5
      9 v2.6.31-git14
     11 v2.6.31-git2
     11 v2.6.31-git9
     11 v2.6.31-git12
     18 v2.6.31

					- Ted

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Tue, 6 Oct 2009, Len Brown wrote:
> 
> This also means that I've overwritten all of the
> reference build results.

That was a really long and boring email, and all it said to me was

 "I can't be bothered to turn on CONFIG_LOCALCONFIG_AUTO, or I didn't even 
  read the thread to find out it exists and that you can use it even 
  without a git tree"

> thanks for listening.

I wish I could say the same.

So now, can you please just turn on CONFIG_LOCALCONFIG_AUTO and say "oh, 
I'm happy now"?

It really does work with tar-balls too. The whole tar-ball thing is a 
total red herring. All you need to do is add a ".scmversion" file into the 
end result, and you're done.

And you can do that easily - even _after_ you've created the tar-file, and 
even if you don't have a working tree. Lookie here:

	tar rvf some-random-tar-file.tar linux-x.y.z/.scmversion

see?

Or, in the case of using "git archive", you can avoid having to remember 
to add that .scmversion file, and instead teach your build-bot to create 
it automatically from the tar-file even if you do _not_ add a .scmversion 
file to the actual tar-file. "git tar" There's a command for that: "git 
get-tar-commit-id", so you can just add something like

	zcat < xxx.tar.gz | git get-tar-commit-id > .scmversion

(yes, yes, you may want to massage it a bit, ie do something like

	sed 's/^\(........\).*$/-g\1/'

or whatever to turn that 40-character SHA1 into a nicer extraversion. 
Whatever. Truly trivial scripting, and it means that your build server 
will now _always_ build a kernel that actually knows what kernel it is!

Isn't that the sign of a _good_ solution? Something that actually improves 
the end result in a real way? Now your builds will know what version they 
were built from!

Please?

		Linus

Re: Linux 2.6.32-rc3

[Ingo Molnar]

* Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> Linus Torvalds wrote:
> > So how about this?
> > 
> > It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial 
> > way:
> > 
> >  - if it is set, things work the way they always have, and you get a 
> >    extended kernel release like
> > 
> > 	2.6.32-rc3-00052-g0eca52a-dirty
> > 
> >  - but if it is _not_ set,
> [...]
> >    we append just "+", so you get a version number like
> > 
> > 	2.6.32-rc3+
> [...]
> > The "+" could be anything else, of course. The diff is pretty obvious, you 
> > can argue about exactly _what_ you'd like to see as a suffix for "and then 
> > some".
> 
> The "+" suffix is already in informal use with a different meaning. 
> It's customary to write "For feature XY, you need kernel 2.6.31+" as a 
> shorthand for "kernel 2.6.31 or any later release".

'+' is also informally used to denote addition and a whole ton of other 
things. (and likewise all other ASCII characters)

The primary context in where it's used, uname output and "I used kernel 
v2.6.31+" statements is pretty unambigous i think.

	Ingo

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Tue, 6 Oct 2009, Theodore Tso wrote:
> 
> It's actually not quite so bad.  If you take into account
> Extraversion, the stats that you get look like this[1]:

I'm a moron. Thanks. I wanted to do just a simple grep, and in the process 
I entirely missed that obvious thing.

> That actually shows that well over half of the commit based off of
> 2.6.31 were actually based off of some 2.6.31-rc release, based on
> something *before* 2.6.31 released.

Yup. Goodie. And I feel much better about our development environment now, 
since that is how it's supposed to work.

		Linus

Re: Linux 2.6.32-rc3

[Frans Pop]

On Tue, 6 Oct 2009, Stefan Richter wrote:
> Frans Pop wrote:
> > Developers are supposed to be able to take care of themselves;
> 
> _People who build kernels from sources which differ from releases_ are
> supposed to take care of themselves.

OK. I can agree with that too. It does take some time to learn to take care 
of oneself though. The point was that contributors start out as users; 
some will gradually become developers.

And remember that developers also do often *ask* regular users to "try the
current mainline", even during the merge window. Maybe that is something 
that is done too lightly?

Cheers,
FJP

Re: Linux 2.6.32-rc3

[Ingo Molnar]

* Theodore Tso <tytso@mit.edu> wrote:

> On Tue, Oct 06, 2009 at 06:40:28PM +0200, Ingo Molnar wrote:
> > 
> > Could we, for consistency's sake, make it:
> > 
> >  	2.6.32-rc3+00052-g0eca52a-dirty
> >  	2.6.32-rc3+
> > 
> > ? Or do we want to keep the old version string alone for some reason?
> 
> I'm a bit concerned that changing from what we've currently had:
> 
> >       2.6.29-00052-g0eca52a-dirty
> 
> might break some packaging scripts. [...]

( Sidenote: such scripts might as well need fixing then, even without 
  any upstream changes - adding a localversion file to the top level 
  directory (which many out of tree projects do) would possibly break 
  them as well. )

> [...]  I'm also personally used to that naming scheme; in fact at the 
> moment I'm using 2.6.32-rc1-00292-gb0390e2.  :-)

Yeah, i'm pretty happy with auto-localversion as well and use it 
everywhere. What i suggested is a small tweak to that: to make it more 
clear what people get during the merge window - when the string says 
"2.6.31-00292-gb0390e2". Plus a small tweak to the non-auto-localversion 
naming: to make the uname output more clear when people disable the 
auto-localversion option:

 Linux europe 2.6.31+ #2 SMP Tue Oct 6 19:26:58 CEST 2009 i686 i686 i386 GNU/Linux

versus the inaccurate:

 Linux europe 2.6.31 #2 SMP Tue Oct 6 19:26:58 CEST 2009 i686 i686 i386 GNU/Linux

string which we emit today.

	Ingo

Re: Linux 2.6.32-rc3

[Frans Pop]

On Tuesday 06 October 2009, Linus Torvalds wrote:
> Have you missed the whole discussion about why it doesn't work?
> Have you missed the point on why it is FUNDAMENTALLY WRONG to do?

No, I've followed the discussion. I guess I just disagree with you as my 
perspective is different. I still think there are practical advantages to 
it, even if it is not 100% theoretically correct from a versioning PoV 
(which I've already said I agree with).

> You also seem to be making up more and more ludicrous examples of things
> to do.

Those ludicrous examples work very well for me and keep mixtures of stable, 
development and bisection kernels on 6 different architectures manageable. 
Call me weird.

I was not proposing my scheme as a general solution, but just presenting it 
as an example of what can be done locally.

Anyway, as long as I can continue to follow my own scheme, I'm happy 
enough.

> Why the f*ck cares about somebody taking a random git tree, tarring it
> up, and then building it like that? 

Because they are not random. I build inbetween trees mostly when I see that 
fixes for issues I've seen have been merged. My method, making use of the 
possibilities of the distro package management system, gives me perfect 
version management for these kernels. And that is something, I do care 
about (for my own systems, not as something to force on others).

Cheers,
FJP

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Tue, 6 Oct 2009, Frans Pop wrote:
> 
> Enabling it by default somehow would be fine with me, but "compulsory" is a 
> step to far IMO. Users should always be allowed custom schemes.

I do respect that - we shouldn't _force_ things if some people have 
special needs and do things differently and really need a very particular 
version number setup.

That said, we might make it a lot harder for people to overlook this by 
mistake when they don't care or know enough. Maybe we can have three 
levels of the "automatic" version number, and make the third level ("no 
automatic sign of versioning at all") be something that you really need to 
ask for (eg you need to have EMBEDDED enabled to show that you want the 
whole extended config option setup or something fairly draconian like 
that).

				Linus

Re: [patch] kbuild: Improve version string logic

[Johannes Berg]

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

On Tue, 2009-10-06 at 19:35 +0200, Ingo Molnar wrote:

> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> way:
> 
>  - if it is set, things work the way they always have, and you get a
>    extended kernel release like:
> 
> 	2.6.32-rc3+00052-g0eca52a-dirty
> 
>    ( with the difference that the extra version string is separated via
>      '+' not via '-'. This improves visibility when we have additional
>      changes over a vanilla tag. )

I really don't see how it improves visibility (unless you're oblivious
to the difference between long and short strings), but I do know that I
have a few parsers that this will break.

I think adding the + unconditionally will also break things like
debian's make-kpkg, for instance, since the + would get propagated into
the package version which reserves the + for something else.

Etc. Can we please make this stuff optional?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [patch] kbuild: Improve version string logic

[Ingo Molnar]

* Johannes Berg <johannes@sipsolutions.net> wrote:

> On Tue, 2009-10-06 at 19:35 +0200, Ingo Molnar wrote:
> 
> > It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> > way:
> > 
> >  - if it is set, things work the way they always have, and you get a
> >    extended kernel release like:
> > 
> > 	2.6.32-rc3+00052-g0eca52a-dirty
> > 
> >    ( with the difference that the extra version string is separated via
> >      '+' not via '-'. This improves visibility when we have additional
> >      changes over a vanilla tag. )
> 
> I really don't see how it improves visibility (unless you're oblivious 
> to the difference between long and short strings), but I do know that 
> I have a few parsers that this will break.

It improves visibility the same way the + at the end of the short 
version improves visibility.

That said, i'm perfectly fine with just having the short version include 
the '+' sign (i.e. Linus's original patch), that was my original 
suggestion and that is already a big step forward.

Thanks,

	Ingo

Re: [patch] kbuild: Improve version string logic

[Johannes Berg]

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

On Tue, 2009-10-06 at 20:49 +0200, Ingo Molnar wrote:

> That said, i'm perfectly fine with just having the short version include 
> the '+' sign (i.e. Linus's original patch), that was my original 
> suggestion and that is already a big step forward.

However, that still breaks current make-kpkg iirc. I haven't used it in
quite some time, so I don't particularly care.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Linux 2.6.32-rc3

[david]

On Tue, 6 Oct 2009, Linus Torvalds wrote:

> On Tue, 6 Oct 2009, Stefan Richter wrote:
>
>> Frans Pop wrote:
>>> Developers are supposed to be able to take care of themselves;
>>
>> _People who build kernels from sources which differ from releases_ are
>> supposed to take care of themselves.
>
> Yes. If you compile a random development kernel, you'd better then not
> come and whine to developers about how you can't tell which version it is.
> Especially when we do have things like CONFIG_LOCALVERSION_AUTO exactly
> for this case.
>
> But it's possible that people really just weren't aware of that whole
> LOCALVERSION_AUTO thing.

I will say that I was not aware of it, and I've been using kernel.org 
kernels for many years.

I'm glad to see it there. enabling it by default would probably be a very 
good thing.

David Lang

Re: [patch] kbuild: Improve version string logic

[Theodore Tso]

On Tue, Oct 06, 2009 at 08:37:07PM +0200, Johannes Berg wrote:
> 
> I really don't see how it improves visibility (unless you're oblivious
> to the difference between long and short strings), but I do know that I
> have a few parsers that this will break.
> 
> I think adding the + unconditionally will also break things like
> debian's make-kpkg, for instance, since the + would get propagated into
> the package version which reserves the + for something else.
> 
> Etc. Can we please make this stuff optional?

That's exactly what I'm afraid of.  I'd really like to keep the long
version AUTOVERSION strings the same, please.

						- Ted

Re: Linux 2.6.32-rc3

[Joel Becker]

On Tue, Oct 06, 2009 at 09:31:03AM -0700, Linus Torvalds wrote:
> On Tue, 6 Oct 2009, Linus Torvalds wrote:
> > 
> > Unless:
> > 
> > > _That_ i think is a lot harder to confuse with the real .31 than a 
> > > v2.6.31-1234-g16123c4 version string.
> > 
> > .. are you saying that it would be just some automatically generated 
> > thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a 
> > CONFIG_LOCALVERSION_AUTO_SHORTFORM?
> 
> So how about this?
> 
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial 
> way:
> 
>  - if it is set, things work the way they always have, and you get a 
>    extended kernel release like
> 
> 	2.6.32-rc3-00052-g0eca52a-dirty
> 
>  - but if it is _not_ set, we'll still try to get a version from the 
>    underlying SCM (we actually support git, hg and SVN right now, even if 
>    some comments may say "git only"), and if the underlying SCM says it 
>    has a local version, we append just "+", so you get a version number 
>    like
> 
> 	2.6.32-rc3+

	I really like this, because I don't want to see
LOCALVERSION_AUTO forced on.  While I like LOCALVERSION_AUTO in theory,
in practice it means that a one-line commit forces me to install an
entirely new /lib/modules directory.  On many of my test machines this
fills up quickly.  So I turn of LOCALVERSION_AUTO and just set a manual
LOCALVERSION.

Joel

-- 

Life's Little Instruction Book #356

	"Be there when people need you."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: Linux 2.6.32-rc3

[Stefan Richter]

Frans Pop wrote:
> On Tue, 6 Oct 2009, Stefan Richter wrote:
>> Frans Pop wrote:
>>> Developers are supposed to be able to take care of themselves;
>> _People who build kernels from sources which differ from releases_ are
>> supposed to take care of themselves.
> 
> OK. I can agree with that too. It does take some time to learn to take care 
> of oneself though. The point was that contributors start out as users; 
> some will gradually become developers.

The distinction between "users" and "developers" doesn't make sense to
me in the first place.

> And remember that developers also do often *ask* regular users to "try the
> current mainline", even during the merge window. Maybe that is something 
> that is done too lightly?

Do they?  Perhaps the "developers" know what experience and resources
are available to the particular "user", or otherwise put into context
what might be required for the discussed test.

Anyway.  Remember, you ultimately cannot remote-control what people have
in their $(kernelrelease).  You can only tell them that they can set the
local version to an explicit or automatic value if a meaningful
$(kernelrelease) is desired despite working with an unreleased source.
-- 
Stefan Richter
-=====-==--= =-=- --==-
http://arcgraph.de/sr/

Re: Linux 2.6.32-rc3

[Frans Pop]

On Tuesday 06 October 2009, you wrote:
> On Tue, 6 Oct 2009, Frans Pop wrote:
> > Enabling it by default somehow would be fine with me, but "compulsory"
> > is a step to far IMO. Users should always be allowed custom schemes.
>
> I do respect that - we shouldn't _force_ things if some people have
> special needs and do things differently and really need a very
> particular version number setup.

Note that I was referring to adding on the full commit identification. I 
have a lot less problems with the "+" (or whatever we end up with).

I would probably even use it, although it will mean that I effectively 
_always_ have the "+" because of local patches. But that is correct as 
with the patches it's no longer a vanilla release.

> That said, we might make it a lot harder for people to overlook this by
> mistake when they don't care or know enough. Maybe we can have three
> levels of the "automatic" version number, and make the third level ("no
> automatic sign of versioning at all") be something that you really need
> to ask for (eg you need to have EMBEDDED enabled to show that you want
> the whole extended config option setup or something fairly draconian
> like that).

I'd opt for the "or something" as I think it would be a mistake to link it 
to EMBEDDED. That has a rather different purpose.

One case to consider is distributions. They will have their own patches, 
possibly as a branch off mainline in git.
AFAICT with the current patch they'd automatically always get the "+", 
which is almost certain to conflict with their own naming schemes.
Distro configs with EMBEDDED set also does not seem right. Nor should it 
IMHO be needed to have to patch the Makefile to get rid of it.

I think just having a config option with the three choices you suggest and 
an appropriate help text to guide users should be sufficient, with the one 
that activates the "+" as default.

Cheers,
FJP

Re: [patch] kbuild: Improve version string logic

[Frans Pop]

Johannes Berg wrote:
> I think adding the + unconditionally will also break things like
> debian's make-kpkg, for instance, since the + would get propagated into
> the package version which reserves the + for something else.

Are you sure? AFAIK it would be propagated into the package _name_, where 
it is allowed. And even if it were part of the package version, it would 
be in the "upstream" part of the version number, where it is also allowed.

The only reserved use of "+" I'm aware of is in the Debian part of the 
package version.

But I have not used make-kpkg in ages, so I'm not 100% sure how that builds 
the package version. I could be that it duplicates the kernel version in 
both the package name and the upstream part of the package version, but 
that should still be OK.

Cheers,
FJP

Re: [patch] kbuild: Improve version string logic

[Johannes Berg]

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

On Tue, 2009-10-06 at 21:45 +0200, Frans Pop wrote:
> Johannes Berg wrote:
> > I think adding the + unconditionally will also break things like
> > debian's make-kpkg, for instance, since the + would get propagated into
> > the package version which reserves the + for something else.
> 
> Are you sure? 

No, I'm not.

> AFAIK it would be propagated into the package _name_, where 
> it is allowed. And even if it were part of the package version, it would 
> be in the "upstream" part of the version number, where it is also allowed.
> 
> The only reserved use of "+" I'm aware of is in the Debian part of the 
> package version.
> 
> But I have not used make-kpkg in ages, so I'm not 100% sure how that builds 
> the package version. I could be that it duplicates the kernel version in 
> both the package name and the upstream part of the package version, but 
> that should still be OK.

That may all well be true. I wasn't even aware of the distinction
between debian and upstream part of the version :)

I do, however, remember no end to trouble with autoversion and make-kpkg
so eventually gave up on using it entirely.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [patch] kbuild: Improve version string logic

[Frans Pop]

This is a bit OT, but one last reply.

On Tuesday 06 October 2009, Johannes Berg wrote:
> > AFAIK it would be propagated into the package _name_, where
> > it is allowed. And even if it were part of the package version, it
> > would be in the "upstream" part of the version number, where it is
> > also allowed.
>
> That may all well be true. I wasn't even aware of the distinction
> between debian and upstream part of the version :)

The Debian part is everything after the last dash in a package version.

> I do, however, remember no end to trouble with autoversion and make-kpkg
> so eventually gave up on using it entirely.

Yes, problems with autoversion and make-kpkg I can understand as it makes 
the revision ID part of the package name, which is very simply not where 
you want it [1].

I stopped using make-kpkg for 2 reasons. First of all it is insanely 
complex. And second it used to always do a 'make clean' for every build, 
which meant a huge inefficiency during bisections and builds after minor 
changes; I understand that has been fixed though.

I was happy to discover the kernel's native deb-pkg target. There've been 
some improvements to that in recent kernels that make it quite powerful 
and flexible for building custom kernels as Debian packages.

Cheers,
FJP

[1] The deb-pkg target does the same, so autoversion is not usable with 
that either. What I do is manipulate the output of 'git describe' to set 
an ENVVAR that gets used as package version.

Re: Linux 2.6.32-rc3

[Stefan Richter]

Ingo Molnar wrote:
[...]
>  Linux europe 2.6.31+ #2 SMP Tue Oct 6 19:26:58 CEST 2009 i686 i686 i386 GNU/Linux
> 
> versus the inaccurate:
> 
>  Linux europe 2.6.31 #2 SMP Tue Oct 6 19:26:58 CEST 2009 i686 i686 i386 GNU/Linux
> 
> string which we emit today.

It's not the string which is inaccurate.  To assume that the version
string which is embedded into the kernel image fully describes the
kernel is inaccurate. :-)  The + suffix is an improvement in the sense
that it asserts that this kernel is not of a specific version...
-- 
Stefan Richter
-=====-==--= =-=- --==-
http://arcgraph.de/sr/

Re: Linux 2.6.32-rc3

[Benjamin Herrenschmidt]

> 
> It doesn't help, for several reasons:
> 
>  - the step function of the Makefile change happens once per release, and 
>    if you compile anything but releases, you can never rely on just the 
>    revision. Was it a plain -rc, a plain release, or something in 
>    between? You'll never know, just looking at the 2.6.x.y thing.
> 
>    In other words, you fundamentally have three choices:
> 
>     (a) be confused. Adding an "-rc0" won't help. You'll still be confused 
> 	in between releases about exactly what you're running.

Well, thing is, it's not us who are confused in general, it's users who
do reports with confusing versions. Yes, I agree that anything but a
release warrants a proper commit ID, but that's exactly what I asked for
when I wanted -rc0 here :-)

IE. That the -only- kernel that is called "2.6.x" is the release,
everything else has some kind of -rc in front of it, which allows me to
bug the user for a commit ID and know right away that this isn't a
release kernel.

>     (b) use CONFIG_LOCALVERSION_AUTO=y
> 
> 	Now, if 'uname -r' says 2.6.31, then you _know_ it's exactly 
> 	2.6.31 and nothing else. If it's a few commits after 2.6.31, it 
> 	will say something like '2.6.31-1-g752015d', and you know that 
> 	it's one commit after 2.6.31, and you'll know _which_ commit it is!
> 
>     (c) Don't compile anything but releases. 
> 
>    Those are the choices. 

Sure, when doing the stuff ourselves. Again, the problem is user
reports. Being able to distinguish between a 2.6.x "release" kernel and
anything else would be of value, at least to me. For anything else, I
can say "heh, you've been compiling non-release stuff, you should be
able to get me a git commit ID.

Difference boils down to users falling into two categories: Those who
compile non-release stuff, and should be able to figure out what the ID
is or recompile with LOCAL_VERSION set propertly etc... and those who
don't, didn't always compile the kernel themselves, and fortunately in
-most- cases are only running a "release".
 
>  - An even _more_ fundamental reason: Linux development isn't linear. 
>    There is not one "first commit" after a release, and there never will 
>    be. Sure, there's a first commit that I do, but that has absolutely 
>    zero relevance.

it would be easy enough for you to push a change to the Makefile just
after you tag a release and before you merge anything else.

>    Learn this. Until you do, you'll be confused, and you'll show your 
>    confusion by saying "I want a 2.6.n+1-rc0". You'll _also_ show your 
>    confusion by things like "I was bisecting a bug that happened between 
>    2.6.30 and 2.6.31, and suddenly git was asking me to test a kernel that 
>    said it was version 2.6.29-rc1 - so I stopped bisecting because git was 
>    confused".
> 
> Who was confused? Was it git, or was it the person who thought that the 
> Makefile version could be consistent in a non-linear world?
> 
> So no. I'm not going to do -rc0. Because doing that is _stupid_. And until 
> you understand _why_ it's stupid, it's pointless talking about it, and 
> when you _do_ understand that it's stupid, you'll agree with me.

I disagree. I understand the linearity problem. My point isn't about
having the Makefile provide with any kind of precise "pointer" into that
tree for non-release, but really only to differenciate a release from
anything else.

I know for somebody who uses git everyday, the concept of release even
becomes a bit fuzzy, but there's a lot of folks out there who really
don't see anything else :-) 

Cheers,
Ben.
 
> 			Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Tue, 6 Oct 2009, Hans-Peter Jansen wrote:
> 
> Let's change the focus - what does it cost you:

No. You don't understand the difference between doing things right, and 
doing them wrong. It's not about "what does it cost me". It's about doing 
a really stupid thing that doesn't even _solve_ the problem in a lot of 
real cases, and doing the _right_ thing that solves it for every case.

And the fact that people cannot see the difference between those two 
cases is sad.

And no, this is not about "developers" vs "users". Not at all. Everything 
that makes it wrong for developers makes it wrong for users too. 

		Linus

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Wed, 7 Oct 2009, Benjamin Herrenschmidt wrote:
> 
> Sure, when doing the stuff ourselves. Again, the problem is user
> reports. Being able to distinguish between a 2.6.x "release" kernel and
> anything else would be of value, at least to me.

Why are you arguing? CONFIG_LOCALVERSION_AUTO gives exactly that?

Also, why do you think that "release" is any special? All the same things 
are true about "is it -rc1 or is it -rc1-351-g58e57fb? When it comes to a 
bug-report, the difference between the two can be huge.

> I disagree. I understand the linearity problem. My point isn't about
> having the Makefile provide with any kind of precise "pointer" into that
> tree for non-release, but really only to differenciate a release from
> anything else.

And your point is totally destroyed by any amount of thinking. Which you 
clearly didn't do.

I repeat: there are tons of kernels that would not be based directly on 
that "-rc0" commit. You would confuse _those_ cases even more, because you 
would now think that they are somehow "release" kernels.

And the fact is, NONE OF YOUR BLATHERING has in any way shown why people 
shouldn't just use CONFIG_LOCALVERSION_AUTO.

I keep on returning to that, and harping on it, but the point is, WE 
ALREADY SOLVED THIS PROBLEM. Every single person who asks for a -rc0 tag 
is just being stupid. You already have a much superior solution.

So don't ask me for something _stupid_, when you already have the smart 
thing!

		Linus

Re: Linux 2.6.32-rc3

[Florian Mickler]

On Tue, 6 Oct 2009 20:29:08 +0200
Frans Pop <elendil@planet.nl> wrote:

> On Tuesday 06 October 2009, Linus Torvalds wrote:
> > Have you missed the whole discussion about why it doesn't work?
> > Have you missed the point on why it is FUNDAMENTALLY WRONG to do?
> 
> No, I've followed the discussion. I guess I just disagree with you as my 
> perspective is different. I still think there are practical advantages to 
> it, even if it is not 100% theoretically correct from a versioning PoV 
> (which I've already said I agree with).

We shouldn't try to weaken the version-numbering-scheme
more. And every action which only 'suggests' that the version-number
has more weight, than it actually has is just papering over the real
bug. 

It works if you are only some bird sitting at
one branch of the kernel-development-tree (the git DAG, that is)
looking at what he thinks is the tip of the tree. 

But this scheme does not work in the 'decentralised' kernel-scenario.
Because if only one subsystem-maintainer forgets to 'put the zero' into
his branch, anybody who tries that branch is at the same situation
as before.  So it would be useless for any 'colaboration based effort'. 

Nice to have as a bird, but as a ranger you can't expect every tree to
have a tip. ( actually you can .. note to self: ... i'm getting
confused in this alegory... whatever... just relax, refocus and go
on.. ) 

On the other hand, if you could modify the DNA of the trees to make
them 
a) better, so they prevail and other trees extinguish over time and 
b) have him grow 'pluses' at the tip (or whatever distinguishing
feature a released tree exhibits ) the ranger could then wander through 
the forest and just look for pluses to do, whatever he needs to do
with those branches.. aerm trees ... ah whatever. 


i hope you are not lost in the woods, and to sumarize: i've no business
whatsoever in the linux-kernel, but read lkml instead of doing smth
useful. ah, and i think a change in the build-mechanics to distinguish
releases is the way to go, instead of a commit. 

but the problem you noted with the 'export' from git into the ''real
world'' is of course there. 
maybe there is a solution to this? eventually smth like "if you don't
use git you have to always tell the truth? or any other way to 
'dirty' the makefile at export-time ?  in-kernel boot-time checksumming
of the kernel-image? to get at least uname -r right?


dunno,
Florian

-- 
A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?  
>> A: Top-posting.  
>>> Q: What is the most annoying thing in e-mail?

Re: Linux 2.6.32-rc3

[Bryan Donlan]

On Tue, Oct 6, 2009 at 12:36 PM, Frans Pop <elendil@planet.nl> wrote:

> BTW, I've got a solution for bisection too: the versions in the Makefile
> get changed to something constant. And the package version is set equal to
> the bisection iteration. This ensures that I know exactly which kernels
> were build for the series and that I can always go back to a specific
> kernel if I need to retest for some reason.
>
> E.g. (for a bisection covering .30-.31):
> linux-image-2.6.31-bisect_1_amd64.deb
> linux-image-2.6.31-bisect_2_amd64.deb
> linux-image-2.6.31-bisect_3_amd64.deb

It should be noted that implementing this would result in the package
names becoming wildly inconsistent if you bisect over the point where
this feature is introduced. In order to be useful, it would need to
determine if its own implementation commit is shadowed by the 'bisect
good' marker, make a note of this in a non-overwritten location (.git,
eg), then disable itself and use the old behavior if it would bisect
over its own introduction.

Re: Linux 2.6.32-rc3

[Dave Airlie]

On Wed, Oct 7, 2009 at 8:19 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 7 Oct 2009, Benjamin Herrenschmidt wrote:
>>
>> Sure, when doing the stuff ourselves. Again, the problem is user
>> reports. Being able to distinguish between a 2.6.x "release" kernel and
>> anything else would be of value, at least to me.
>
> Why are you arguing? CONFIG_LOCALVERSION_AUTO gives exactly that?
>
> Also, why do you think that "release" is any special? All the same things
> are true about "is it -rc1 or is it -rc1-351-g58e57fb? When it comes to a
> bug-report, the difference between the two can be huge.
>
>> I disagree. I understand the linearity problem. My point isn't about
>> having the Makefile provide with any kind of precise "pointer" into that
>> tree for non-release, but really only to differenciate a release from
>> anything else.
>
> And your point is totally destroyed by any amount of thinking. Which you
> clearly didn't do.
>
> I repeat: there are tons of kernels that would not be based directly on
> that "-rc0" commit. You would confuse _those_ cases even more, because you
> would now think that they are somehow "release" kernels.
>
> And the fact is, NONE OF YOUR BLATHERING has in any way shown why people
> shouldn't just use CONFIG_LOCALVERSION_AUTO.
>
> I keep on returning to that, and harping on it, but the point is, WE
> ALREADY SOLVED THIS PROBLEM. Every single person who asks for a -rc0 tag
> is just being stupid. You already have a much superior solution.
>
> So don't ask me for something _stupid_, when you already have the smart
> thing!

Why don't you just have the kernel version Linux-commitid?

why keep up the pretense that the 2.6.xx bit means anything outside of release?

You could just have the tarball generation scripts make it into a 2.6.31 but
for everyone else we never see it.

Dave.

Re: Linux 2.6.32-rc3

[Theodore Tso]

On Wed, Oct 07, 2009 at 11:22:38AM +1000, Dave Airlie wrote:
> 
> Why don't you just have the kernel version Linux-commitid?
> 
> why keep up the pretense that the 2.6.xx bit means anything outside of release?
> 
> You could just have the tarball generation scripts make it into a 2.6.31 but
> for everyone else we never see it.

The tarball generation scripts for the daily snapshots already set
EXTRAVERSION to -git15, -git16, etc.

So the problem seems to be localized to those users/developers who are
smart enough to use git, and dumb enough not to set
CONFIG_LOCALVERSION_AUTO.  So big of a set this actually is, I can't
say.  Do we have any statistics about how many bug reporters make this
mistake?

						- Ted

Re: [patch] kbuild: Improve version string logic

[David Rientjes]

On Tue, 6 Oct 2009, Ingo Molnar wrote:

> Subject: kbuild: Improve version string logic
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Tue, 6 Oct 2009 09:31:03 -0700 (PDT)
> 
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> way:
> 
>  - if it is set, things work the way they always have, and you get a
>    extended kernel release like:
> 
> 	2.6.32-rc3+00052-g0eca52a-dirty
> 
>    ( with the difference that the extra version string is separated via
>      '+' not via '-'. This improves visibility when we have additional
>      changes over a vanilla tag. )
> 

s/changes/commits/, we'd have to look at the -dirty suffix for uncommited 
changes.

The '+' doesn't necessarily always mean there are additional changes since 
scripts/setlocalversion will return -00000-EXTRAVERSION when we're at a 
release.  So when CONFIG_LOCALVERSION_AUTO is enabled, this patch would, 
for example, create the version 2.6.32-rc3+00000-rc3.

Perhaps we should suppress setlocalversion's output if git describe 
doesn't have a 7-character trailing hash prefixed with 'g'?

Re: Linux 2.6.32-rc3

[Benjamin Herrenschmidt]

> So the problem seems to be localized to those users/developers who are
> smart enough to use git, and dumb enough not to set
> CONFIG_LOCALVERSION_AUTO.  So big of a set this actually is, I can't
> say.  Do we have any statistics about how many bug reporters make this
> mistake?

Not -that- often but I did waste a considerable amount of
time in each case when reported that "2.6.N" had a bug that in fact was
due to somebody building some random git checkout. But yeah, I suppose I
should from now and always ask precisely what kernel was used and/or
enable CONFIG_LOCALVERSION_AUTO.

Cheers,
Ben.

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Wed, 7 Oct 2009, Dave Airlie wrote:
> 
> Why don't you just have the kernel version Linux-commitid?

That's actually what I personally do 99% of the time. And, in fact, it's 
how CONFIG_LOCALVERSION_AUTO effectively works. It's very useful for doing 
things like

	gitk v$(uname -r)..

which really does work (well, apart from the "-dirty" case when I've 
compiled a dirty kernel that has something that isn't committed). Try it. 
It's a great way to see "what do I have in my current tree that I'm not 
actually running".

So with CONFIG_LOCALVERSION_AUTO, you can largely pretend that you really 
only have the git SHA1. The rest is "fluff" for people.

> why keep up the pretense that the 2.6.xx bit means anything outside of release?

Agreed. However, it _does_ mean something for releases.

And that is really how you should think of it. I update the kernel 
Makefile for releases, and nothing else. If you compile a non-release 
kernel, the version is meaningless - unless you have 
CONFIG_LOCALVERSION_AUTO.

> You could just have the tarball generation scripts make it into a 2.6.31 but
> for everyone else we never see it.

Well, about a year ago I actually considered generating the version 
entirely from the tags in the git tree, and do it entirely that way. 

The reason I didn't is that even if it only makes sense for releases, it 
is (a) tradition and (b) useful without (or across) SCM's and (c) human- 
readable. In fact, I tend to like seeing things like

	Linux version 2.6.32-rc2-00351-g58e57fb

in my dmesg outputs, because it does mean something _outside_ of just the 
pure "git version" (the '58e57fb' part is sufficient as far as git is 
concerned). It does have a very human-readable component to it: it's 351 
commits after 2.6.32-rc2.

So I literally think that our current CONFIG_LOCALVERSION_AUTO includes 
the best of both worlds. It has the "uniquely identifying" part, but it 
also has a part that is human-readable and useful for that reason.

			Linus

Re: Linux 2.6.32-rc3

[Linus Torvalds]

On Tue, 6 Oct 2009, Linus Torvalds wrote:
> 
> So I literally think that our current CONFIG_LOCALVERSION_AUTO includes 
> the best of both worlds. It has the "uniquely identifying" part, but it 
> also has a part that is human-readable and useful for that reason.

Btw, that doesn't mean that I'm married to the exact details of the syntax 
etc. I like CONFIG_LOCALVERSION_AUTO, but I can also see why Ingo would 
prefer a "+" there instead of a "-".

And the zero-padding to five digits of the number of commits may make 
things line up nicely, and I think there was even some odd technical 
reason for it too (some package manager or other that was unhappy with 
"simple" numbers like "-1" and thought that they were a build number or 
something), but it's admittedly silly too.

So I'm not trying to say that we could not change the details or perhaps 
improve on it. What I _am_ trying to say is that conceptually that whole 
CONFIG_LOCALVERSION_AUTO is absolutely the only sane way to do things. 
Whether we could expand on it or simplify it or paint it a different bike 
shed color, I don't care much about.

So I'm not married to the exact details of our current LOCALVERSION_AUTO 
thing. But I _am_ 100% convinced that it's conceptually the right thing to 
do, unlike the other suggestions I have pooh-poohed in this thread.

		Linus

Re: Linux 2.6.32-rc3

[Justin P. Mattock]

Linus Torvalds wrote:
> On Wed, 7 Oct 2009, Dave Airlie wrote:
>    
>> Why don't you just have the kernel version Linux-commitid?
>>      
>
> That's actually what I personally do 99% of the time. And, in fact, it's
> how CONFIG_LOCALVERSION_AUTO effectively works. It's very useful for doing
> things like
>
> 	gitk v$(uname -r)..
>
> which really does work (well, apart from the "-dirty" case when I've
> compiled a dirty kernel that has something that isn't committed). Try it.
> It's a great way to see "what do I have in my current tree that I'm not
> actually running".
>
> So with CONFIG_LOCALVERSION_AUTO, you can largely pretend that you really
> only have the git SHA1. The rest is "fluff" for people.
>
>    
>> why keep up the pretense that the 2.6.xx bit means anything outside of release?
>>      
>
> Agreed. However, it _does_ mean something for releases.
>
> And that is really how you should think of it. I update the kernel
> Makefile for releases, and nothing else. If you compile a non-release
> kernel, the version is meaningless - unless you have
> CONFIG_LOCALVERSION_AUTO.
>
>    
>> You could just have the tarball generation scripts make it into a 2.6.31 but
>> for everyone else we never see it.
>>      
>
> Well, about a year ago I actually considered generating the version
> entirely from the tags in the git tree, and do it entirely that way.
>
> The reason I didn't is that even if it only makes sense for releases, it
> is (a) tradition and (b) useful without (or across) SCM's and (c) human-
> readable. In fact, I tend to like seeing things like
>
> 	Linux version 2.6.32-rc2-00351-g58e57fb
>
> in my dmesg outputs, because it does mean something _outside_ of just the
> pure "git version" (the '58e57fb' part is sufficient as far as git is
> concerned). It does have a very human-readable component to it: it's 351
> commits after 2.6.32-rc2.
>
>    
As a total newbie, this took a few to see, but then once I connected the 
dots
made complete sense. (i.g. the how many commits 00351 and commit number 
g58e57fb)
> So I literally think that our current CONFIG_LOCALVERSION_AUTO includes
> the best of both worlds. It has the "uniquely identifying" part, but it
> also has a part that is human-readable and useful for that reason.
>
> 			Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>    
just my $2
(as for the "+" and "-" tough to say, I'm happy as is,
as for the mistake with the version number well, "your human").

:-)

Justin P. Mattock

Re: Linux 2.6.32-rc3

[Frans Pop]

On Wednesday 07 October 2009, Bryan Donlan wrote:
> On Tue, Oct 6, 2009 at 12:36 PM, Frans Pop <elendil@planet.nl> wrote:
> > BTW, I've got a solution for bisection too: the versions in the
> > Makefile get changed to something constant. And the package version is
> > set equal to the bisection iteration. This ensures that I know exactly
> > which kernels were build for the series and that I can always go back
> > to a specific kernel if I need to retest for some reason.
> >
> > E.g. (for a bisection covering .30-.31):
> > linux-image-2.6.31-bisect_1_amd64.deb
> > linux-image-2.6.31-bisect_2_amd64.deb
> > linux-image-2.6.31-bisect_3_amd64.deb
>
> It should be noted that implementing this would result in the package
> names becoming wildly inconsistent if you bisect over the point where
> this feature is introduced.

It is already supported :-)
But yes, what you note is an issue, though one that automatically fades 
with time. And it is softened by the fact that the scheme is not default. 
The default package versioning was unchanged when the option was added.

> In order to be useful, it would need to 
> determine if its own implementation commit is shadowed by the 'bisect
> good' marker, make a note of this in a non-overwritten location (.git,
> eg), then disable itself and use the old behavior if it would bisect
> over its own introduction.

I deal with it in my wrapper script: that tests if the implementation 
commit is present and, if not [1], replaces scripts/package/builddeb with 
a version that does support it. That works for quite a long time back.
The wrapper script also reverts the change after each build so the 
following good/bad does not fail because the tree is dirty.

Cheers,
FJP

[1] It was introduced with .30: v2.6.30-rc8-79-gc72c75d.

2.6.32-rc3: floating-point build failure (undefined reference to `__udivdi3' in menu governor)

[Andreas Mohr]

Hi,

didn't find any report about this, so...

  LD      .tmp_vmlinux1
drivers/built-in.o(.text+0xd85a1): In function `menu_select':
drivers/cpuidle/governors/menu.c:212: undefined reference to `__udivdi3'
make: *** [.tmp_vmlinux1] Error 1


The symbol being __udivdi3 sounds to me like it's illegal FP use here.

This is not necessarily a -rc3 regression, though (currently running
2.6.29-rc7 on this box).


# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-49)

(yes, I know... ;)

Andreas Mohr

Re: Linux 2.6.32-rc3

[Theodore Tso]

On Tue, Oct 06, 2009 at 08:31:46PM -0700, Linus Torvalds wrote:
> 
> Btw, that doesn't mean that I'm married to the exact details of the syntax 
> etc. I like CONFIG_LOCALVERSION_AUTO, but I can also see why Ingo would 
> prefer a "+" there instead of a "-".
> 
> And the zero-padding to five digits of the number of commits may make 
> things line up nicely, and I think there was even some odd technical 
> reason for it too (some package manager or other that was unhappy with 
> "simple" numbers like "-1" and thought that they were a build number or 
> something), but it's admittedly silly too.

I really like CONFIG_LOCALVERSION_AUTO the way it is, and changing it
will break things.  It probably wouldn't be that hard to fix things,
although the fix probably would involve post-processing the version
number to bring it back to using '-' for all of the spearators, so
that '+' could be used for separating the packaging-specific version
details.

The one thing that I wish we *could* do is make
CONFIG_LOCALVERSION_AUTO mandatory, or at least making it the strong
default and forcing people to work to turn it off, since the problem
really is with users smart enough to use git, but not quite smart
enough to turn on CONFIG_LOCALVERSION_AUTO.

					- Ted

Re: 2.6.32-rc3: floating-point build failure (undefined reference to `__udivdi3' in menu governor)

[Arjan van de Ven]

Andreas Mohr wrote:
> Hi,
> 
> didn't find any report about this, so...
> 
>   LD      .tmp_vmlinux1
> drivers/built-in.o(.text+0xd85a1): In function `menu_select':
> drivers/cpuidle/governors/menu.c:212: undefined reference to `__udivdi3'
> make: *** [.tmp_vmlinux1] Error 1
> 
> # gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-49)

seems you're the only user of this left.

it's not floating point but a 64 bit division.
The only one I can imagine is the one on line 213

looking at it, can you try sticking (u32) at the end of line 212; that multiply is not very likely to exceed 32 bits

Re: Linux 2.6.32-rc3

[Mike Galbraith]

On Wed, 2009-10-07 at 09:52 -0400, Theodore Tso wrote:

> The one thing that I wish we *could* do is make
> CONFIG_LOCALVERSION_AUTO mandatory, or at least making it the strong
> default and forcing people to work to turn it off, since the problem
> really is with users smart enough to use git, but not quite smart
> enough to turn on CONFIG_LOCALVERSION_AUTO.

There are also those who use git, but turn CONFIG_LOCALVERSION_AUTO off
for a reason, because it just annoys them with zero gain.

I don't do -rcX.  I have one tree per installed kernel.  When Linus
pulls a release out of the oven, on that day, Makefile becomes rev++ for
a new tree and stays that way until he declares the next one baked.  Old
tree stays frozen at rev until it becomes .stable.  My repos are always
frozen at where the installed kernel is at, so adding an extra version
is just a work generating irritant.

I'd like having git ID embedded in the kernel for idiot proofing, but I
don't like it polluting my installs, so I live without it.

	-Mike

Re: 2.6.32-rc3: floating-point build failure (undefined reference to `__udivdi3' in menu governor)

[Andreas Mohr]

Hi,

On Wed, Oct 07, 2009 at 07:23:07AM -0700, Arjan van de Ven wrote:
> Andreas Mohr wrote:
>> Hi,
>>
>> didn't find any report about this, so...
>>
>>   LD      .tmp_vmlinux1
>> drivers/built-in.o(.text+0xd85a1): In function `menu_select':
>> drivers/cpuidle/governors/menu.c:212: undefined reference to `__udivdi3'
>> make: *** [.tmp_vmlinux1] Error 1
>>
>> # gcc -v
>> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
>> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
>> Thread model: posix
>> gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-49)
>
> seems you're the only user of this left.

Oh my...

> it's not floating point but a 64 bit division.
> The only one I can imagine is the one on line 213
>
> looking at it, can you try sticking (u32) at the end of line 212; that multiply is not very likely to exceed 32 bits

Nopeee.

        data->predicted_us = DIV_ROUND_CLOSEST((u32)
                data->expected_us * data->correction_factor[data->bucket],
                (u32)RESOLUTION * DECAY);

It did properly rebuild drivers/cpuidle/governors/menu.o.
Still happening.
IOW it must be somewhere inside the DIV_ROUND_CLOSEST macro or so.

Andreas Mohr

Re: Linux 2.6.32-rc3

[david]

On Wed, 7 Oct 2009, Mike Galbraith wrote:

> On Wed, 2009-10-07 at 09:52 -0400, Theodore Tso wrote:
>
>> The one thing that I wish we *could* do is make
>> CONFIG_LOCALVERSION_AUTO mandatory, or at least making it the strong
>> default and forcing people to work to turn it off, since the problem
>> really is with users smart enough to use git, but not quite smart
>> enough to turn on CONFIG_LOCALVERSION_AUTO.
>
> There are also those who use git, but turn CONFIG_LOCALVERSION_AUTO off
> for a reason, because it just annoys them with zero gain.
>
> I don't do -rcX.  I have one tree per installed kernel.  When Linus
> pulls a release out of the oven, on that day, Makefile becomes rev++ for
> a new tree and stays that way until he declares the next one baked.  Old
> tree stays frozen at rev until it becomes .stable.  My repos are always
> frozen at where the installed kernel is at, so adding an extra version
> is just a work generating irritant.
>
> I'd like having git ID embedded in the kernel for idiot proofing, but I
> don't like it polluting my installs, so I live without it.

as I understand it, if you only use the released kernel then 
CONFIG_LOCALVERSION_AUTO will make no difference to you.

the kernel string only changes if you use a non-release kernel.

David Lang

Re: 2.6.32-rc3: floating-point build failure (undefined reference to `__udivdi3' in menu governor)

[Arjan van de Ven]

Andreas Mohr wrote:
> Hi,
>> looking at it, can you try sticking (u32) at the end of line 212; that multiply is not very likely to exceed 32 bits
> 
> Nopeee.
> 
>         data->predicted_us = DIV_ROUND_CLOSEST((u32)
>                 data->expected_us * data->correction_factor[data->bucket],
>                 (u32)RESOLUTION * DECAY);
> 
> It did properly rebuild drivers/cpuidle/governors/menu.o.
> Still happening.
> IOW it must be somewhere inside the DIV_ROUND_CLOSEST macro or so.

it looks like your GCC has a problem dividing by a power of two though;
both DECAY and RESOLUTION are powers of two...

Re: 2.6.32-rc3: floating-point build failure (undefined reference to `__udivdi3' in menu governor)

[Kyle McMartin]

On Wed, Oct 07, 2009 at 07:34:58PM +0200, Andreas Mohr wrote:
> Nopeee.
> 
>         data->predicted_us = DIV_ROUND_CLOSEST((u32)
>                 data->expected_us * data->correction_factor[data->bucket],
>                 (u32)RESOLUTION * DECAY);
> 
> It did properly rebuild drivers/cpuidle/governors/menu.o.
> Still happening.
> IOW it must be somewhere inside the DIV_ROUND_CLOSEST macro or so.
> 

It's being a jerk and not realizing that RESOLUTION * DECAY is a power
of 2, so it can just do a shift...

I don't recall if gcc 3 had these magic builtins, but if it does,
something like this might help since it's the u64 case that's
problematic.

I probably noviced this in some trivial way, but it's a thought.
And in the most-annoying case (most of these u64 divisions are power of
2, that I've seen...) would sort things out.

regards, Kyle

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index d3cd23f..4936eb6 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -51,6 +51,9 @@ extern const char linux_proc_banner[];
 #define DIV_ROUND_CLOSEST(x, divisor)(			\
 {							\
 	typeof(divisor) __divisor = divisor;		\
+	if (__builtin_types_compatible_p(typeof(divisor), unsigned long long) &&	\
+		__builtin_popcountll(__divisor) == 1)			\
+		(((x) + ((__divisor) / 2) << __builtin_ffsll(__divisor)));	\
 	(((x) + ((__divisor) / 2)) / (__divisor));	\
 }							\
 )

Re: Linux 2.6.32-rc3

[Mike Galbraith]

On Wed, 2009-10-07 at 10:44 -0700, david@lang.hm wrote:

> as I understand it, if you only use the released kernel then 
> CONFIG_LOCALVERSION_AUTO will make no difference to you.
> 
> the kernel string only changes if you use a non-release kernel.

Oh no, I pull/build multiple trees daily.

	-Mike

Re: Linux 2.6.32-rc3

[Steven Rostedt]

On Tue, Oct 06, 2009 at 08:24:52AM -0700, Linus Torvalds wrote:
> 
> I'd much rather screw up the version number entirely and add a _random_ 
> number to it (so that the Makefile would say "2.6.18" after I have 
> released 2.6.32) just so that people would be forced to _understand_ that 
> the version number isn't as meaningful as you seem to think it is.

Oh oh oh... Can we call it 2.7 now!

Or better yet. 3.0 :-)

-- Steve

Re: Linux 2.6.32-rc3

[Len Brown]

> ... please just turn on CONFIG_LOCALCONFIG_AUTO

For git-tree-based builds, I'm delighted with CONFIG_LOCALCONFIG_AUTO.

But on my build engine, I don't need or want the exact commit id.
(I have a descriptive originating branch name for it already,
and that is a heck of a lot easier to understand)

Indeed SUBLEVEL and EXTRAVERSION in the Makefile turn out to be
just about ideal both for good .config file library re-use,
and with double buffering, storing of results.

So if the -rc* EXTRAVERSION naming scheme were applied consistently
so that it could differentiate between a final release and
the following merge window, then SUBLEVEL and EXTRAVERSION
would be all I need on my build box.

Re: scripts to generate .scmversion

I'll pass.

I'd rather a script to simply update SUBLEVEL and EXTRAVERSION
in the Makefile upon seeing the 1st commit of the merge window.
I was hoping you'd do that for me, but failing that,
I can do it for myself.  Just don't jump on me when I call
the merge window rc0.

thanks,
-Len

Re: Linux 2.6.32-rc3

[Frans Pop]

Linus Torvalds wrote:
> Once you start believing the lie, suddenly all the subtrees will start
> thinking that now _their_ kernel versions are bad, so now they'll start
> to want to make the same idiotic changes to their Makefiles, or maybe
> they'll decide that they don't want to pull tagged releases, but the "one
> after the tag so that they'll get the updated Makefile".

After sleeping on it and letting it percolate a bit I understand this 
argument better, and accept it.

I'll continue to increase SUBLEVEL and add -rc0 for my own builds though, 
as IMHO it still makes perfect sense for versioning and managing installed 
kernel packages.

The conclusion for me is: if anyone wants -rc0, simply apply it locally.


I don't see myself ever using AUTOVERSION. The reason is that I don't want 
the files in /boot and dirs in /lib/modules/ to include the commit ID.

For me the kernel *version* is what's defined in the Makefile (plus any 
localversion extentions). That's how I want it installed. The AUTOVERSION 
part is a *revision*: an update to the tagged version.
(I don't expect you to agree with this.)

So, unless it is made possible to include AUTOVERSION in the kernel and 
display it in dmesg and as part of the full 'uname -a' info *without* it 
becoming part of 'uname -r', it is not a usable option for me. Sorry.

Cheers,
FJP

Re: 2.6.32-rc3: floating-point build failure (undefined reference to `__udivdi3' in menu governor)

[Andreas Mohr]

Hi,

On Wed, Oct 07, 2009 at 01:45:54PM -0400, Kyle McMartin wrote:
> On Wed, Oct 07, 2009 at 07:34:58PM +0200, Andreas Mohr wrote:
> > Still happening.
> > IOW it must be somewhere inside the DIV_ROUND_CLOSEST macro or so.
> > 
> 
> It's being a jerk and not realizing that RESOLUTION * DECAY is a power
> of 2, so it can just do a shift...
> 
> I don't recall if gcc 3 had these magic builtins, but if it does,
> something like this might help since it's the u64 case that's
> problematic.

Uh... nope:

In file included from kernel/sched.c:1818:
kernel/sched_fair.c: In function `select_task_rq_fair':
kernel/sched_fair.c:1366: implicit declaration of function `__builtin_popcountll'
kernel/sched_fair.c:1366: implicit declaration of function `__builtin_ffsll'
kernel/sched_fair.c:1366: warning: suggest parentheses around + or - inside shift
kernel/sched.c: In function `update_sg_lb_stats':
kernel/sched.c:3755: warning: suggest parentheses around + or - inside shift
kernel/sched.c: In function `find_busiest_queue':
kernel/sched.c:4050: warning: suggest parentheses around + or - inside shift
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2


Hmpf. Rather stuck now, ain'tcha, given that gcc 3.2.3 doesn't even have those?

Thanks,

Andreas Mohr

Re: 2.6.32-rc3: floating-point build failure (undefined reference to `__udivdi3' in menu governor)

[Arjan van de Ven]

Andreas Mohr wrote:
> Hi,
> 
> On Wed, Oct 07, 2009 at 01:45:54PM -0400, Kyle McMartin wrote:
>> On Wed, Oct 07, 2009 at 07:34:58PM +0200, Andreas Mohr wrote:
>>> Still happening.
>>> IOW it must be somewhere inside the DIV_ROUND_CLOSEST macro or so.
>>>
>> It's being a jerk and not realizing that RESOLUTION * DECAY is a power
>> of 2, so it can just do a shift...
>>
>> I don't recall if gcc 3 had these magic builtins, but if it does,
>> something like this might help since it's the u64 case that's
>> problematic.
> 
> Uh... nope:
> 
> In file included from kernel/sched.c:1818:
> kernel/sched_fair.c: In function `select_task_rq_fair':
> kernel/sched_fair.c:1366: implicit declaration of function `__builtin_popcountll'
> kernel/sched_fair.c:1366: implicit declaration of function `__builtin_ffsll'
> kernel/sched_fair.c:1366: warning: suggest parentheses around + or - inside shift
> kernel/sched.c: In function `update_sg_lb_stats':
> kernel/sched.c:3755: warning: suggest parentheses around + or - inside shift
> kernel/sched.c: In function `find_busiest_queue':
> kernel/sched.c:4050: warning: suggest parentheses around + or - inside shift
> make[1]: *** [kernel/sched.o] Error 1
> make: *** [kernel] Error 2
> 
> 
> Hmpf. Rather stuck now, ain'tcha, given that gcc 3.2.3 doesn't even have those?
> 

wonder if making a new define with the value of RESOLUTION * DECAY
(the actual value obviously) convinces your gcc that it really is a power of two ?

Re: 2.6.32-rc3: floating-point build failure (undefined reference to `__udivdi3' in menu governor)

[Kyle McMartin]

On Fri, Oct 09, 2009 at 09:32:13AM -0700, Arjan van de Ven wrote:
>> Hmpf. Rather stuck now, ain'tcha, given that gcc 3.2.3 doesn't even have those?
>>
>
> wonder if making a new define with the value of RESOLUTION * DECAY
> (the actual value obviously) convinces your gcc that it really is a power of two ?
>

It shouldn't. Maybe just add a BUILD_BUG_ON and change the divide to a
shift directly. How expected are these values to ever change, really?

-Kyle

Re: 2.6.32-rc3: floating-point build failure (undefined reference to `__udivdi3' in menu governor)

[Arjan van de Ven]

Kyle McMartin wrote:
> On Fri, Oct 09, 2009 at 09:32:13AM -0700, Arjan van de Ven wrote:
>>> Hmpf. Rather stuck now, ain'tcha, given that gcc 3.2.3 doesn't even have those?
>>>
>> wonder if making a new define with the value of RESOLUTION * DECAY
>> (the actual value obviously) convinces your gcc that it really is a power of two ?
>>
> 
> It shouldn't. Maybe just add a BUILD_BUG_ON and change the divide to a
> shift directly. How expected are these values to ever change, really?
> 

so far... they haven't. I don't really expect these to change much.
maybe once a year or so... to other powers of two

Re: Linux 2.6.32-rc3

[Pavel Machek]

On Tue 2009-10-06 22:31:19, Theodore Tso wrote:
> On Wed, Oct 07, 2009 at 11:22:38AM +1000, Dave Airlie wrote:
> > 
> > Why don't you just have the kernel version Linux-commitid?
> > 
> > why keep up the pretense that the 2.6.xx bit means anything outside of release?
> > 
> > You could just have the tarball generation scripts make it into a 2.6.31 but
> > for everyone else we never see it.
> 
> The tarball generation scripts for the daily snapshots already set
> EXTRAVERSION to -git15, -git16, etc.
> 
> So the problem seems to be localized to those users/developers who are
> smart enough to use git, and dumb enough not to set
> CONFIG_LOCALVERSION_AUTO.  So big of a set this actually is, I can't
> say.  Do we have any statistics about how many bug reporters make this
> mistake?

I admit -- I did not know about LOCALVERSION_AUTO, and many times
wished -rc0 would be labeled as such.

Now...perhaps LOCALVERSION_AUTO should not be option? Just hardwire it
to Y? (But that still does not solve systems when someone, probably
me, did rm -rf .git, for space and speed reasons). 

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux 2.6.32-rc3

[Felipe Contreras]

On Sat, Oct 10, 2009 at 3:09 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Tue 2009-10-06 22:31:19, Theodore Tso wrote:
>> On Wed, Oct 07, 2009 at 11:22:38AM +1000, Dave Airlie wrote:
>> >
>> > Why don't you just have the kernel version Linux-commitid?
>> >
>> > why keep up the pretense that the 2.6.xx bit means anything outside of release?
>> >
>> > You could just have the tarball generation scripts make it into a 2.6.31 but
>> > for everyone else we never see it.
>>
>> The tarball generation scripts for the daily snapshots already set
>> EXTRAVERSION to -git15, -git16, etc.
>>
>> So the problem seems to be localized to those users/developers who are
>> smart enough to use git, and dumb enough not to set
>> CONFIG_LOCALVERSION_AUTO.  So big of a set this actually is, I can't
>> say.  Do we have any statistics about how many bug reporters make this
>> mistake?
>
> I admit -- I did not know about LOCALVERSION_AUTO, and many times
> wished -rc0 would be labeled as such.
>
> Now...perhaps LOCALVERSION_AUTO should not be option? Just hardwire it
> to Y? (But that still does not solve systems when someone, probably
> me, did rm -rf .git, for space and speed reasons).

Why is LOCALVERSION_AUTO part of the config file? Shouldn't it be on
the Makefile? Then it's easy for people to override it if they want.
And it's also easy for packagers, for whatever wicked reasons.

-- 
Felipe Contreras

[PATCH, v2] kbuild: Improve version string logic

[Ingo Molnar]

This is basically your original patch that adds '+' to the short version 
string of kernels that are 'between' -rc tags. (i dropped the '+' within 
the long version i did in v1 - there were objections against that)

Would this be ok?

	Ingo

-------------->
>From 597e5b15dd0cbb3158afc438e5edae9986e6b76a Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 6 Oct 2009 09:31:03 -0700
Subject: [PATCH] kbuild: Improve version string logic

It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
way:

 - if it is set, things work the way they always have, and you get a
   extended kernel release like:

	2.6.32-rc3-00052-g0eca52a

 - but if it is _not_ set, we'll still try to get a version from the
   underlying SCM (we actually support git, hg and SVN right now, even if
   some comments may say "git only"), and if the underlying SCM says it
   has a local version, we append just "+", so you get a version number
   like:

	2.6.32-rc3+

IOW, you'd never get 2.6.32-rc0, but you'd get either the complex git
version number (or SVN/hg/whatever), or at least "2.6.31+" with the "+"
showing that it is more than plain 2.6.31.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Frans Pop <elendil@planet.nl>
Cc: Dirk Hohndel <hohndel@infradead.org>
Cc: Len Brown <lenb@kernel.org>
LKML-Reference: <20091006173508.GA4786@elte.hu>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 Makefile |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 927d7a3..5dab509 100644
--- a/Makefile
+++ b/Makefile
@@ -963,8 +963,6 @@ localver = $(subst $(space),, $(string) \
 # .scmversion is used when generating rpm packages so we do not loose
 # the version information from the SCM when we do the build of the kernel
 # from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
 ifeq ($(wildcard .scmversion),)
         _localver-auto = $(shell $(CONFIG_SHELL) \
                          $(srctree)/scripts/setlocalversion $(srctree))
@@ -972,7 +970,14 @@ else
         _localver-auto = $(shell cat .scmversion 2> /dev/null)
 endif
 
+ifdef CONFIG_LOCALVERSION_AUTO
 	localver-auto  = $(LOCALVERSION)$(_localver-auto)
+else
+	ifeq ($_localver-auto,)
+		localver-auto = $(LOCALVERSION)
+	else
+		localver-auto = $(LOCALVERSION)+
+	endif
 endif
 
 localver-full = $(localver)$(localver-auto)

Re: [PATCH, v2] kbuild: Improve version string logic

[Frans Pop]

On Monday 12 October 2009, Ingo Molnar wrote:
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> way:
>
>  - if it is set, things work the way they always have, and you get a
>    extended kernel release like:
>
>         2.6.32-rc3-00052-g0eca52a
>
>  - but if it is _not_ set, we'll still try to get a version from the
>    underlying SCM (we actually support git, hg and SVN right now, even
> if some comments may say "git only"), and if the underlying SCM says it
> has a local version, we append just "+", so you get a version number
> like:
>
>         2.6.32-rc3+

I don't object to making this the default (even a strong default), but I 
still don't like the fact that it's not optional.
IMO both LOCALVERSION_AUTO *and* the added "+" can be unsuitable for some 
use cases, for example for distributions.

If someone uses git to manage their custom patches, the only out this patch 
leaves them to avoid the "+" is to revert it in their own trees. IMO that 
should not be necessary.

To repeat some comments from <200910062137.06593.elendil@planet.nl>:
<snip>
Linus wrote:
> That said, we might make it a lot harder for people to overlook this by
> mistake when they don't care or know enough. Maybe we can have three
> levels of the "automatic" version number, and make the third level ("no
> automatic sign of versioning at all") be something that you really need
> to ask for (eg you need to have EMBEDDED enabled to show that you want
> the whole extended config option setup or something fairly draconian
> like that).

I'd opt for the "or something" as I think it would be a mistake to link it 
to EMBEDDED. That has a rather different purpose.

One case to consider is distributions. They will have their own patches, 
possibly as a branch off mainline in git.
AFAICT with the current patch they'd automatically always get the "+", 
which is almost certain to conflict with their own naming schemes.
Distro configs with EMBEDDED set also does not seem right. Nor should it 
IMHO be needed to have to patch the Makefile to get rid of it.

I think just having a config option with the three choices you suggest and 
an appropriate help text to guide users should be sufficient, with the one 
that activates the "+" as default.
</snip>

Cheers,
FJP

Re: [PATCH, v2] kbuild: Improve version string logic

[David Rientjes]

On Mon, 12 Oct 2009, Ingo Molnar wrote:

> diff --git a/Makefile b/Makefile
> index 927d7a3..5dab509 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -963,8 +963,6 @@ localver = $(subst $(space),, $(string) \
>  # .scmversion is used when generating rpm packages so we do not loose
>  # the version information from the SCM when we do the build of the kernel
>  # from the copied source
> -ifdef CONFIG_LOCALVERSION_AUTO
> -
>  ifeq ($(wildcard .scmversion),)
>          _localver-auto = $(shell $(CONFIG_SHELL) \
>                           $(srctree)/scripts/setlocalversion $(srctree))
> @@ -972,7 +970,14 @@ else
>          _localver-auto = $(shell cat .scmversion 2> /dev/null)
>  endif
>  
> +ifdef CONFIG_LOCALVERSION_AUTO
>  	localver-auto  = $(LOCALVERSION)$(_localver-auto)
> +else
> +	ifeq ($_localver-auto,)
> +		localver-auto = $(LOCALVERSION)
> +	else
> +		localver-auto = $(LOCALVERSION)+
> +	endif
>  endif
>  
>  localver-full = $(localver)$(localver-auto)

I don't see where the `+' is dropped between -rc tags; 
scripts/setlocalversion should return -00000-rc5 for v2.6.32-rc5, for 
example, so _localver-auto will always be non-NULL and the `+' is 
appended.

I think scripts/setlocalversion should also be modified as I earlier 
suggested to suppress output when git-describe shows no additional 
commits beyond the tag.  Then, CONFIG_LOCALVERSION_AUTO would not be 
v2.6.32-rc4-00000-rc4, for example, when 2.6.32-rc4 is released.

Your patch also adds the make LOCALVERSION= string to the version without 
requiring CONFIG_LOCALVERSION_AUTO.  That's a change from prior behavior, 
but I think it's helpful for user-specified version tags.

Re: [PATCH, v2] kbuild: Improve version string logic

[Ingo Molnar]

* Frans Pop <elendil@planet.nl> wrote:

> On Monday 12 October 2009, Ingo Molnar wrote:
> > It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> > way:
> >
> >  - if it is set, things work the way they always have, and you get a
> >    extended kernel release like:
> >
> >         2.6.32-rc3-00052-g0eca52a
> >
> >  - but if it is _not_ set, we'll still try to get a version from the
> >    underlying SCM (we actually support git, hg and SVN right now, even
> > if some comments may say "git only"), and if the underlying SCM says it
> > has a local version, we append just "+", so you get a version number
> > like:
> >
> >         2.6.32-rc3+
> 
> I don't object to making this the default (even a strong default), but 
> I still don't like the fact that it's not optional.
>
> IMO both LOCALVERSION_AUTO *and* the added "+" can be unsuitable for 
> some use cases, for example for distributions.
> 
> If someone uses git to manage their custom patches, the only out this 
> patch leaves them to avoid the "+" is to revert it in their own trees.

Is this a bad thing?

> IMO that should not be necessary.

Why not?

	Ingo

Re: [PATCH, v2] kbuild: Improve version string logic

[Ingo Molnar]

* David Rientjes <rientjes@google.com> wrote:

> On Mon, 12 Oct 2009, Ingo Molnar wrote:
> 
> > diff --git a/Makefile b/Makefile
> > index 927d7a3..5dab509 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -963,8 +963,6 @@ localver = $(subst $(space),, $(string) \
> >  # .scmversion is used when generating rpm packages so we do not loose
> >  # the version information from the SCM when we do the build of the kernel
> >  # from the copied source
> > -ifdef CONFIG_LOCALVERSION_AUTO
> > -
> >  ifeq ($(wildcard .scmversion),)
> >          _localver-auto = $(shell $(CONFIG_SHELL) \
> >                           $(srctree)/scripts/setlocalversion $(srctree))
> > @@ -972,7 +970,14 @@ else
> >          _localver-auto = $(shell cat .scmversion 2> /dev/null)
> >  endif
> >  
> > +ifdef CONFIG_LOCALVERSION_AUTO
> >  	localver-auto  = $(LOCALVERSION)$(_localver-auto)
> > +else
> > +	ifeq ($_localver-auto,)
> > +		localver-auto = $(LOCALVERSION)
> > +	else
> > +		localver-auto = $(LOCALVERSION)+
> > +	endif
> >  endif
> >  
> >  localver-full = $(localver)$(localver-auto)
> 
> I don't see where the `+' is dropped between -rc tags; 
> scripts/setlocalversion should return -00000-rc5 for v2.6.32-rc5, for 
> example, so _localver-auto will always be non-NULL and the `+' is 
> appended.
> 
> I think scripts/setlocalversion should also be modified as I earlier 
> suggested to suppress output when git-describe shows no additional 
> commits beyond the tag.  Then, CONFIG_LOCALVERSION_AUTO would not be 
> v2.6.32-rc4-00000-rc4, for example, when 2.6.32-rc4 is released.
> 
> Your patch also adds the make LOCALVERSION= string to the version 
> without requiring CONFIG_LOCALVERSION_AUTO.  That's a change from 
> prior behavior, but I think it's helpful for user-specified version 
> tags.

Good points - the patch is defective in its current form. Anyone 
interested in fixing it? I'll be busy with other things.

	Ingo

Re: [PATCH, v2] kbuild: Improve version string logic

[David Rientjes]

On Tue, 13 Oct 2009, Ingo Molnar wrote:

> > > diff --git a/Makefile b/Makefile
> > > index 927d7a3..5dab509 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -963,8 +963,6 @@ localver = $(subst $(space),, $(string) \
> > >  # .scmversion is used when generating rpm packages so we do not loose
> > >  # the version information from the SCM when we do the build of the kernel
> > >  # from the copied source
> > > -ifdef CONFIG_LOCALVERSION_AUTO
> > > -
> > >  ifeq ($(wildcard .scmversion),)
> > >          _localver-auto = $(shell $(CONFIG_SHELL) \
> > >                           $(srctree)/scripts/setlocalversion $(srctree))
> > > @@ -972,7 +970,14 @@ else
> > >          _localver-auto = $(shell cat .scmversion 2> /dev/null)
> > >  endif
> > >  
> > > +ifdef CONFIG_LOCALVERSION_AUTO
> > >  	localver-auto  = $(LOCALVERSION)$(_localver-auto)
> > > +else
> > > +	ifeq ($_localver-auto,)
> > > +		localver-auto = $(LOCALVERSION)
> > > +	else
> > > +		localver-auto = $(LOCALVERSION)+
> > > +	endif
> > >  endif
> > >  
> > >  localver-full = $(localver)$(localver-auto)
> > 
> > I don't see where the `+' is dropped between -rc tags; 
> > scripts/setlocalversion should return -00000-rc5 for v2.6.32-rc5, for 
> > example, so _localver-auto will always be non-NULL and the `+' is 
> > appended.
> > 
> > I think scripts/setlocalversion should also be modified as I earlier 
> > suggested to suppress output when git-describe shows no additional 
> > commits beyond the tag.  Then, CONFIG_LOCALVERSION_AUTO would not be 
> > v2.6.32-rc4-00000-rc4, for example, when 2.6.32-rc4 is released.
> > 
> > Your patch also adds the make LOCALVERSION= string to the version 
> > without requiring CONFIG_LOCALVERSION_AUTO.  That's a change from 
> > prior behavior, but I think it's helpful for user-specified version 
> > tags.
> 
> Good points - the patch is defective in its current form. Anyone 
> interested in fixing it? I'll be busy with other things.
> 

The patch itself is good, it just needs a change to 
scripts/setlocalversion to suppress output when at a tagged commit.



scripts: suppress setlocalversion output if at tagged commit

It's unnecessary, even for CONFIG_LOCALVERSION_AUTO configs, to append
the "git describe" output to the version string if there are no revisions
beyond a tagged commit.

When the git respository was at the v2.6.32-rc4 tagged commit, for
example, the previous code would output "-00000-rc4," which is
unnecessary.

The comment in scripts/setlocalversion pertaining to this behavior need
not be changed since the implementation now conforms to the description.

Signed-off-by: David Rientjes <rientjes@google.com>
---
 scripts/setlocalversion |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/scripts/setlocalversion b/scripts/setlocalversion
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -26,7 +26,8 @@ if head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
 		# If we are past a tagged commit (like "v2.6.30-rc5-302-g72357d5"),
 		# we pretty print it.
 		if atag="`git describe 2>/dev/null`"; then
-			echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'
+			echo "$atag" | awk -F- 'int($(NF-1)) > 0	\
+					{printf("-%05d-%s", $(NF-1),$(NF))}'
 
 		# If we don't have a tag at all we print -g{commitish}.
 		else

Re: [PATCH, v2] kbuild: Improve version string logic

[Frans Pop]

On Tuesday 13 October 2009, Ingo Molnar wrote:
> > IMO both LOCALVERSION_AUTO *and* the added "+" can be unsuitable for
> > some use cases, for example for distributions.
> >
> > If someone uses git to manage their custom patches, the only out this
> > patch leaves them to avoid the "+" is to revert it in their own trees.
>
> Is this a bad thing?

IMHO yes. This change essentially creates a backwards incompatibility with 
existing naming schemes. Requiring to patch the change out to preserve an 
existing naming scheme just seems a tad unfriendly.

But if I'm the only one who feels that way, go right ahead. You might 
consider adding a comment in the Makefile as a pointer though.

I appreciate that you want this to be a strong default. Does Kconfig 
support defining an option that can only be set by manually editing the 
config and is not displayed as a config question?
If that is supported (or if support for that could be added), then that 
might be a sufficiently obscure solution that experts would know how to 
find, but would leave the vast majority of users using the default.

Cheers,
FJP

Re: [PATCH, v2] kbuild: Improve version string logic

[Linus Torvalds]

On Tue, 13 Oct 2009, Frans Pop wrote:
> On Tuesday 13 October 2009, Ingo Molnar wrote:
> >
> > Is this a bad thing?
> 
> IMHO yes. This change essentially creates a backwards incompatibility with 
> existing naming schemes. Requiring to patch the change out to preserve an 
> existing naming scheme just seems a tad unfriendly.

Let's keep the old behavior by making the AUTO option an three-way choice 
("none", "short", "auto"), and making sure that it actually takes work to 
choose "none" (and that "make oldconfig" doesn't choose it unless you 
explicitly made the choice before - so people who just re-use old .config 
files wouldn't get "none" by mistake).

		Linus

Re: [PATCH, v2] kbuild: Improve version string logic

[David Rientjes]

On Tue, 13 Oct 2009, Linus Torvalds wrote:

> > IMHO yes. This change essentially creates a backwards incompatibility with 
> > existing naming schemes. Requiring to patch the change out to preserve an 
> > existing naming scheme just seems a tad unfriendly.
> 
> Let's keep the old behavior by making the AUTO option an three-way choice 
> ("none", "short", "auto"), and making sure that it actually takes work to 
> choose "none" (and that "make oldconfig" doesn't choose it unless you 
> explicitly made the choice before - so people who just re-use old .config 
> files wouldn't get "none" by mistake).
> 

I don't think you want to do that because it would require the .config to 
be posted on bug reports, for example, to determine the setting of 
CONFIG_LOCALVERSION_AUTO before you can interpret the kernel version.  In 
other words, you wouldn't know that "2.6.32-rc4" is actually 200 commits 
beyond the actual release unless you also know that the .config has 
CONFIG_LOCALVERSION_AUTO="none".

Instead, it's better to force something to be appended to the kernel 
release when "git describe" shows a non-zero revision count as you 
earlier suggested.  When CONFIG_LOCALVERSION_AUTO is enabled, that would 
be the output of scripts/setlocalversion; when it is disabled, it would be 
a `+'.  Only when scripts/setlocalversion returns nothing (we're at an 
actual kernel release) will nothing be appended.

The following is on top of my "scripts: suppress setlocalversion output if 
at tagged commit" patch from 
http://marc.info/?l=linux-kernel&m=125542102631704


kbuild: improve version string logic

The LOCALVERSION= string passed to "make" will now always be appended to
the kernel version after CONFIG_LOCALVERSION, if it exists, regardless of
whether CONFIG_LOCALVERSION_AUTO is set or not.  This allows users to
uniquely identify their kernel builds with a string.

scripts/setlocalversion will now always be called to determine whether
the repository is beyond a tagged (release) commit.  With "scripts:
suppress setlocalversion output if at tagged commit", the output of this
script is empty when at a tagged commit.

If CONFIG_LOCALVERSION_AUTO is enabled, the unique SCM tag reported by 
setlocalversion (or .scmversion) is appended to the kernel version, if it 
exists.  When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
to the kernel version to represent that the kernel has been revised since
the last release.

The end result is this:

 - when LOCALVERSION= is passed to "make", it is appended to the kernel
   version,

 - when CONFIG_LOCALVERSION_AUTO is enabled, a unique SCM identifier is
   appended if the respository has been revised beyond a tagged commit,
   and

 - when CONFIG_LOCALVERSION_AUTO is disabled, a `+' is appended if the 
   repository has been revised beyond a tagged commit.

Also renames variables such as localver-auto and _localver-auto to more 
accurately describe what they represent: localver-extra and
scm-identifier, respectively.

Signed-off-by: David Rientjes <rientjes@google.com>
---
 Makefile |   32 ++++++++++++++++++++------------
 1 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -898,9 +898,13 @@ $(vmlinux-dirs): prepare scripts
 #	  $(localver)
 #	    localversion*		(files without backups, containing '~')
 #	    $(CONFIG_LOCALVERSION)	(from kernel config setting)
-#	  $(localver-auto)		(only if CONFIG_LOCALVERSION_AUTO is set)
-#	    ./scripts/setlocalversion	(SCM tag, if one exists)
-#	    $(LOCALVERSION)		(from make command line if provided)
+#	    $(LOCALVERSION)		(from make command line, if provided)
+#	  $(localver-extra)
+#	    $(scm-identifier)		(unique SCM tag, if one exists)
+#	      ./scripts/setlocalversion	(only with CONFIG_LOCALVERSION_AUTO)
+#	      .scmversion		(only with CONFIG_LOCALVERSION_AUTO)
+#	    +				(only without CONFIG_LOCALVERSION_AUTO
+#					 and repository is at non-tagged commit)
 #
 #  Note how the final $(localver-auto) string is included *only* if the
 # kernel config option CONFIG_LOCALVERSION_AUTO is selected.  Also, at the
@@ -914,26 +918,30 @@ string  = $(shell cat /dev/null \
 localver = $(subst $(space),, $(string) \
 			      $(patsubst "%",%,$(CONFIG_LOCALVERSION)))
 
-# If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called
-# and if the SCM is know a tag from the SCM is appended.
-# The appended tag is determined by the SCM used.
+# scripts/setlocalversion is called to create a unique identifier if the source
+# is managed by a known SCM and the repository has been revised since the last
+# tagged (release) commit.  The format of the identifier is determined by the
+# SCM's implementation.
 #
 # .scmversion is used when generating rpm packages so we do not loose
 # the version information from the SCM when we do the build of the kernel
 # from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
 ifeq ($(wildcard .scmversion),)
-        _localver-auto = $(shell $(CONFIG_SHELL) \
+        scm-identifier = $(shell $(CONFIG_SHELL) \
                          $(srctree)/scripts/setlocalversion $(srctree))
 else
-        _localver-auto = $(shell cat .scmversion 2> /dev/null)
+        scm-identifier = $(shell cat .scmversion 2> /dev/null)
 endif
 
-	localver-auto  = $(LOCALVERSION)$(_localver-auto)
+ifdef CONFIG_LOCALVERSION_AUTO
+	localver-extra = $(scm-identifier)
+else
+	ifneq ($scm-identifier,)
+		localver-extra = +
+	endif
 endif
 
-localver-full = $(localver)$(localver-auto)
+localver-full = $(localver)$(LOCALVERSION)$(localver-extra)
 
 # Store (new) KERNELRELASE string in include/config/kernel.release
 kernelrelease = $(KERNELVERSION)$(localver-full)

Re: [PATCH, v2] kbuild: Improve version string logic

[Ingo Molnar]

* David Rientjes <rientjes@google.com> wrote:

> On Tue, 13 Oct 2009, Linus Torvalds wrote:
> 
> > > IMHO yes. This change essentially creates a backwards incompatibility with 
> > > existing naming schemes. Requiring to patch the change out to preserve an 
> > > existing naming scheme just seems a tad unfriendly.
> > 
> > Let's keep the old behavior by making the AUTO option an three-way 
> > choice ("none", "short", "auto"), and making sure that it actually 
> > takes work to choose "none" (and that "make oldconfig" doesn't 
> > choose it unless you explicitly made the choice before - so people 
> > who just re-use old .config files wouldn't get "none" by mistake).
> 
> I don't think you want to do that because it would require the .config 
> to be posted on bug reports, for example, to determine the setting of 
> CONFIG_LOCALVERSION_AUTO before you can interpret the kernel version.  
> In other words, you wouldn't know that "2.6.32-rc4" is actually 200 
> commits beyond the actual release unless you also know that the 
> .config has CONFIG_LOCALVERSION_AUTO="none".

We've come a full circle ...

That's the current !CONFIG_LOCALVERSION_AUTO status quo ... That was 
being asked to be preserved for (unspecified) packaging reasons. So
your suggestion is to do away with that behavior altogether?

	Ingo

Re: [PATCH, v2] kbuild: Improve version string logic

[David Rientjes]

On Wed, 14 Oct 2009, Ingo Molnar wrote:

> > I don't think you want to do that because it would require the .config 
> > to be posted on bug reports, for example, to determine the setting of 
> > CONFIG_LOCALVERSION_AUTO before you can interpret the kernel version.  
> > In other words, you wouldn't know that "2.6.32-rc4" is actually 200 
> > commits beyond the actual release unless you also know that the 
> > .config has CONFIG_LOCALVERSION_AUTO="none".
> 
> We've come a full circle ...
> 
> That's the current !CONFIG_LOCALVERSION_AUTO status quo ... That was 
> being asked to be preserved for (unspecified) packaging reasons. So
> your suggestion is to do away with that behavior altogether?
> 

I don't think it's helpful to specify a version as "2.6.32-rc4" when in 
reality it has 200 commits beyond the release and I like the addition of 
`+' for !CONFIG_LOCALVERSION_AUTO if we're not at a tagged commit.  
That's what my two patches do so the only time you could get a 
"2.6.32-rc4" version string is for when it's the equivalent of 
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.32-rc4.tar.bz2 
(and you would actually get that regardless of whether you're using 
CONFIG_LOCALVERSION_AUTO or not).

There's another possible extension that could be made: we could allow 
LOCALVERSION= as passed to "make" to override the added `+' since it is 
used to identify kernel versions by a string anyway; so make 
LOCALVERSION=-slub_fixes would become v2.6.32-rc4-slub_fixes if 
CONFIG_LOCALVERSION_AUTO were disabled, regardless of what commit we're 
at, and v2.6.32-rc4-slub_fixes-00094-g80f5069 if it were enabled.

Regardless of future improvements, I think my two patches allow the kernel 
version to more accurately describe what is running.  That is predicated 
on my belief that "v2.6.32-rc4", though, should never describe _anything_ 
except the kernel.org v2.6.32-rc4 kernel.

Re: [PATCH, v2] kbuild: Improve version string logic

[Ingo Molnar]

* David Rientjes <rientjes@google.com> wrote:

> On Wed, 14 Oct 2009, Ingo Molnar wrote:
> 
> > > I don't think you want to do that because it would require the .config 
> > > to be posted on bug reports, for example, to determine the setting of 
> > > CONFIG_LOCALVERSION_AUTO before you can interpret the kernel version.  
> > > In other words, you wouldn't know that "2.6.32-rc4" is actually 200 
> > > commits beyond the actual release unless you also know that the 
> > > .config has CONFIG_LOCALVERSION_AUTO="none".
> > 
> > We've come a full circle ...
> > 
> > That's the current !CONFIG_LOCALVERSION_AUTO status quo ... That was 
> > being asked to be preserved for (unspecified) packaging reasons. So
> > your suggestion is to do away with that behavior altogether?
> > 
> 
> I don't think it's helpful to specify a version as "2.6.32-rc4" when 
> in reality it has 200 commits beyond the release and I like the 
> addition of `+' for !CONFIG_LOCALVERSION_AUTO if we're not at a tagged 
> commit.  That's what my two patches do so the only time you could get 
> a "2.6.32-rc4" version string is for when it's the equivalent of 
> http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.32-rc4.tar.bz2 
> (and you would actually get that regardless of whether you're using 
> CONFIG_LOCALVERSION_AUTO or not).
> 
> There's another possible extension that could be made: we could allow 
> LOCALVERSION= as passed to "make" to override the added `+' since it 
> is used to identify kernel versions by a string anyway; so make 
> LOCALVERSION=-slub_fixes would become v2.6.32-rc4-slub_fixes if 
> CONFIG_LOCALVERSION_AUTO were disabled, regardless of what commit 
> we're at, and v2.6.32-rc4-slub_fixes-00094-g80f5069 if it were 
> enabled.
> 
> Regardless of future improvements, I think my two patches allow the 
> kernel version to more accurately describe what is running.  That is 
> predicated on my belief that "v2.6.32-rc4", though, should never 
> describe _anything_ except the kernel.org v2.6.32-rc4 kernel.

I agree with all that - in fact i started this thread by stating that 
view and suggesting the '+' extension to the short version name.

But there's been packaging related objections from Frans and others, and 
i suspect you'll need to answer/address those instead of further 
detailing the virtues of proper version names (which i still 100% agree 
with).

Btw., i only minimally agree with the packaging objections: there's 
certainly no harm in enabling for folks to still keep things as they 
were for years. But we can definitely change the default and we can make 
it difficult to choose the faulty short-name scheme.

Thanks,

	Ingo

Re: [PATCH, v2] kbuild: Improve version string logic

[David Rientjes]

On Wed, 14 Oct 2009, Ingo Molnar wrote:

> > Regardless of future improvements, I think my two patches allow the 
> > kernel version to more accurately describe what is running.  That is 
> > predicated on my belief that "v2.6.32-rc4", though, should never 
> > describe _anything_ except the kernel.org v2.6.32-rc4 kernel.
> 
> I agree with all that - in fact i started this thread by stating that 
> view and suggesting the '+' extension to the short version name.
> 

Yeah, my patches build upon the base that you originally proposed.  I like 
the `+' suffix for configs with CONFIG_LOCALVERSION_AUTO that aren't 
vanilla kernels.

> But there's been packaging related objections from Frans and others, and 
> i suspect you'll need to answer/address those instead of further 
> detailing the virtues of proper version names (which i still 100% agree 
> with).
> 

We could easily go with my suggestion of allowing "make LOCALVERSION=" to 
override all additions to the kernel version when CONFIG_LOCALVERSION_AUTO 
is disabled.  For such configurations, kernels would be built with this 
variable to specify how it's different from the vanilla version and would 
suppress the `+'.

Frans and others, how does adding a unique string passed by the user for a 
more descriptive kernel version interact poorly with certain packaging 
requirements?

Re: [PATCH, v2] kbuild: Improve version string logic

[Frans Pop]

On Wednesday 14 October 2009, David Rientjes wrote:
> On Tue, 13 Oct 2009, Linus Torvalds wrote:
> > Let's keep the old behavior by making the AUTO option an three-way
> > choice ("none", "short", "auto"), and making sure that it actually
> > takes work to choose "none" (and that "make oldconfig" doesn't choose
> > it unless you explicitly made the choice before - so people who just
> > re-use old .config files wouldn't get "none" by mistake).

I'm working on a patch that implements this; will post it later.

> I don't think you want to do that because it would require the .config
> to be posted on bug reports, for example, to determine the setting of
> CONFIG_LOCALVERSION_AUTO before you can interpret the kernel version. 
> In other words, you wouldn't know that "2.6.32-rc4" is actually 200
> commits beyond the actual release unless you also know that the .config
> has CONFIG_LOCALVERSION_AUTO="none".

Even with this patch you can never be 100% sure of that, for example 
because you cannot be 100% certain that a kernel was built from a tree 
that's under revision control. The most *any* change can do is increase 
the likelyhood that we get that information in the version number.

Will explain more in a different reply later.

> Signed-off-by: David Rientjes <rientjes@google.com>
> ---
>  Makefile |   32 ++++++++++++++++++++------------
>  1 files changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -898,9 +898,13 @@ $(vmlinux-dirs): prepare scripts
>  #	  $(localver)
>  #	    localversion*		(files without backups, containing '~')
>  #	    $(CONFIG_LOCALVERSION)	(from kernel config setting)
> -#	  $(localver-auto)		(only if CONFIG_LOCALVERSION_AUTO is set)
> -#	    ./scripts/setlocalversion	(SCM tag, if one exists)
> -#	    $(LOCALVERSION)		(from make command line if provided)
> +#	    $(LOCALVERSION)		(from make command line, if provided)
> +#	  $(localver-extra)
> +#	    $(scm-identifier)		(unique SCM tag, if one exists)
> +#	      ./scripts/setlocalversion	(only with CONFIG_LOCALVERSION_AUTO)
> +#	      .scmversion		(only with CONFIG_LOCALVERSION_AUTO)
> +#	    +				(only without CONFIG_LOCALVERSION_AUTO
> +#					 and repository is at non-tagged commit)
>  #
>  #  Note how the final $(localver-auto) string is included *only* if the

You forgot to change the $(localver-auto) here; and maybe also remove that 
leading space in this line.

Re: [PATCH, v2] kbuild: Improve version string logic

[Frans Pop]

On Wednesday 14 October 2009, David Rientjes wrote:
> On Wed, 14 Oct 2009, Ingo Molnar wrote:
> Yeah, my patches build upon the base that you originally proposed.  I
> like the `+' suffix for configs with CONFIG_LOCALVERSION_AUTO that
> aren't vanilla kernels.

That is fine for custom kernels. I still maintain that it is hopelessly
wrong for distro kernels.

Distro kernels generally have their own naming schemes.
Debian uses: 2.6.30-2-amd64 (<version>-<ABI>-<flavor>)
Fedora uses: 2.6.30.5-43.fc11.i586

And those kernel versions implicitly already contain the information that
they are not vanilla kernels. So a "+" suffix is totally redundant.

My main argument is that if they build kernels from an SCM, which is quite
likely, they should not suddenly get a "+" appended to those versions.
And IMO they should also not have to patch the Makefile to avoid it.
If this change is made, it should be made in such a way that old version
naming schemes are still possible.

> > But there's been packaging related objections from Frans and others,

I'm personally not convinced that there are actual *technical* packaging
issues, at least not for Debian (see my posts elsewhere in the thread).

However, it is very much possible that the change will break random
scripts that are in use and that expect a certain naming scheme.
Having an out would help those cases as well.

> > and i suspect you'll need to answer/address those instead of further
> > detailing the virtues of proper version names (which i still 100%
> > agree with).
>
> We could easily go with my suggestion of allowing "make LOCALVERSION="
> to override all additions to the kernel version when
> CONFIG_LOCALVERSION_AUTO is disabled.  For such configurations, kernels
> would be built with this variable to specify how it's different from the
> vanilla version and would suppress the `+'.

Using LOCALVERSION= for that would be wrong as it is on a different level
from AUTOVERSION. They should be independent. However, that basic approach
of using an environment variable is certainly an option.

And, while I was working on the patch to implement a tristate AUTOVERSION,
I thought of a very common use case that IMO we do want to cover here.

Many users build custom kernels using a distro config as starting point.
The distro does not want the "+", but we very much _do_ want it in the
custom kernel built by the user.
So the conclusion is that suppressing the "+" is simply not something that
can be set in the config, and thus the tristate solution is wrong.
Only alternative I see is that it must be a build option.

So I propose the following patch on top of the patch proposed by David.
It offers a clean out for users who explicitly do not want *any* SCM-based
suffix added to their kernel version, and is IMO both 1) obvious enough
for expert users and 2) obscure enough that regular users are unlikely to
abuse it. Is that acceptable?

The patch also fixes up the comment I mentioned earlier. The old comment
was outdated anyway and partially made redundant by the change David
already made in the later comment. And it has a typo fix.

David: I think it would be best to just merge this into your patch.

diff --git a/Makefile b/Makefile
index 24e54fd..6fcaba7 100644
--- a/Makefile
+++ b/Makefile
@@ -906,10 +906,8 @@ $(vmlinux-dirs): prepare scripts
 #	    +				(only without CONFIG_LOCALVERSION_AUTO
 #					 and repository is at non-tagged commit)
 #
-#  Note how the final $(localver-auto) string is included *only* if the
-# kernel config option CONFIG_LOCALVERSION_AUTO is selected.  Also, at the
-# moment, only git is supported but other SCMs can edit the script
-# scripts/setlocalversion and add the appropriate checks as needed.
+# Note that the final $(localver-extra) string can be suppressed by setting
+# the environment variable KBUILD_NO_LOCALVERSION_EXTRA.
 
 pattern = ".*/localversion[^~]*"
 string  = $(shell cat /dev/null \
@@ -923,9 +921,11 @@ localver = $(subst $(space),, $(string) \
 # tagged (release) commit.  The format of the identifier is determined by the
 # SCM's implementation.
 #
-# .scmversion is used when generating rpm packages so we do not loose
+# .scmversion is used when generating rpm packages so we do not lose
 # the version information from the SCM when we do the build of the kernel
 # from the copied source
+ifndef KBUILD_NO_LOCALVERSION_EXTRA
+
 ifeq ($(wildcard .scmversion),)
         scm-identifier = $(shell $(CONFIG_SHELL) \
                          $(srctree)/scripts/setlocalversion $(srctree))
@@ -941,6 +941,8 @@ else
 	endif
 endif
 
+endif # ifndef KBUILD_NO_LOCALVERSION_EXTRA
+
 localver-full = $(localver)$(LOCALVERSION)$(localver-extra)
 
 # Store (new) KERNELRELASE string in include/config/kernel.release

Re: [PATCH, v2] kbuild: Improve version string logic

[David Rientjes]

On Thu, 15 Oct 2009, Frans Pop wrote:

> That is fine for custom kernels. I still maintain that it is hopelessly
> wrong for distro kernels.
> 
> Distro kernels generally have their own naming schemes.
> Debian uses: 2.6.30-2-amd64 (<version>-<ABI>-<flavor>)
> Fedora uses: 2.6.30.5-43.fc11.i586
> 
> And those kernel versions implicitly already contain the information that
> they are not vanilla kernels. So a "+" suffix is totally redundant.
> 

And that's why I suggested, in addition to my patch, that we allow "make 
LOCALVERSION=" to override the `+' suffix for kernels compiled without 
CONFIG_LOCALVERSION_AUTO.  In your examples, they would pass 
LOCALVERSION=-2-amd64 or LOCALVERSION=-43.fc11.i586, respectively, to 
make.

> My main argument is that if they build kernels from an SCM, which is quite
> likely, they should not suddenly get a "+" appended to those versions.
> And IMO they should also not have to patch the Makefile to avoid it.
> If this change is made, it should be made in such a way that old version
> naming schemes are still possible.
> 

They are, with my suggestion to allow make LOCALVERSION= to override the 
`+'.  The question I posed directly to you was this: how does adding a 
unique string passed by the user for a more descriptive kernel version 
interact poorly with certain packaging requirements?  You've given two 
examples that are _perfect_ use cases for my suggestion.

> > We could easily go with my suggestion of allowing "make LOCALVERSION="
> > to override all additions to the kernel version when
> > CONFIG_LOCALVERSION_AUTO is disabled.  For such configurations, kernels
> > would be built with this variable to specify how it's different from the
> > vanilla version and would suppress the `+'.
> 
> Using LOCALVERSION= for that would be wrong as it is on a different level
> from AUTOVERSION. They should be independent. However, that basic approach
> of using an environment variable is certainly an option.
> 

Now I'm confused, because currently LOCALVERSION= can only be used when 
CONFIG_LOCALVERSION_AUTO is defined; in other words, it's completely 
dependent on it.  My patch changes that and seems to be your desire as 
well?

> So I propose the following patch on top of the patch proposed by David.
> It offers a clean out for users who explicitly do not want *any* SCM-based
> suffix added to their kernel version, and is IMO both 1) obvious enough
> for expert users and 2) obscure enough that regular users are unlikely to
> abuse it. Is that acceptable?
> 

No, it actually makes things much worse because now instead of forcing the 
user to post his .config to determine the setting of 
CONFIG_LOCALVERSION_AUTO to intepret the version string, it forces them to 
recall what their KBUILD_NO_LOCALVERSION_EXTRA environment variable 
happened to be at the time of build.

Re: [PATCH, v2] kbuild: Improve version string logic

[David Rientjes]

On Wed, 14 Oct 2009, David Rientjes wrote:

> We could easily go with my suggestion of allowing "make LOCALVERSION=" to 
> override all additions to the kernel version when CONFIG_LOCALVERSION_AUTO 
> is disabled.  For such configurations, kernels would be built with this 
> variable to specify how it's different from the vanilla version and would 
> suppress the `+'.
> 

The following patch implements this suggestion and folds both of my 
proposed patches together.


kbuild: improve version string logic

The LOCALVERSION= string passed to "make" will now always be appended to
the kernel version after CONFIG_LOCALVERSION, if it exists, regardless of
whether CONFIG_LOCALVERSION_AUTO is set or not.  This allows users to
uniquely identify their kernel builds with a string.

scripts/setlocalversion will now always be called to determine whether
the repository is beyond a tagged (release) commit.  When at a tagged
commit, this script will now suppress all output.

If CONFIG_LOCALVERSION_AUTO is enabled, the unique SCM tag reported by 
setlocalversion (or .scmversion) is appended to the kernel version, if it 
exists.  When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
to the kernel version to represent that the kernel has been revised since
the last release unless "make LOCALVERSION=" was used to uniquely identify
the build.

The end result is this:

 - when LOCALVERSION= is passed to "make", it is appended to the kernel
   version,

 - when CONFIG_LOCALVERSION_AUTO is enabled, a unique SCM identifier is
   appended if the respository has been revised beyond a tagged commit,
   and

 - when CONFIG_LOCALVERSION_AUTO is disabled, a `+' is appended if the 
   repository has been revised beyond a tagged commit and LOCALVERSION=
   was not passed to "make".

Examples:

With CONFIG_LOCALVERSION_AUTO: "make" results in
v2.6.32-rc4-00149-ga3ccf63.  If there are uncommited changes to the
respository, it results in v2.6.32-rc4-00149-ga3ccf63-dirty.  If
"make LOCALVERSION=kbuild" were used, it results in
v2.6.32-rc4-kbuild-00149-ga3ccf63-dirty.

Without CONFIG_LOCALVERSION_AUTO, "make" results in v2.6.32-rc4+
unless the repository is at the Linux v2.6.32-rc4 commit (in which
case the version would be v2.6.32-rc4).  If "make LOCALVERSION=kbuild"
were used, it results in v2.6.32-rc4-kbuild.

Also renames variables such as localver-auto and _localver-auto to more 
accurately describe what they represent: localver-extra and
scm-identifier, respectively.

Signed-off-by: David Rientjes <rientjes@google.com>
---
 Makefile                |   43 +++++++++++++++++++++++++++----------------
 scripts/setlocalversion |    3 ++-
 2 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -898,14 +898,19 @@ $(vmlinux-dirs): prepare scripts
 #	  $(localver)
 #	    localversion*		(files without backups, containing '~')
 #	    $(CONFIG_LOCALVERSION)	(from kernel config setting)
-#	  $(localver-auto)		(only if CONFIG_LOCALVERSION_AUTO is set)
-#	    ./scripts/setlocalversion	(SCM tag, if one exists)
-#	    $(LOCALVERSION)		(from make command line if provided)
+#	    $(LOCALVERSION)		(from make command line, if provided)
+#	  $(localver-extra)
+#	    $(scm-identifier)		(unique SCM tag, if one exists)
+#	      ./scripts/setlocalversion	(only with CONFIG_LOCALVERSION_AUTO)
+#	      .scmversion		(only with CONFIG_LOCALVERSION_AUTO)
+#	    +				(only without CONFIG_LOCALVERSION_AUTO
+#					 and without LOCALVERSION= and 
+#					 repository is at non-tagged commit)
 #
-#  Note how the final $(localver-auto) string is included *only* if the
-# kernel config option CONFIG_LOCALVERSION_AUTO is selected.  Also, at the
-# moment, only git is supported but other SCMs can edit the script
-# scripts/setlocalversion and add the appropriate checks as needed.
+# For kernels without CONFIG_LOCALVERSION_AUTO compiled from an SCM that has
+# been revised beyond a tagged commit, `+' is appended to the version string
+# when not overridden by using "make LOCALVERSION=".  This indicates that the
+# kernel is not a vanilla release version and has been modified.
 
 pattern = ".*/localversion[^~]*"
 string  = $(shell cat /dev/null \
@@ -914,26 +919,32 @@ string  = $(shell cat /dev/null \
 localver = $(subst $(space),, $(string) \
 			      $(patsubst "%",%,$(CONFIG_LOCALVERSION)))
 
-# If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called
-# and if the SCM is know a tag from the SCM is appended.
-# The appended tag is determined by the SCM used.
+# scripts/setlocalversion is called to create a unique identifier if the source
+# is managed by a known SCM and the repository has been revised since the last
+# tagged (release) commit.  The format of the identifier is determined by the
+# SCM's implementation.
 #
 # .scmversion is used when generating rpm packages so we do not loose
 # the version information from the SCM when we do the build of the kernel
 # from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
 ifeq ($(wildcard .scmversion),)
-        _localver-auto = $(shell $(CONFIG_SHELL) \
+        scm-identifier = $(shell $(CONFIG_SHELL) \
                          $(srctree)/scripts/setlocalversion $(srctree))
 else
-        _localver-auto = $(shell cat .scmversion 2> /dev/null)
+        scm-identifier = $(shell cat .scmversion 2> /dev/null)
 endif
 
-	localver-auto  = $(LOCALVERSION)$(_localver-auto)
+ifdef CONFIG_LOCALVERSION_AUTO
+	localver-extra = $(scm-identifier)
+else
+	ifneq ($scm-identifier,)
+		ifeq ($(LOCALVERSION),)
+			localver-extra = +
+		endif
+	endif
 endif
 
-localver-full = $(localver)$(localver-auto)
+localver-full = $(localver)$(LOCALVERSION)$(localver-extra)
 
 # Store (new) KERNELRELASE string in include/config/kernel.release
 kernelrelease = $(KERNELVERSION)$(localver-full)
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -26,7 +26,8 @@ if head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
 		# If we are past a tagged commit (like "v2.6.30-rc5-302-g72357d5"),
 		# we pretty print it.
 		if atag="`git describe 2>/dev/null`"; then
-			echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'
+			echo "$atag" | awk -F- 'int($(NF-1)) > 0	\
+					{printf("-%05d-%s", $(NF-1),$(NF))}'
 
 		# If we don't have a tag at all we print -g{commitish}.
 		else

Re: [PATCH, v2] kbuild: Improve version string logic

[Ingo Molnar]

* David Rientjes <rientjes@google.com> wrote:

> On Wed, 14 Oct 2009, David Rientjes wrote:
> 
> > We could easily go with my suggestion of allowing "make LOCALVERSION=" to 
> > override all additions to the kernel version when CONFIG_LOCALVERSION_AUTO 
> > is disabled.  For such configurations, kernels would be built with this 
> > variable to specify how it's different from the vanilla version and would 
> > suppress the `+'.
> > 
> 
> The following patch implements this suggestion and folds both of my 
> proposed patches together.

thanks David!

Acked-by: Ingo Molnar <mingo@elte.hu>

	Ingo

Re: [PATCH, v2] kbuild: Improve version string logic

[Ingo Molnar]

* Frans Pop <elendil@planet.nl> wrote:

> On Wednesday 14 October 2009, David Rientjes wrote:
> > On Wed, 14 Oct 2009, Ingo Molnar wrote:
> > Yeah, my patches build upon the base that you originally proposed.  I
> > like the `+' suffix for configs with CONFIG_LOCALVERSION_AUTO that
> > aren't vanilla kernels.
> 
> That is fine for custom kernels. I still maintain that it is hopelessly
> wrong for distro kernels.
> 
> Distro kernels generally have their own naming schemes.
> Debian uses: 2.6.30-2-amd64 (<version>-<ABI>-<flavor>)
> Fedora uses: 2.6.30.5-43.fc11.i586
> 
> And those kernel versions implicitly already contain the information 
> that they are not vanilla kernels. So a "+" suffix is totally 
> redundant.

It's not "totally redundant" _AT ALL_.

"2.6.30+-2-amd64" tells us that not only do we have the usual per distro 
patches on top of vanilla .30 (which patches can be found in the deb or 
src.rpm), but we _ALSO_ have extra _vanilla kernel_ commits since 
v2.6.30.

So it is very much meaningful. If i hunt a weird bug visible in a distro 
but not visible in my reproduction, i will be alerted to the fact that 
the distro isnt using a precise tag as a base but something inbetween.

That is useful information. Why do you keep insisting that it's "totally 
redundant"? It is clearly not. It's a property of the upstream kernel 
version - any per distro pile of patches on top of that is a different 
space. _Both_ pieces of information are important - that's why Debian 
put that -5 there.

Besides, distros building on kernels inbetween -rc's is very rare. If it 
happens it's sufficiently unusual to alert users to that fact via the 
'+' sign. The '+' sign will go away if a distro uses a precise upstream 
version.

	Ingo

Re: [PATCH, v2] kbuild: Improve version string logic

[Frans Pop]

On Thursday 15 October 2009, David Rientjes wrote:
> And that's why I suggested, in addition to my patch, that we allow "make
> LOCALVERSION=" to override the `+' suffix for kernels compiled without
> CONFIG_LOCALVERSION_AUTO.  In your examples, they would pass
> LOCALVERSION=-2-amd64 or LOCALVERSION=-43.fc11.i586, respectively, to
> make.

Who says they are using LOCALVERSION to add the suffix?

> > My main argument is that if they build kernels from an SCM, which is
> > quite likely, they should not suddenly get a "+" appended to those
> > versions. And IMO they should also not have to patch the Makefile to
> > avoid it. If this change is made, it should be made in such a way that
> > old version naming schemes are still possible.
>
> They are, with my suggestion to allow make LOCALVERSION= to override the
> `+'.  The question I posed directly to you was this: how does adding a
> unique string passed by the user for a more descriptive kernel version
> interact poorly with certain packaging requirements?  You've given two
> examples that are _perfect_ use cases for my suggestion.

I'm not a Debian kernel maintainer, so I cannot answer that question. I 
will alert the Debian kernel team to this discussion so they can respond 
for themselves.

The thing is that you are assuming people do things in a certain way and 
your patches will break existing naming schemes for anybody who happens to 
do things slightly differently. My proposal offered full backwards 
compatibility for people who know what they are doing.

> > Using LOCALVERSION= for that would be wrong as it is on a different
> > level from AUTOVERSION. They should be independent. However, that
> > basic approach of using an environment variable is certainly an
> > option.
>
> Now I'm confused, because currently LOCALVERSION= can only be used when
> CONFIG_LOCALVERSION_AUTO is defined; in other words, it's completely
> dependent on it.  My patch changes that and seems to be your desire as
> well?

That change seemed logical to me. And I did say my patch was on top of 
yours, so yes, my comment was based on that change being implemented.

> > So I propose the following patch on top of the patch proposed by
> > David. It offers a clean out for users who explicitly do not want
> > *any* SCM-based suffix added to their kernel version, and is IMO both
> > 1) obvious enough for expert users and 2) obscure enough that regular
> > users are unlikely to abuse it. Is that acceptable?
>
> No, it actually makes things much worse because now instead of forcing
> the user to post his .config to determine the setting of
> CONFIG_LOCALVERSION_AUTO to intepret the version string, it forces them
> to recall what their KBUILD_NO_LOCALVERSION_EXTRA environment variable
> happened to be at the time of build.

As I've already said, I think that build variable is sufficiently obscure 
that I expect it will only be used by people who know what they are doing.

And I can only repeat that even with your patch you will never get 100% 
coverage. People who really don't want the "+" will simply patch it out. 
Why not give them a clean way to avoid it?

Re: [PATCH, v2] kbuild: Improve version string logic

[Frans Pop]

On Thursday 15 October 2009, Ingo Molnar wrote:
> > Distro kernels generally have their own naming schemes.
> > Debian uses: 2.6.30-2-amd64 (<version>-<ABI>-<flavor>)
> > Fedora uses: 2.6.30.5-43.fc11.i586
> >
> > And those kernel versions implicitly already contain the information
> > that they are not vanilla kernels. So a "+" suffix is totally
> > redundant.
>
> It's not "totally redundant" _AT ALL_.
>
> "2.6.30+-2-amd64" tells us that not only do we have the usual per distro

But it would not be "2.6.30+-2-amd64"; it would become "2.6.30-2-amd64+", 
which IMO sucks.

> patches on top of vanilla .30 (which patches can be found in the deb or
> src.rpm), but we _ALSO_ have extra _vanilla kernel_ commits since
> v2.6.30.

This is where you are wrong. Yes, the patches are in the deb [1], but how 
do they end up there? The distro patches themselves are also maintained in 
an SCM, quite possibly as a branch from mainline, and the package 
maintainers will build *from* that SCM. So *the distro patches themselves* 
will trigger the "+".

You simply cannot distinguish between "extra vanilla kernel commits" 
and "distro commits" in a tree. Both are changes since the tagged release; 
both will trigger the "+", which makes the "+" meaningless.

Also, any distro cherry-picks upstream patches from later versions 
as "distro patches" (at least, that's the case for over 90% of the patches 
in Debian stable kernels). And we already know such patches are included 
whenever we see a distro kernel version, so I still think having the "+" 
does not add any meaningful information.

> Besides, distros building on kernels inbetween -rc's is very rare.

True. Which is why we shouldn't be adding the "+".

> If it happens it's sufficiently unusual to alert users to that fact via
> the '+' sign. The '+' sign will go away if a distro uses a precise
> upstream version.

But that's the whole point. It does not!
Even if they _only_ add their packaging infrastructure on top and have no 
patches that affect the the kernel itself (which is unlikely), they would 
still end up with the "+" because the commit(s) that add the packaging 
infrastructure make the tree unequal to the tagged release.

Cheers,
FJP

[1] Actually they are in the .diff.gz, which contains all changes relative 
to the original tarball, but I understand what you mean.

Re: Linux 2.6.32-rc3

[Frans Pop]

Ingo Molnar wrote:
> hm, i think you ignored (or missed, or found irrelevant) my first
> suggested variant:
> 
> v2.6.31
> v2.6.31+

A general concern about adding the "+".

Anyone want to bet how many (init?) scripts there are in userspace that do 
something like:

KVERS="$(uname -r | cut -d"-" -f1)"
case $KVERS in
  2.6.*)
    minor=$(echo $KVERS | cut -d"." -f3)
    if [ $minor -lt 10 ]; then
      # do something
    fi ;;
esac

Note that the '[ $minor -lt 10 ]' will now produce an error because
'31+' is no longer a valid number:
   bash: [: 31+: integer expression expected

A "-" has for ages been the standard separator between the kernel version 
and any suffixes, certainly in Debian. Loads of scripts will assume that.

In an earlier mail I said that I would consider using the "+". This is 
seriously making me have second thoughts, even for custom built kernels.


Here are some real life examples from my Debian stable system:
/etc/init.d/pcmciautils:
supported_kernel()
{
    case $KERNEL_VERSION in
        2.[012345].*|2.6.[0-9]|2.6.[0-9][!0-9]*) return 1 ;;
        2.6.1[012]|2.6.1[012][!0-9]*) return 1 ;;
    esac
    return 0
}

Would have failed for e.g. a 2.6.12+ kernel.

/etc/init.d/umountnfs.sh:
KERNEL="$(uname -s)"
RELEASE="$(uname -r)"
case "${KERNEL}:${RELEASE}" in
  Linux:[01].*|Linux:2.[01].*)
        FLAGS=""
        ;;
  Linux:2.[23].*|Linux:2.4.?|Linux:2.4.?-*|Linux:2.4.10|Linux:2.4.10-*)
        FLAGS="-f"
        ;;
  *)
        FLAGS="-f -l"
        ;;
esac

Would have failed for e.g. a 2.4.7+ kernel.

Sure, these won't fail if we start adding the "+" now, but will the people 
writing such tests in the future always remember to allow for the "+", 
especially given that it will be relatively rare in a distro context?

Cheers,
FJP

Re: [PATCH, v2] kbuild: Improve version string logic

[David Rientjes]

On Thu, 15 Oct 2009, Frans Pop wrote:

> > And that's why I suggested, in addition to my patch, that we allow "make
> > LOCALVERSION=" to override the `+' suffix for kernels compiled without
> > CONFIG_LOCALVERSION_AUTO.  In your examples, they would pass
> > LOCALVERSION=-2-amd64 or LOCALVERSION=-43.fc11.i586, respectively, to
> > make.
> 
> Who says they are using LOCALVERSION to add the suffix?
> 

You would prefer that CONFIG_LOCALVERSION overrides the `+' when 
CONFIG_LOCALVERSION_AUTO is disabled?

> The thing is that you are assuming people do things in a certain way and 
> your patches will break existing naming schemes for anybody who happens to 
> do things slightly differently. My proposal offered full backwards 
> compatibility for people who know what they are doing.
> 

Your proposal doesn't work because the context (the state of an 
environment variable at build, in your case) isn't known to interpret the 
version string.

The point is that you should be able to look at a kernel version without 
asking for enviornment variables or configs and know what kernel is 
running.  That's not always going to be valid, someone can make additional 
changes outside of a git respository and use it, but the net impact is 
that versions have become much more descriptive from a large majority of 
the general population that posts to linux-kernel, git users, and it's 
going to save a lot of time.

> > No, it actually makes things much worse because now instead of forcing
> > the user to post his .config to determine the setting of
> > CONFIG_LOCALVERSION_AUTO to intepret the version string, it forces them
> > to recall what their KBUILD_NO_LOCALVERSION_EXTRA environment variable
> > happened to be at the time of build.
> 
> As I've already said, I think that build variable is sufficiently obscure 
> that I expect it will only be used by people who know what they are doing.
> 

Do you really expect people to email bug reports and say "btw, I compiled 
with KBUILD_NO_LOCALVERSION_EXTRA because I thought it looked prettier, 
this is actually Linus' git at a3ccf63"?

> And I can only repeat that even with your patch you will never get 100% 
> coverage. People who really don't want the "+" will simply patch it out. 
> Why not give them a clean way to avoid it?
> 

Sigh, this is becoming ridiculous.  If you're doing development and have 
revisions beyond a tagged release, then why would you want the version to 
still be "v2.6.32-rc4" without giving it a descriptive name of your own?  
Why wouldn't you use LOCALVERSION=-slub_merge, for example, to describe 
what the kernel was?  The scenario you're describing is where everyone has 
100 different v2.6.32-rc4 kernels sitting around because they've disabled 
CONFIG_LOCALVERSION_AUTO and aren't able to tell the difference between 
them.  That's just a poor work environment.

 [ I can understand if you frequently do build and boot testing, but even 
   then you can get rid of that `+' very easily by giving it a descriptive 
   LOCALVERSION= name if `+' causes you so much grief. ]

Re: [PATCH, v2] kbuild: Improve version string logic

[David Rientjes]

On Thu, 15 Oct 2009, Frans Pop wrote:

> You simply cannot distinguish between "extra vanilla kernel commits" 
> and "distro commits" in a tree. Both are changes since the tagged release; 
> both will trigger the "+", which makes the "+" meaningless.
> 

I can guarantee that distro is not going to be releasing a "v2.6.33" 
kernel with patches on top of it without modifying the version string in 
some way.  With my patch, the `+' is suppressed when LOCALVERSION= is 
used.

I chose not to allow CONFIG_LOCALVERSION to suppress the `+' because the 
config normally does not change with a revision, a build does.  So while 
CONFIG_LOCALVERSION may describe the packager of the kernel, LOCALVERSION= 
would describe a particular release.

> > Besides, distros building on kernels inbetween -rc's is very rare.
> 
> True. Which is why we shouldn't be adding the "+".
> 

The `+' is irrelevant at -rc releases, it wouldn't be added anyway!  It's 
purpose is to identify non-vanilla release kernels.

> But that's the whole point. It does not!
> Even if they _only_ add their packaging infrastructure on top and have no 
> patches that affect the the kernel itself (which is unlikely), they would 
> still end up with the "+" because the commit(s) that add the packaging 
> infrastructure make the tree unequal to the tagged release.
> 

Why would you add packaging infrastructure to the kernel source itself?  
Normally you would have a Makefile for rpm packaging that would call into 
the kernel Makefile, leaving it vanilla.

Re: [PATCH, v2] kbuild: Improve version string logic

[Frans Pop]

On Thursday 15 October 2009, David Rientjes wrote:
> Sigh, this is becoming ridiculous.

Yes, I thoroughly agree. I'm afraid I don't see much point in repeating my 
arguments anymore.

We seem to be unable to get eachothers arguments. I think I understand your 
PoV, or at least your aims, and I even agree with those. I don't think you 
really get my concerns about the implementation, but I give up. I seem 
unable to make you understand; probably my limitation. So, let's just 
agree to disagree.

My conclusion in the mean time is that the whole concept of having the "+" 
is broken. Especially since my discovery earlier today [1] that it is more 
than likely to break existing scripts in userspace (not packaging, but 
regular userspace).

I plan to continue to use my own naming conventions, even if that means I 
have to patch the "+' out of the Makefile. Especially since it seems I 
have to decide between risking breakage in user space and confirming to 
this new standard. And that choice is simple.

> Do you really expect people to email bug reports and say "btw, I
> compiled with KBUILD_NO_LOCALVERSION_EXTRA because I thought it looked
> prettier, this is actually Linus' git at a3ccf63"?

In the current situation I already frequently provide the output of 'git 
describe master' as part of bug reports. Nothing new there. And users will 
*still* need to do that as the "+" does not tell anyone where exactly they 
are at. It could equally be release +50 or +4000 commits.

Cheers.
FJP

[1] http://lkml.org/lkml/2009/10/15/210

Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks

[Boaz Harrosh]

On 10/12/2009 09:57 PM, Ingo Molnar wrote:
> 
> This is basically your original patch that adds '+' to the short version 
> string of kernels that are 'between' -rc tags. (i dropped the '+' within 
> the long version i did in v1 - there were objections against that)
> 
> Would this be ok?
> 

Rrrr. If I wanted CONFIG_LOCALVERSION_AUTO, I would use that one. At least
it is actually useful and informative.

I already have my:
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 35
-EXTRAVERSION = -rc2
+EXTRAVERSION = -rc2-my_tree

Which is managed by a git tree (for everybody based on my tree)

At least give us a way out with:
CONFIG_LOCALVERSION_NO_AUTO_IM_REALLY_STUPID=y way out.

or EXTRAVERSION != $(git version)

But don't leave us cold in the woods like that. (What if I remove the git tree altogether, move to svn)

If I can shoot my self in the foot, it does not mean Government should not issue any more
gun licenses.

I already have my outer Makefile system that makes sure I don't forget to compile, or
"did I install this Kernel or not". Please let us have a way out?

Boaz
> 	Ingo
> 
> -------------->
>>From 597e5b15dd0cbb3158afc438e5edae9986e6b76a Mon Sep 17 00:00:00 2001
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Tue, 6 Oct 2009 09:31:03 -0700
> Subject: [PATCH] kbuild: Improve version string logic
> 
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> way:
> 
>  - if it is set, things work the way they always have, and you get a
>    extended kernel release like:
> 
> 	2.6.32-rc3-00052-g0eca52a
> 
>  - but if it is _not_ set, we'll still try to get a version from the
>    underlying SCM (we actually support git, hg and SVN right now, even if
>    some comments may say "git only"), and if the underlying SCM says it
>    has a local version, we append just "+", so you get a version number
>    like:
> 
> 	2.6.32-rc3+
> 
> IOW, you'd never get 2.6.32-rc0, but you'd get either the complex git
> version number (or SVN/hg/whatever), or at least "2.6.31+" with the "+"
> showing that it is more than plain 2.6.31.
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> Cc: Frans Pop <elendil@planet.nl>
> Cc: Dirk Hohndel <hohndel@infradead.org>
> Cc: Len Brown <lenb@kernel.org>
> LKML-Reference: <20091006173508.GA4786@elte.hu>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  Makefile |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 927d7a3..5dab509 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -963,8 +963,6 @@ localver = $(subst $(space),, $(string) \
>  # .scmversion is used when generating rpm packages so we do not loose
>  # the version information from the SCM when we do the build of the kernel
>  # from the copied source
> -ifdef CONFIG_LOCALVERSION_AUTO
> -
>  ifeq ($(wildcard .scmversion),)
>          _localver-auto = $(shell $(CONFIG_SHELL) \
>                           $(srctree)/scripts/setlocalversion $(srctree))
> @@ -972,7 +970,14 @@ else
>          _localver-auto = $(shell cat .scmversion 2> /dev/null)
>  endif
>  
> +ifdef CONFIG_LOCALVERSION_AUTO
>  	localver-auto  = $(LOCALVERSION)$(_localver-auto)
> +else
> +	ifeq ($_localver-auto,)
> +		localver-auto = $(LOCALVERSION)
> +	else
> +		localver-auto = $(LOCALVERSION)+
> +	endif
>  endif
>  
>  localver-full = $(localver)$(localver-auto)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks

[David Rientjes]

On Mon, 7 Jun 2010, Boaz Harrosh wrote:

> Rrrr. If I wanted CONFIG_LOCALVERSION_AUTO, I would use that one. At least
> it is actually useful and informative.
> 
> I already have my:
>  VERSION = 2
>  PATCHLEVEL = 6
>  SUBLEVEL = 35
> -EXTRAVERSION = -rc2
> +EXTRAVERSION = -rc2-my_tree
> 

You shouldn't be using EXTRAVERSION for this purpose, you should be 
passing LOCALVERSION=my_tree to make.

> Which is managed by a git tree (for everybody based on my tree)
> 
> At least give us a way out with:
> CONFIG_LOCALVERSION_NO_AUTO_IM_REALLY_STUPID=y way out.
> 
> or EXTRAVERSION != $(git version)
> 
> But don't leave us cold in the woods like that. (What if I remove the git tree altogether, move to svn)
> 
> If I can shoot my self in the foot, it does not mean Government should not issue any more
> gun licenses.
> 
> I already have my outer Makefile system that makes sure I don't forget to compile, or
> "did I install this Kernel or not". Please let us have a way out?
> 

Unless it's a vanilla 2.6.35-rc2 kernel, it's inaccurate to persent it as 
2.6.35-rc2; you'll need to pass LOCALVERSION to make to identify this as a 
non-vanilla kernel.

Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks

[Boaz Harrosh]

On 06/07/2010 10:45 PM, David Rientjes wrote:
> On Mon, 7 Jun 2010, Boaz Harrosh wrote:
> 
>> Rrrr. If I wanted CONFIG_LOCALVERSION_AUTO, I would use that one. At least
>> it is actually useful and informative.
>>
>> I already have my:
>>  VERSION = 2
>>  PATCHLEVEL = 6
>>  SUBLEVEL = 35
>> -EXTRAVERSION = -rc2
>> +EXTRAVERSION = -rc2-my_tree
>>
> 
> You shouldn't be using EXTRAVERSION for this purpose, you should be 
> passing LOCALVERSION=my_tree to make.
> 

That will not work because the way I run make is out of my control. Every
one in the working group has his system. The Makefile is part of the
public git tree, so every one will get the same identification without
any confusion with Vanilla kernel, or what was compiled.

>> Which is managed by a git tree (for everybody based on my tree)
>>
>> At least give us a way out with:
>> CONFIG_LOCALVERSION_NO_AUTO_IM_REALLY_STUPID=y way out.
>>
>> or EXTRAVERSION != $(git version)
>>
>> But don't leave us cold in the woods like that. (What if I remove the git tree altogether, move to svn)
>>
>> If I can shoot my self in the foot, it does not mean Government should not issue any more
>> gun licenses.
>>
>> I already have my outer Makefile system that makes sure I don't forget to compile, or
>> "did I install this Kernel or not". Please let us have a way out?
>>
> 
> Unless it's a vanilla 2.6.35-rc2 kernel, it's inaccurate to persent it as 
> 2.6.35-rc2; you'll need to pass LOCALVERSION to make to identify this as a 
> non-vanilla kernel.

What are we lawyers? come on. And I do not have that problem! The output will
not be 2.6.35-rc2 as you fear. It will be 2.6.35-rc2-my-tree-my-version.
A person is checking out my tree will get my version string and the output
name is well defined, and separate from Vanilla Kernel. So even the layers are
happy. (That said, insert the: "I have a right to be stupid ..." mantra)

I don't get it. What is that CONFIG_LOCALVERSION_AUTO. It has become a *no-choice*
option. The system now tells me: "I will poke in your system, if I find it under git,
I slave it. Your choice is to have an ugly "+" sign or a more informative name based
on actual commit number". But that is no-choice don't you see?

Please stop this *none-sense* this is not your place to mandate my Kernel name. If
I'm forced to have an external Makefile I can just "mv" what ever name I choose.
The Kernel name is an ABI you have just broken that, You must revert it ASAP.

Boaz !

Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks

[David Rientjes]

On Tue, 8 Jun 2010, Boaz Harrosh wrote:

> >> I already have my:
> >>  VERSION = 2
> >>  PATCHLEVEL = 6
> >>  SUBLEVEL = 35
> >> -EXTRAVERSION = -rc2
> >> +EXTRAVERSION = -rc2-my_tree
> >>
> > 
> > You shouldn't be using EXTRAVERSION for this purpose, you should be 
> > passing LOCALVERSION=my_tree to make.
> > 
> 
> That will not work because the way I run make is out of my control. Every
> one in the working group has his system. The Makefile is part of the
> public git tree, so every one will get the same identification without
> any confusion with Vanilla kernel, or what was compiled.
> 

If everyone using that tree wants the same version string for that kernel, 
use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make 
LOCALVERSION=".

> > Unless it's a vanilla 2.6.35-rc2 kernel, it's inaccurate to persent it as 
> > 2.6.35-rc2; you'll need to pass LOCALVERSION to make to identify this as a 
> > non-vanilla kernel.
> 
> What are we lawyers? come on. And I do not have that problem! The output will
> not be 2.6.35-rc2 as you fear. It will be 2.6.35-rc2-my-tree-my-version.

That's because you're using EXTRAVERSION which is also used upstream to 
describe kernel releases (stable, rc, mm, etc).

> Please stop this *none-sense* this is not your place to mandate my Kernel name. If
> I'm forced to have an external Makefile I can just "mv" what ever name I choose.
> The Kernel name is an ABI you have just broken that, You must revert it ASAP.
> 

You still have the tools available to do everything you once did.

Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks

[Paul Mundt]

On Mon, Jun 07, 2010 at 11:18:42PM -0700, David Rientjes wrote:
> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
> 
> > >> I already have my:
> > >>  VERSION = 2
> > >>  PATCHLEVEL = 6
> > >>  SUBLEVEL = 35
> > >> -EXTRAVERSION = -rc2
> > >> +EXTRAVERSION = -rc2-my_tree
> > >>
> > > 
> > > You shouldn't be using EXTRAVERSION for this purpose, you should be 
> > > passing LOCALVERSION=my_tree to make.
> > > 
> > 
> > That will not work because the way I run make is out of my control. Every
> > one in the working group has his system. The Makefile is part of the
> > public git tree, so every one will get the same identification without
> > any confusion with Vanilla kernel, or what was compiled.
> > 
> 
> If everyone using that tree wants the same version string for that kernel, 
> use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make 
> LOCALVERSION=".
> 
Or just distribute a localversion-my_tree file in the top-level directory
like other trees do. This doesn't strike me as a particularly significant
problem.

Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks

[Boaz Harrosh]

On 06/08/2010 09:18 AM, David Rientjes wrote:
> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
> 
>>>> I already have my:
>>>>  VERSION = 2
>>>>  PATCHLEVEL = 6
>>>>  SUBLEVEL = 35
>>>> -EXTRAVERSION = -rc2
>>>> +EXTRAVERSION = -rc2-my_tree
>>>>
>>>
>>> You shouldn't be using EXTRAVERSION for this purpose, you should be 
>>> passing LOCALVERSION=my_tree to make.
>>>
>>
>> That will not work because the way I run make is out of my control. Every
>> one in the working group has his system. The Makefile is part of the
>> public git tree, so every one will get the same identification without
>> any confusion with Vanilla kernel, or what was compiled.
>>
> 
> If everyone using that tree wants the same version string for that kernel, 
> use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make 
> LOCALVERSION=".

That does not work I tried LOCALVERSION is checked for emptiness. So the
"plus" is added just the same. I tried:

$ make			# gets a plus
$ make LOCALVERSION=""	# same plus

CONFIG_LOCALVERSION will not work because it, too, is not in the git. I need
something that everyone can get by checkout. (The config file is usually a
distro config with make oldconfig)

> 
>>> Unless it's a vanilla 2.6.35-rc2 kernel, it's inaccurate to persent it as 
>>> 2.6.35-rc2; you'll need to pass LOCALVERSION to make to identify this as a 
>>> non-vanilla kernel.
>>
>> What are we lawyers? come on. And I do not have that problem! The output will
>> not be 2.6.35-rc2 as you fear. It will be 2.6.35-rc2-my-tree-my-version.
> 
> That's because you're using EXTRAVERSION which is also used upstream to 
> describe kernel releases (stable, rc, mm, etc).
> 

That's why it is perfect. Because I have that patch as first in my tree that
changes that in Makefile. Then from time to time when I rebase I get the
conflict with Linus change of the name, and have the privilege to specify how
this is a different tree, with a different name and version. It is all git work
no external factors. (That I will keep, regardless of plus or no plus)

And you have not answered my question:
  What does the CONFIG_LOCALVERSION_AUTO give me? the name is changed regardless
  so now it has become. Min-Auto-Name or Informative-Auto-Name. It used to be
  Auto-name-yes or Auto-Name-no. Please change the config name to reflect the choice
  we actually have. (And keep the old config because we need the original choice)

>> Please stop this *none-sense* this is not your place to mandate my Kernel name. If
>> I'm forced to have an external Makefile I can just "mv" what ever name I choose.
>> The Kernel name is an ABI you have just broken that, You must revert it ASAP.
>>
> 
> You still have the tools available to do everything you once did.

No! how? I couldn't find how please specify exact commands to use.

Boaz

Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks

[Boaz Harrosh]

On 06/08/2010 09:34 AM, Paul Mundt wrote:
> On Mon, Jun 07, 2010 at 11:18:42PM -0700, David Rientjes wrote:
>> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>>
>>>>> I already have my:
>>>>>  VERSION = 2
>>>>>  PATCHLEVEL = 6
>>>>>  SUBLEVEL = 35
>>>>> -EXTRAVERSION = -rc2
>>>>> +EXTRAVERSION = -rc2-my_tree
>>>>>
>>>>
>>>> You shouldn't be using EXTRAVERSION for this purpose, you should be 
>>>> passing LOCALVERSION=my_tree to make.
>>>>
>>>
>>> That will not work because the way I run make is out of my control. Every
>>> one in the working group has his system. The Makefile is part of the
>>> public git tree, so every one will get the same identification without
>>> any confusion with Vanilla kernel, or what was compiled.
>>>
>>
>> If everyone using that tree wants the same version string for that kernel, 
>> use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make 
>> LOCALVERSION=".
>>
> Or just distribute a localversion-my_tree file in the top-level directory
> like other trees do. This doesn't strike me as a particularly significant
> problem.

OK That one is actually a solution. I'll try that ASAP. If it works as expected
it's perfect. Even better than before

Thanks
Boaz

Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks

[Boaz Harrosh]

On 06/08/2010 09:39 AM, Boaz Harrosh wrote:
> On 06/08/2010 09:34 AM, Paul Mundt wrote:
>> On Mon, Jun 07, 2010 at 11:18:42PM -0700, David Rientjes wrote:
>>> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>>>
>>>>>> I already have my:
>>>>>>  VERSION = 2
>>>>>>  PATCHLEVEL = 6
>>>>>>  SUBLEVEL = 35
>>>>>> -EXTRAVERSION = -rc2
>>>>>> +EXTRAVERSION = -rc2-my_tree
>>>>>>
>>>>>
>>>>> You shouldn't be using EXTRAVERSION for this purpose, you should be 
>>>>> passing LOCALVERSION=my_tree to make.
>>>>>
>>>>
>>>> That will not work because the way I run make is out of my control. Every
>>>> one in the working group has his system. The Makefile is part of the
>>>> public git tree, so every one will get the same identification without
>>>> any confusion with Vanilla kernel, or what was compiled.
>>>>
>>>
>>> If everyone using that tree wants the same version string for that kernel, 
>>> use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make 
>>> LOCALVERSION=".
>>>
>> Or just distribute a localversion-my_tree file in the top-level directory
>> like other trees do. This doesn't strike me as a particularly significant
>> problem.
> 


I can't manage to work this out. Here is what I did please, what did I do wrong:
[my-tree] $ git checkout v2.6.35-rc2
[my-tree] $ touch localversion-my_tree
[my-tree] $ git add localversion-my_tree; git commit; # ...
[my-tree] $ make oldconfig
[my-tree] $ make

At my make install I still get DEPMOD 2.6.35-rc2+

What else to do?

Thanks
Boaz

> OK That one is actually a solution. I'll try that ASAP. If it works as expected
> it's perfect. Even better than before
> 
> Thanks
> Boaz

Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks

[Paul Mundt]

On Tue, Jun 08, 2010 at 10:16:39AM +0300, Boaz Harrosh wrote:
> On 06/08/2010 09:39 AM, Boaz Harrosh wrote:
> > On 06/08/2010 09:34 AM, Paul Mundt wrote:
> >> On Mon, Jun 07, 2010 at 11:18:42PM -0700, David Rientjes wrote:
> >>> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
> >>>
> >>>>>> I already have my:
> >>>>>>  VERSION = 2
> >>>>>>  PATCHLEVEL = 6
> >>>>>>  SUBLEVEL = 35
> >>>>>> -EXTRAVERSION = -rc2
> >>>>>> +EXTRAVERSION = -rc2-my_tree
> >>>>>>
> >>>>>
> >>>>> You shouldn't be using EXTRAVERSION for this purpose, you should be 
> >>>>> passing LOCALVERSION=my_tree to make.
> >>>>>
> >>>>
> >>>> That will not work because the way I run make is out of my control. Every
> >>>> one in the working group has his system. The Makefile is part of the
> >>>> public git tree, so every one will get the same identification without
> >>>> any confusion with Vanilla kernel, or what was compiled.
> >>>>
> >>>
> >>> If everyone using that tree wants the same version string for that kernel, 
> >>> use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make 
> >>> LOCALVERSION=".
> >>>
> >> Or just distribute a localversion-my_tree file in the top-level directory
> >> like other trees do. This doesn't strike me as a particularly significant
> >> problem.
> > 
> 
> 
> I can't manage to work this out. Here is what I did please, what did I do wrong:
> [my-tree] $ git checkout v2.6.35-rc2
> [my-tree] $ touch localversion-my_tree

It's not frightfully intuitive, you have to have the string in the file.
So simply doing:

$ echo "-my_tree" > localversion-my_tree

ought to work fine for your case.

Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks

[Boaz Harrosh]

On 06/08/2010 10:16 AM, Boaz Harrosh wrote:
> On 06/08/2010 09:39 AM, Boaz Harrosh wrote:
>> On 06/08/2010 09:34 AM, Paul Mundt wrote:
>>> On Mon, Jun 07, 2010 at 11:18:42PM -0700, David Rientjes wrote:
>>>> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>>>>
>>>>>>> I already have my:
>>>>>>>  VERSION = 2
>>>>>>>  PATCHLEVEL = 6
>>>>>>>  SUBLEVEL = 35
>>>>>>> -EXTRAVERSION = -rc2
>>>>>>> +EXTRAVERSION = -rc2-my_tree
>>>>>>>
>>>>>>
>>>>>> You shouldn't be using EXTRAVERSION for this purpose, you should be 
>>>>>> passing LOCALVERSION=my_tree to make.
>>>>>>
>>>>>
>>>>> That will not work because the way I run make is out of my control. Every
>>>>> one in the working group has his system. The Makefile is part of the
>>>>> public git tree, so every one will get the same identification without
>>>>> any confusion with Vanilla kernel, or what was compiled.
>>>>>
>>>>
>>>> If everyone using that tree wants the same version string for that kernel, 
>>>> use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make 
>>>> LOCALVERSION=".
>>>>
>>> Or just distribute a localversion-my_tree file in the top-level directory
>>> like other trees do. This doesn't strike me as a particularly significant
>>> problem.
>>
> 
> 
> I can't manage to work this out. Here is what I did please, what did I do wrong:
> [my-tree] $ git checkout v2.6.35-rc2
> [my-tree] $ touch localversion-my_tree

OK I get it above should be:
[my-tree] $ echo "-my_tree" > localversion-my_tree

But now I get DEPMOD 2.6.35-rc2-my_tree+

Please fix it so if localversion* is present then the plus is
removed. And the git is not inspected

Boaz

> [my-tree] $ git add localversion-my_tree; git commit; # ...
> [my-tree] $ make oldconfig
> [my-tree] $ make
> 
> At my make install I still get DEPMOD 2.6.35-rc2+
> 
> What else to do?
> 
> Thanks
> Boaz
> 
>> OK That one is actually a solution. I'll try that ASAP. If it works as expected
>> it's perfect. Even better than before
>>
>> Thanks
>> Boaz
> 

Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks

[Paul Mundt]

On Tue, Jun 08, 2010 at 10:21:54AM +0300, Boaz Harrosh wrote:
> On 06/08/2010 10:16 AM, Boaz Harrosh wrote:
> OK I get it above should be:
> [my-tree] $ echo "-my_tree" > localversion-my_tree
> 
> But now I get DEPMOD 2.6.35-rc2-my_tree+
> 
> Please fix it so if localversion* is present then the plus is
> removed. And the git is not inspected
> 
How is that a 'fix'? If I'm using localversion* and have people sending
me bug reports, I still do want to see the git ID. The + thing in this
context might not have any meaning since the 2.6.35-rc2 that you've
tagged for your tree and the release one could wildly differ, but that's
more of an argument against the + thing existing at all than anything
else.

Whether having LOCALVERSION_AUTO be compulsory is a good idea or not is
another matter entirely, the localversion* semantics are pretty
clear-cut.

Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks

[Boaz Harrosh]

On 06/08/2010 10:32 AM, Paul Mundt wrote:
> On Tue, Jun 08, 2010 at 10:21:54AM +0300, Boaz Harrosh wrote:
>> On 06/08/2010 10:16 AM, Boaz Harrosh wrote:
>> OK I get it above should be:
>> [my-tree] $ echo "-my_tree" > localversion-my_tree
>>
>> But now I get DEPMOD 2.6.35-rc2-my_tree+
>>
>> Please fix it so if localversion* is present then the plus is
>> removed. And the git is not inspected
>>
> How is that a 'fix'? If I'm using localversion* and have people sending
> me bug reports, I still do want to see the git ID. The + thing in this
> context might not have any meaning since the 2.6.35-rc2 that you've
> tagged for your tree and the release one could wildly differ, but that's
> more of an argument against the + thing existing at all than anything
> else.
> 

You lost me sorry. I don't understand what you are saying ?

> Whether having LOCALVERSION_AUTO be compulsory is a good idea or not is
> another matter entirely, the localversion* semantics are pretty
> clear-cut.

the "localversion* semantics" is not the issue here. The issue is the
CONFIG_LOCALVERSION_AUTO semantics. You have effectively made it compulsory
but with a choice of a style. "From the frying pan to the fire"

And you have broken the "localversion* semantics". Because my vanilla release
is 2.6.rc2-my_tree-my_ver as checkedout and delivered from my official tree.
Now you have added a "+" regardless of if it is an official tagged version or
not.

I do not expect a complicated "let me be smarter than you" system that
checks any tags of mine and provides an out-of-tree version system. I just
want a switch that tells the system. "Let me shoot myself in the leg,
I know what I want"

"localversion*" should override any automatism as an indication of an
alternative tagging system. (Or any other switch that can turn this off)

And please stop the politics: "having LOCALVERSION_AUTO be compulsory" is
Politics not, anything technical: "how to support my needs"

Boaz

kbuild: Fix the breakage caused by "improve version string logic"

[Boaz Harrosh]

The patch: 85a256d8e0116c8f5ad276730830f5d4d473344d
	Author: David Rientjes <rientjes@google.com>
	Title: kbuild: improve version string logic

Broke none Linus trees that supply their own version string and
tag system via a presence of a localversion* file at the Kernel's
root subdirectory.

After This patch. The "+" (plus) is not added if a localversion*
file is present or a CONFIG_LOCALVERSION is configured.

Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
---
 Makefile |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 654c31a..324a413 100644
--- a/Makefile
+++ b/Makefile
@@ -945,7 +945,9 @@ ifdef CONFIG_LOCALVERSION_AUTO
 else
 	ifneq ($(scm-identifier),)
 		ifeq ($(LOCALVERSION),)
-			localver-extra = +
+			ifeq ($(localver),)
+				localver-extra = +
+			endif
 		endif
 	endif
 endif
-- 
1.6.6.1

Re: kbuild: Fix the breakage caused by "improve version string logic"

[David Rientjes]

On Tue, 8 Jun 2010, Boaz Harrosh wrote:

> 
> The patch: 85a256d8e0116c8f5ad276730830f5d4d473344d
> 	Author: David Rientjes <rientjes@google.com>
> 	Title: kbuild: improve version string logic
> 
> Broke none Linus trees that supply their own version string and
> tag system via a presence of a localversion* file at the Kernel's
> root subdirectory.
> 
> After This patch. The "+" (plus) is not added if a localversion*
> file is present or a CONFIG_LOCALVERSION is configured.
> 

The only reason the `+' is being appended to your version string is 
because your scm is reporting that there have been commits to the tree 
since the last release; for git, that means anything that isn't at a 
tagged commit.

If you were to create a tarball of your tree, for instance, and distribute 
it to someone else, there would be no appended `+' because there is no 
revision history.  The `+' being appended simply implies that you're 
beyond the base kernel version in an scm.  The motivation is to be more 
descriptive about what kernel is being run: the most common case where 
this comes into play is when someone is running a kernel off of Linus' 
tree and a bug report incorrectly shows that it is a vanilla 2.6.35-rc2 
kernel, for instance.

When we discussed adding this indicator of revision history, we explicitly 
noted that the `+' is a modification of the base kernel version, not the 
entire string.

As mentioned previously, you can easily suppress that from being added by 
using "make LOCALVERSION=-foo" to create a 2.6.35-rc2-foo kernel when you 
do not have CONFIG_LOCALVERSION_AUTO enabled.  You already found that you 
cannot pass an empty LOCALVERSION string, so it must be something to 
identify itself as unique from vanilla 2.6.35-rc2.

The usecase that you've cited before is your colleagues pulling your git 
tree and then getting this `+' appended when they really don't want it.  
Although localversion* files are better than (ab)using the EXTRAVERSION 
variable in the Makefile, they won't suppress the `+' because your 
revision history shows that you're beyond a released (tagged) kernel.  The 
solution is to use git-tag to indicate your particular version of Linux 
that differentiates it from vanilla 2.6.35-rc2 and pass along your version 
information with either localversion* files or CONFIG_LOCALVERSION if you 
package your .config as well.

Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks

[David Rientjes]

On Tue, 8 Jun 2010, Boaz Harrosh wrote:

> And you have broken the "localversion* semantics". Because my vanilla release
> is 2.6.rc2-my_tree-my_ver as checkedout and delivered from my official tree.
> Now you have added a "+" regardless of if it is an official tagged version or
> not.
> 

The `+' modifies the base kernel version, not the version string.  
Otherwise, it would be impossible to determine whether a "2.6.35-rc2-foo" 
kernel were vanilla 2.6.35-rc2 or otherwise modified.

> I do not expect a complicated "let me be smarter than you" system that
> checks any tags of mine and provides an out-of-tree version system. I just
> want a switch that tells the system. "Let me shoot myself in the leg,
> I know what I want"
> 

If you're using git, which you obviously are, then add localversion* files 
to your repository (or modify CONFIG_LOCALVERSION if you pass along your 
.config as well) and use git-tag to indicate its something you're 
releasing as your kernel.

Re: kbuild: Fix the breakage caused by "improve version string logic"

[Boaz Harrosh]

On 06/08/2010 12:13 PM, David Rientjes wrote:
> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
> 
>>
>> The patch: 85a256d8e0116c8f5ad276730830f5d4d473344d
>> 	Author: David Rientjes <rientjes@google.com>
>> 	Title: kbuild: improve version string logic
>>
>> Broke none Linus trees that supply their own version string and
>> tag system via a presence of a localversion* file at the Kernel's
>> root subdirectory.
>>
>> After This patch. The "+" (plus) is not added if a localversion*
>> file is present or a CONFIG_LOCALVERSION is configured.
>>
> 
> The only reason the `+' is being appended to your version string is 
> because your scm is reporting that there have been commits to the tree 
> since the last release; for git, that means anything that isn't at a 
> tagged commit.
> 

What is a tagged commit:

[my_tree] $ git branch
*master
[my_tree] $ git tag v2.6.35-rc2-my-tree
[my_tree] $ cat localversion-my-tree
-my-tree

I still get: DEPMOD 2.6.35-rc2-my-tree+

How to solve? please specify.

> If you were to create a tarball of your tree, for instance, and distribute 
> it to someone else, there would be no appended `+' because there is no 
> revision history.  The `+' being appended simply implies that you're 
> beyond the base kernel version in an scm.  The motivation is to be more 
> descriptive about what kernel is being run: the most common case where 
> this comes into play is when someone is running a kernel off of Linus' 
> tree and a bug report incorrectly shows that it is a vanilla 2.6.35-rc2 
> kernel, for instance.
> 

In the Linus case there is CONFIG_LOCALVERSION_AUTO=y by default for this.

In my tree there is 2.6.35-rc2-my-tree so it cannot be mistaken with
Linus tree.

CONFIG_LOCALVERSION_AUTO=n was: "Even if I have an SCM, please do not
inspect it."

I need that back

> When we discussed adding this indicator of revision history, we explicitly 
> noted that the `+' is a modification of the base kernel version, not the 
> entire string.
> 

My base "kernel version" is 2.6.35-rc2-my-tree. There cannot be any mistake
where this tree came from. How do I get rid of the "+"?

> As mentioned previously, you can easily suppress that from being added by 
> using "make LOCALVERSION=-foo" to create a 2.6.35-rc2-foo kernel when you 
> do not have CONFIG_LOCALVERSION_AUTO enabled.  You already found that you 
> cannot pass an empty LOCALVERSION string, so it must be something to 
> identify itself as unique from vanilla 2.6.35-rc2.
> 

As mentioned previously this is not an option I do not have git control
over how this gets compiled.

> The usecase that you've cited before is your colleagues pulling your git 
> tree and then getting this `+' appended when they really don't want it.

Yes
  
> Although localversion* files are better than (ab)using the EXTRAVERSION 
> variable in the Makefile, they won't suppress the `+' because your 
> revision history shows that you're beyond a released (tagged) kernel.

I'm now using localversion-my-tree file. It is much better thanks.

What else do I need to do so clean checkout of my tree will not have
the "+" appended. It already have the my-tree appended to it.

> The solution is to use git-tag to indicate your particular version of Linux 
> that differentiates it from vanilla 2.6.35-rc2 and pass along your version 
> information with either localversion* 

I tried that. Only with my patch it works. Hence the patch.

files or CONFIG_LOCALVERSION if you 
> package your .config as well.

Again not an option .config is derived from a distro one and is not managed
by git.

Please find me a solution? this breaks lots of stuff un-necessarily and with
no apparent gain.

Thanks
Boaz

Re: kbuild: Fix the breakage caused by "improve version string logic"

[Boaz Harrosh]

On 06/08/2010 01:14 PM, Boaz Harrosh wrote:
> On 06/08/2010 12:13 PM, David Rientjes wrote:
>> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>>
>>>
>>> The patch: 85a256d8e0116c8f5ad276730830f5d4d473344d
>>> 	Author: David Rientjes <rientjes@google.com>
>>> 	Title: kbuild: improve version string logic
>>>
>>> Broke none Linus trees that supply their own version string and
>>> tag system via a presence of a localversion* file at the Kernel's
>>> root subdirectory.
>>>
>>> After This patch. The "+" (plus) is not added if a localversion*
>>> file is present or a CONFIG_LOCALVERSION is configured.
>>>
>>
>> The only reason the `+' is being appended to your version string is 
>> because your scm is reporting that there have been commits to the tree 
>> since the last release; for git, that means anything that isn't at a 
>> tagged commit.
>>
> 
> What is a tagged commit:
> 
> [my_tree] $ git branch
> *master
> [my_tree] $ git tag v2.6.35-rc2-my-tree

OK now I get it I need:
$ git tag -a v2.6.35-rc2-my-tree

I never used the -a before though no one complained. What else
am I missing?

Boaz

> [my_tree] $ cat localversion-my-tree
> -my-tree
> 
> I still get: DEPMOD 2.6.35-rc2-my-tree+
> 
> How to solve? please specify.
> 

Re: kbuild: Fix the breakage caused by "improve version string logic"

[David Rientjes]

On Tue, 8 Jun 2010, Boaz Harrosh wrote:

> What is a tagged commit:
> 
> [my_tree] $ git branch
> *master
> [my_tree] $ git tag v2.6.35-rc2-my-tree
> [my_tree] $ cat localversion-my-tree
> -my-tree
> 
> I still get: DEPMOD 2.6.35-rc2-my-tree+
> 
> How to solve? please specify.
> 

You need to use git tag -a.

> In my tree there is 2.6.35-rc2-my-tree so it cannot be mistaken with
> Linus tree.
> 

Just because you have appended "-my-tree" to the version string does not 
mean it is not vanilla 2.6.35-rc2.  You could append information such as 
that just for a different config, for instance.  The `+' modifies the base 
kernel version (2.6.35-rc2), not the string itself or whatever you choose 
to add to it.

> > As mentioned previously, you can easily suppress that from being added by 
> > using "make LOCALVERSION=-foo" to create a 2.6.35-rc2-foo kernel when you 
> > do not have CONFIG_LOCALVERSION_AUTO enabled.  You already found that you 
> > cannot pass an empty LOCALVERSION string, so it must be something to 
> > identify itself as unique from vanilla 2.6.35-rc2.
> > 
> 
> As mentioned previously this is not an option I do not have git control
> over how this gets compiled.
> 

If your git repository is publically accessible, it is very simple to tag 
commits that you want your users to pull from to indicate it's a 
"release".  That allows you to determine whether other users have extra 
commits on top of your release when they send you bug reports, for 
example, which is quite helpful.

Re: kbuild: Fix the breakage caused by "improve version string logic"

[Boaz Harrosh]

On 06/09/2010 09:55 AM, David Rientjes wrote:
> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
> 
>> What is a tagged commit:
>>
>> [my_tree] $ git branch
>> *master
>> [my_tree] $ git tag v2.6.35-rc2-my-tree
>> [my_tree] $ cat localversion-my-tree
>> -my-tree
>>
>> I still get: DEPMOD 2.6.35-rc2-my-tree+
>>
>> How to solve? please specify.
>>
> 
> You need to use git tag -a.
> 

Right, I got that

>> In my tree there is 2.6.35-rc2-my-tree so it cannot be mistaken with
>> Linus tree.
>>
> 
> Just because you have appended "-my-tree" to the version string does not 
> mean it is not vanilla 2.6.35-rc2.  You could append information such as 
> that just for a different config, for instance.  

No, this is all naming convention. Just like the '+' is. If it was a config
thing then it would be added via CONFIG_LOCALVERSION and *appended* to any
compilation using that config. From a git tree you get added the localversion*
file that gets pulled by a checkout. and so on. So at a glance I know that
the presence of my_tree was added because it is from my tree. They are all
chained and ordered so we know exactly what contributed what.

> The `+' modifies the base 
> kernel version (2.6.35-rc2), not the string itself or whatever you choose 
> to add to it.
> 

Not, correct. As you yourself explained. The `+' modifies any Kernel that
is not a "tag -a" and/or modified from the tree it derives from.
Base kernel version has nothing to do with it.

>>> As mentioned previously, you can easily suppress that from being added by 
>>> using "make LOCALVERSION=-foo" to create a 2.6.35-rc2-foo kernel when you 
>>> do not have CONFIG_LOCALVERSION_AUTO enabled.  You already found that you 
>>> cannot pass an empty LOCALVERSION string, so it must be something to 
>>> identify itself as unique from vanilla 2.6.35-rc2.
>>>
>>
>> As mentioned previously this is not an option I do not have git control
>> over how this gets compiled.
>>
> 
> If your git repository is publically accessible, it is very simple to tag 
> commits that you want your users to pull from to indicate it's a 
> "release".  That allows you to determine whether other users have extra 
> commits on top of your release when they send you bug reports, for 
> example, which is quite helpful.

Sigh, I give up. Let me spell it out for you once more and I'll not mention
this again:
  "For multitude of reasons, there are times that even when running from
   a git tree, I wish to compile a Kernel as if it's from a tar-ball. .i.e
   Don't poke in my git tree for this compilation."

Because I'm cross compiling, because I'm bisecting, because my scripts and
environment demand specific names, because i need to save space and time...

But it seems I will not be granted my wish. I'll go damage my
scripts/setlocalversion and be done with this.

Thanks
Boaz

Re: kbuild: Fix the breakage caused by "improve version string logic"

[Mike Galbraith]

On Wed, 2010-06-09 at 10:54 +0300, Boaz Harrosh wrote:

> But it seems I will not be granted my wish. I'll go damage my
> scripts/setlocalversion and be done with this.

I dislike that annoying little <expletive deleted> '+' too, but I have
to edit Makefile constantly to whack -rc and set version to the _right_
number as defined by me anyway, so it doesn't matter much.

Thank goodness we have _something_ to gripe about :)

	-Mike

Re: [patch] kbuild: improve version string logic

[Jiri Kosina]

On Mon, 18 Jan 2010, Michal Marek wrote:

> > Michal, where are you hosting your git tree?  Are you going to be taking 
> > over kbuild-next on git.kernel.org?
> 
> git://repo.or.cz/linux-kbuild.git for-next
> (http://repo.or.cz/w/linux-kbuild.git). Maybe I should ask for an
> account in git.kernel.org account and move it there, you're not the
> first one to wonder where to find the tree :).

Yes, I think it is preferred.

I know, I know, the proper URL is listed in MAINTAINERS file ... still, I 
believe that what most people do when looking for particular git tree is 
going to http://git.kernel.org/ and looking around there.

So having the tree there really helps to give it much more exposure than 
on some random git hosting.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: [patch] kbuild: improve version string logic

[Michal Marek]

On 18.1.2010 11:45, David Rientjes wrote:
> Michal, where are you hosting your git tree?  Are you going to be taking 
> over kbuild-next on git.kernel.org?

git://repo.or.cz/linux-kbuild.git for-next
(http://repo.or.cz/w/linux-kbuild.git). Maybe I should ask for an
account in git.kernel.org account and move it there, you're not the
first one to wonder where to find the tree :).

Michal

Re: [patch] kbuild: improve version string logic

[David Rientjes]

On Mon, 18 Jan 2010, Michal Marek wrote:

> >>> Given that Sam doesnt maintain the kbuild tree anymore, would this patch be a 
> >>> good fit for -mm perhaps?
> >>
> >> There is a new kbuild tree maintainer: Michal Marek <mmarek@suse.cz>
> > 
> > Good. Michal, what do you think about David's patch?
> 
> The patch is OK, I already commented on a previous version and this
> addresses the two minor issues I had. I was just too busy last week to
> apply it. I will do so ASAP now.
> 

Michal, where are you hosting your git tree?  Are you going to be taking 
over kbuild-next on git.kernel.org?

Re: [patch] kbuild: improve version string logic

[Michal Marek]

On 16.1.2010 10:26, Ingo Molnar wrote:
> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
>> Hi Ingo,
>>
>> On Sat, 16 Jan 2010 07:37:54 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>>>
>>> Given that Sam doesnt maintain the kbuild tree anymore, would this patch be a 
>>> good fit for -mm perhaps?
>>
>> There is a new kbuild tree maintainer: Michal Marek <mmarek@suse.cz>
> 
> Good. Michal, what do you think about David's patch?

The patch is OK, I already commented on a previous version and this
addresses the two minor issues I had. I was just too busy last week to
apply it. I will do so ASAP now.

Michal

Re: [patch] kbuild: improve version string logic

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Ingo,
> 
> On Sat, 16 Jan 2010 07:37:54 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > Given that Sam doesnt maintain the kbuild tree anymore, would this patch be a 
> > good fit for -mm perhaps?
> 
> There is a new kbuild tree maintainer: Michal Marek <mmarek@suse.cz>

Good. Michal, what do you think about David's patch?

	Ingo

Re: [patch] kbuild: improve version string logic

[Stephen Rothwell]

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

Hi Ingo,

On Sat, 16 Jan 2010 07:37:54 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> Given that Sam doesnt maintain the kbuild tree anymore, would this patch be a 
> good fit for -mm perhaps?

There is a new kbuild tree maintainer: Michal Marek <mmarek@suse.cz>

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

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

Re: [patch] kbuild: improve version string logic

[Ingo Molnar]

* David Rientjes <rientjes@google.com> wrote:

> The LOCALVERSION= string passed to "make" will now always be appended to the 
> kernel version after CONFIG_LOCALVERSION, if it exists, regardless of 
> whether CONFIG_LOCALVERSION_AUTO is set or not.  This allows users to 
> uniquely identify their kernel builds with a string.

I've been using Linus's earlier patch for 3 months meanwhile in -tip and the 
'+' version string differentiator is very useful in practice. Your version of 
the patch should address some of the observations offered in the original 
discussion as well. Would be nice to have your patch upstream (in the next 
merge window or so).

Given that Sam doesnt maintain the kbuild tree anymore, would this patch be a 
good fit for -mm perhaps?

	Ingo

[patch] kbuild: improve version string logic

[David Rientjes]

The LOCALVERSION= string passed to "make" will now always be appended to
the kernel version after CONFIG_LOCALVERSION, if it exists, regardless of
whether CONFIG_LOCALVERSION_AUTO is set or not.  This allows users to
uniquely identify their kernel builds with a string.

If CONFIG_LOCALVERSION_AUTO is enabled, the unique SCM tag reported by 
setlocalversion (or .scmversion) is appended to the kernel version, if it 
exists.  When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
to the kernel version to represent that the kernel has been revised since
the last release unless "make LOCALVERSION=" was used to uniquely identify
the build.

The end result is this:

 - when LOCALVERSION= is passed to "make", it is appended to the kernel
   version,

 - when CONFIG_LOCALVERSION_AUTO is enabled, a unique SCM identifier is
   appended if the respository has been revised beyond a tagged commit,
   and

 - when CONFIG_LOCALVERSION_AUTO is disabled, a `+' is appended if the 
   repository has been revised beyond a tagged commit and LOCALVERSION=
   was not passed to "make".

Examples:

With CONFIG_LOCALVERSION_AUTO: "make" results in
v2.6.32-rc4-00149-ga3ccf63.  If there are uncommited changes to the
respository, it results in v2.6.32-rc4-00149-ga3ccf63-dirty.  If
"make LOCALVERSION=kbuild" were used, it results in
v2.6.32-rc4-kbuild-00149-ga3ccf63-dirty.

Without CONFIG_LOCALVERSION_AUTO, "make" results in v2.6.32-rc4+
unless the repository is at the Linux v2.6.32-rc4 commit (in which
case the version would be v2.6.32-rc4).  If "make LOCALVERSION=kbuild"
were used, it results in v2.6.32-rc4-kbuild.

Also renames variables such as localver-auto and _localver-auto to more 
accurately describe what they represent: localver-extra and
scm-identifier, respectively.

Signed-off-by: David Rientjes <rientjes@google.com>
---
 Makefile |   43 +++++++++++++++++++++++++++----------------
 1 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -908,14 +908,19 @@ endif
 #	  $(localver)
 #	    localversion*		(files without backups, containing '~')
 #	    $(CONFIG_LOCALVERSION)	(from kernel config setting)
-#	  $(localver-auto)		(only if CONFIG_LOCALVERSION_AUTO is set)
-#	    ./scripts/setlocalversion	(SCM tag, if one exists)
-#	    $(LOCALVERSION)		(from make command line if provided)
+#	  $(LOCALVERSION)		(from make command line, if provided)
+#	  $(localver-extra)
+#	    $(scm-identifier)		(unique SCM tag, if one exists)
+#	      ./scripts/setlocalversion	(only with CONFIG_LOCALVERSION_AUTO)
+#	      .scmversion		(only with CONFIG_LOCALVERSION_AUTO)
+#	    +				(only without CONFIG_LOCALVERSION_AUTO
+#					 and without LOCALVERSION= and
+#					 repository is at non-tagged commit)
 #
-#  Note how the final $(localver-auto) string is included *only* if the
-# kernel config option CONFIG_LOCALVERSION_AUTO is selected.  Also, at the
-# moment, only git is supported but other SCMs can edit the script
-# scripts/setlocalversion and add the appropriate checks as needed.
+# For kernels without CONFIG_LOCALVERSION_AUTO compiled from an SCM that has
+# been revised beyond a tagged commit, `+' is appended to the version string
+# when not overridden by using "make LOCALVERSION=".  This indicates that the
+# kernel is not a vanilla release version and has been modified.
 
 pattern = ".*/localversion[^~]*"
 string  = $(shell cat /dev/null \
@@ -924,26 +929,32 @@ string  = $(shell cat /dev/null \
 localver = $(subst $(space),, $(string) \
 			      $(patsubst "%",%,$(CONFIG_LOCALVERSION)))
 
-# If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called
-# and if the SCM is know a tag from the SCM is appended.
-# The appended tag is determined by the SCM used.
+# scripts/setlocalversion is called to create a unique identifier if the source
+# is managed by a known SCM and the repository has been revised since the last
+# tagged (release) commit.  The format of the identifier is determined by the
+# SCM's implementation.
 #
 # .scmversion is used when generating rpm packages so we do not loose
 # the version information from the SCM when we do the build of the kernel
 # from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
 ifeq ($(wildcard .scmversion),)
-        _localver-auto = $(shell $(CONFIG_SHELL) \
+        scm-identifier = $(shell $(CONFIG_SHELL) \
                          $(srctree)/scripts/setlocalversion $(srctree))
 else
-        _localver-auto = $(shell cat .scmversion 2> /dev/null)
+        scm-identifier = $(shell cat .scmversion 2> /dev/null)
 endif
 
-	localver-auto  = $(LOCALVERSION)$(_localver-auto)
+ifdef CONFIG_LOCALVERSION_AUTO
+	localver-extra = $(scm-identifier)
+else
+	ifneq ($scm-identifier,)
+		ifeq ($(LOCALVERSION),)
+			localver-extra = +
+		endif
+	endif
 endif
 
-localver-full = $(localver)$(localver-auto)
+localver-full = $(localver)$(LOCALVERSION)$(localver-extra)
 
 # Store (new) KERNELRELASE string in include/config/kernel.release
 kernelrelease = $(KERNELVERSION)$(localver-full)

Re: [patch] kbuild: improve version string logic

[Stephen Rothwell]

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

Hi Michal,

On Tue, 05 Jan 2010 14:59:11 +0100 Michal Marek <mmarek@suse.cz> wrote:
>
> Stephen, won't this break your linux-next scripts in any way? The final
> build won't change, because of the next-YYYYMMDD tag, but the builds in
> between will have the '+' appended to their version.

I think it should be OK - I don't depend on the kernel version for
anything until the very end.  If it does cause a problem, I am now
forwarned and can fix my scripts.

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

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

Re: [patch] kbuild: improve version string logic

[Michal Marek]

On 4.1.2010 22:31, David Rientjes wrote:
> The LOCALVERSION= string passed to "make" will now always be appended to
> the kernel version after CONFIG_LOCALVERSION, if it exists, regardless of
> whether CONFIG_LOCALVERSION_AUTO is set or not.  This allows users to
> uniquely identify their kernel builds with a string.
> 
> scripts/setlocalversion will now always be called to determine whether
> the repository is beyond a tagged (release) commit.  When at a tagged
> commit, this script will now suppress all output.
> 
> If CONFIG_LOCALVERSION_AUTO is enabled, the unique SCM tag reported by 
> setlocalversion (or .scmversion) is appended to the kernel version, if it 
> exists.  When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
> to the kernel version to represent that the kernel has been revised since
> the last release unless "make LOCALVERSION=" was used to uniquely identify
> the build.
> 
> The end result is this:
> 
>  - when LOCALVERSION= is passed to "make", it is appended to the kernel
>    version,
> 
>  - when CONFIG_LOCALVERSION_AUTO is enabled, a unique SCM identifier is
>    appended if the respository has been revised beyond a tagged commit,
>    and
> 
>  - when CONFIG_LOCALVERSION_AUTO is disabled, a `+' is appended if the 
>    repository has been revised beyond a tagged commit and LOCALVERSION=
>    was not passed to "make".

I've read the thread from last October where this was discussed
(http://thread.gmane.org/gmane.linux.kernel/897768/focus=898233). I'm
not entirely sure if all people will be happy about the plus sign that
can't be turned off, but from the thread I got the impression that the
plus sign is wanted, so let's add this to linux-next now, so that people
doing automated builds can adjust their scripts if needed. Just in case:
Stephen, won't this break your linux-next scripts in any way? The final
build won't change, because of the next-YYYYMMDD tag, but the builds in
between will have the '+' appended to their version.


Two small comments are below.

> Examples:
> 
> With CONFIG_LOCALVERSION_AUTO: "make" results in
> v2.6.32-rc4-00149-ga3ccf63.  If there are uncommited changes to the
> respository, it results in v2.6.32-rc4-00149-ga3ccf63-dirty.  If
> "make LOCALVERSION=kbuild" were used, it results in
> v2.6.32-rc4-kbuild-00149-ga3ccf63-dirty.
> 
> Without CONFIG_LOCALVERSION_AUTO, "make" results in v2.6.32-rc4+
> unless the repository is at the Linux v2.6.32-rc4 commit (in which
> case the version would be v2.6.32-rc4).  If "make LOCALVERSION=kbuild"
> were used, it results in v2.6.32-rc4-kbuild.
> 
> Also renames variables such as localver-auto and _localver-auto to more 
> accurately describe what they represent: localver-extra and
> scm-identifier, respectively.
> 
> Acked-by: Ingo Molnar <mingo@elte.hu>
> Signed-off-by: David Rientjes <rientjes@google.com>
> ---
>  Makefile                |   43 +++++++++++++++++++++++++++----------------
>  scripts/setlocalversion |    3 ++-
>  2 files changed, 29 insertions(+), 17 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -898,14 +898,19 @@ $(vmlinux-dirs): prepare scripts
>  #	  $(localver)
>  #	    localversion*		(files without backups, containing '~')
>  #	    $(CONFIG_LOCALVERSION)	(from kernel config setting)
> -#	  $(localver-auto)		(only if CONFIG_LOCALVERSION_AUTO is set)
> -#	    ./scripts/setlocalversion	(SCM tag, if one exists)
> -#	    $(LOCALVERSION)		(from make command line if provided)
> +#	    $(LOCALVERSION)		(from make command line, if provided)

$(LOCALVERSION) is no longer part of $(localver), it should be indented
at the same level.


> +#	  $(localver-extra)
> +#	    $(scm-identifier)		(unique SCM tag, if one exists)
> +#	      ./scripts/setlocalversion	(only with CONFIG_LOCALVERSION_AUTO)
> +#	      .scmversion		(only with CONFIG_LOCALVERSION_AUTO)
> +#	    +				(only without CONFIG_LOCALVERSION_AUTO
> +#					 and without LOCALVERSION= and 
> +#					 repository is at non-tagged commit)
>  #
> -#  Note how the final $(localver-auto) string is included *only* if the
> -# kernel config option CONFIG_LOCALVERSION_AUTO is selected.  Also, at the
> -# moment, only git is supported but other SCMs can edit the script
> -# scripts/setlocalversion and add the appropriate checks as needed.
> +# For kernels without CONFIG_LOCALVERSION_AUTO compiled from an SCM that has
> +# been revised beyond a tagged commit, `+' is appended to the version string
> +# when not overridden by using "make LOCALVERSION=".  This indicates that the
> +# kernel is not a vanilla release version and has been modified.
>  
>  pattern = ".*/localversion[^~]*"
>  string  = $(shell cat /dev/null \
> @@ -914,26 +919,32 @@ string  = $(shell cat /dev/null \
>  localver = $(subst $(space),, $(string) \
>  			      $(patsubst "%",%,$(CONFIG_LOCALVERSION)))
>  
> -# If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called
> -# and if the SCM is know a tag from the SCM is appended.
> -# The appended tag is determined by the SCM used.
> +# scripts/setlocalversion is called to create a unique identifier if the source
> +# is managed by a known SCM and the repository has been revised since the last
> +# tagged (release) commit.  The format of the identifier is determined by the
> +# SCM's implementation.
>  #
>  # .scmversion is used when generating rpm packages so we do not loose
>  # the version information from the SCM when we do the build of the kernel
>  # from the copied source
> -ifdef CONFIG_LOCALVERSION_AUTO
> -
>  ifeq ($(wildcard .scmversion),)
> -        _localver-auto = $(shell $(CONFIG_SHELL) \
> +        scm-identifier = $(shell $(CONFIG_SHELL) \
>                           $(srctree)/scripts/setlocalversion $(srctree))
>  else
> -        _localver-auto = $(shell cat .scmversion 2> /dev/null)
> +        scm-identifier = $(shell cat .scmversion 2> /dev/null)
>  endif
>  
> -	localver-auto  = $(LOCALVERSION)$(_localver-auto)
> +ifdef CONFIG_LOCALVERSION_AUTO
> +	localver-extra = $(scm-identifier)
> +else
> +	ifneq ($scm-identifier,)
> +		ifeq ($(LOCALVERSION),)
> +			localver-extra = +
> +		endif
> +	endif
>  endif
>  
> -localver-full = $(localver)$(localver-auto)
> +localver-full = $(localver)$(LOCALVERSION)$(localver-extra)
>  
>  # Store (new) KERNELRELASE string in include/config/kernel.release
>  kernelrelease = $(KERNELVERSION)$(localver-full)
> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
> --- a/scripts/setlocalversion
> +++ b/scripts/setlocalversion
> @@ -26,7 +26,8 @@ if head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
>  		# If we are past a tagged commit (like "v2.6.30-rc5-302-g72357d5"),
>  		# we pretty print it.
>  		if atag="`git describe 2>/dev/null`"; then
> -			echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'
> +			echo "$atag" | awk -F- 'int($(NF-1)) > 0	\
> +					{printf("-%05d-%s", $(NF-1),$(NF))}'
>
>  		# If we don't have a tag at all we print -g{commitish}.
>  		else

Why is this needed? There is

	# If we are at a tagged commit (like "v2.6.30-rc6"), we ignore it,
	# because this version is defined in the top level Makefile.
	if [ -z "`git describe --exact-match 2>/dev/null`" ]; then

a few lines above and even without your patch ./scripts/setlocalversion
returns nothing when HEAD is tagged. Do you have an old git version that
doesn't undestand --exact-match? In that case, the if around this should
be removed.

thanks,
Michal

[patch] kbuild: improve version string logic

[David Rientjes]

The LOCALVERSION= string passed to "make" will now always be appended to
the kernel version after CONFIG_LOCALVERSION, if it exists, regardless of
whether CONFIG_LOCALVERSION_AUTO is set or not.  This allows users to
uniquely identify their kernel builds with a string.

scripts/setlocalversion will now always be called to determine whether
the repository is beyond a tagged (release) commit.  When at a tagged
commit, this script will now suppress all output.

If CONFIG_LOCALVERSION_AUTO is enabled, the unique SCM tag reported by 
setlocalversion (or .scmversion) is appended to the kernel version, if it 
exists.  When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
to the kernel version to represent that the kernel has been revised since
the last release unless "make LOCALVERSION=" was used to uniquely identify
the build.

The end result is this:

 - when LOCALVERSION= is passed to "make", it is appended to the kernel
   version,

 - when CONFIG_LOCALVERSION_AUTO is enabled, a unique SCM identifier is
   appended if the respository has been revised beyond a tagged commit,
   and

 - when CONFIG_LOCALVERSION_AUTO is disabled, a `+' is appended if the 
   repository has been revised beyond a tagged commit and LOCALVERSION=
   was not passed to "make".

Examples:

With CONFIG_LOCALVERSION_AUTO: "make" results in
v2.6.32-rc4-00149-ga3ccf63.  If there are uncommited changes to the
respository, it results in v2.6.32-rc4-00149-ga3ccf63-dirty.  If
"make LOCALVERSION=kbuild" were used, it results in
v2.6.32-rc4-kbuild-00149-ga3ccf63-dirty.

Without CONFIG_LOCALVERSION_AUTO, "make" results in v2.6.32-rc4+
unless the repository is at the Linux v2.6.32-rc4 commit (in which
case the version would be v2.6.32-rc4).  If "make LOCALVERSION=kbuild"
were used, it results in v2.6.32-rc4-kbuild.

Also renames variables such as localver-auto and _localver-auto to more 
accurately describe what they represent: localver-extra and
scm-identifier, respectively.

Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: David Rientjes <rientjes@google.com>
---
 Makefile                |   43 +++++++++++++++++++++++++++----------------
 scripts/setlocalversion |    3 ++-
 2 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -898,14 +898,19 @@ $(vmlinux-dirs): prepare scripts
 #	  $(localver)
 #	    localversion*		(files without backups, containing '~')
 #	    $(CONFIG_LOCALVERSION)	(from kernel config setting)
-#	  $(localver-auto)		(only if CONFIG_LOCALVERSION_AUTO is set)
-#	    ./scripts/setlocalversion	(SCM tag, if one exists)
-#	    $(LOCALVERSION)		(from make command line if provided)
+#	    $(LOCALVERSION)		(from make command line, if provided)
+#	  $(localver-extra)
+#	    $(scm-identifier)		(unique SCM tag, if one exists)
+#	      ./scripts/setlocalversion	(only with CONFIG_LOCALVERSION_AUTO)
+#	      .scmversion		(only with CONFIG_LOCALVERSION_AUTO)
+#	    +				(only without CONFIG_LOCALVERSION_AUTO
+#					 and without LOCALVERSION= and 
+#					 repository is at non-tagged commit)
 #
-#  Note how the final $(localver-auto) string is included *only* if the
-# kernel config option CONFIG_LOCALVERSION_AUTO is selected.  Also, at the
-# moment, only git is supported but other SCMs can edit the script
-# scripts/setlocalversion and add the appropriate checks as needed.
+# For kernels without CONFIG_LOCALVERSION_AUTO compiled from an SCM that has
+# been revised beyond a tagged commit, `+' is appended to the version string
+# when not overridden by using "make LOCALVERSION=".  This indicates that the
+# kernel is not a vanilla release version and has been modified.
 
 pattern = ".*/localversion[^~]*"
 string  = $(shell cat /dev/null \
@@ -914,26 +919,32 @@ string  = $(shell cat /dev/null \
 localver = $(subst $(space),, $(string) \
 			      $(patsubst "%",%,$(CONFIG_LOCALVERSION)))
 
-# If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called
-# and if the SCM is know a tag from the SCM is appended.
-# The appended tag is determined by the SCM used.
+# scripts/setlocalversion is called to create a unique identifier if the source
+# is managed by a known SCM and the repository has been revised since the last
+# tagged (release) commit.  The format of the identifier is determined by the
+# SCM's implementation.
 #
 # .scmversion is used when generating rpm packages so we do not loose
 # the version information from the SCM when we do the build of the kernel
 # from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
 ifeq ($(wildcard .scmversion),)
-        _localver-auto = $(shell $(CONFIG_SHELL) \
+        scm-identifier = $(shell $(CONFIG_SHELL) \
                          $(srctree)/scripts/setlocalversion $(srctree))
 else
-        _localver-auto = $(shell cat .scmversion 2> /dev/null)
+        scm-identifier = $(shell cat .scmversion 2> /dev/null)
 endif
 
-	localver-auto  = $(LOCALVERSION)$(_localver-auto)
+ifdef CONFIG_LOCALVERSION_AUTO
+	localver-extra = $(scm-identifier)
+else
+	ifneq ($scm-identifier,)
+		ifeq ($(LOCALVERSION),)
+			localver-extra = +
+		endif
+	endif
 endif
 
-localver-full = $(localver)$(localver-auto)
+localver-full = $(localver)$(LOCALVERSION)$(localver-extra)
 
 # Store (new) KERNELRELASE string in include/config/kernel.release
 kernelrelease = $(KERNELVERSION)$(localver-full)
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -26,7 +26,8 @@ if head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
 		# If we are past a tagged commit (like "v2.6.30-rc5-302-g72357d5"),
 		# we pretty print it.
 		if atag="`git describe 2>/dev/null`"; then
-			echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'
+			echo "$atag" | awk -F- 'int($(NF-1)) > 0	\
+					{printf("-%05d-%s", $(NF-1),$(NF))}'
 
 		# If we don't have a tag at all we print -g{commitish}.
 		else