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()
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 <[email protected]> OpenPGP: 1024D/ED7DAEA6
> 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
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
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
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
* Linus Torvalds <[email protected]> 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
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
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
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/
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
* Linus Torvalds <[email protected]> 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
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
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
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
* Linus Torvalds <[email protected]> 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
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)
* Ingo Molnar <[email protected]> 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
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.
* Linus Torvalds <[email protected]> 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
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
* Stefan Richter <[email protected]> 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
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
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/
Ingo Molnar wrote:
> * Stefan Richter <[email protected]> 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/
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.
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
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/
* Linus Torvalds <[email protected]> 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 <[email protected]>
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 <[email protected]>
---
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)
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
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
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
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
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.
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
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
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
* Stefan Richter <[email protected]> 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
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
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
* Theodore Tso <[email protected]> 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
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
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
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
* Johannes Berg <[email protected]> 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
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
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
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
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: [email protected]
Phone: (650) 506-8127
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/
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
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
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
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.
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/
>
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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
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
On Tue, 6 Oct 2009 20:29:08 +0200
Frans Pop <[email protected]> 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?
On Tue, Oct 6, 2009 at 12:36 PM, Frans Pop <[email protected]> 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.
On Wed, Oct 7, 2009 at 8:19 AM, Linus Torvalds
<[email protected]> 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.
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
On Tue, 6 Oct 2009, Ingo Molnar wrote:
> Subject: kbuild: Improve version string logic
> From: Linus Torvalds <[email protected]>
> 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'?
> 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.
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
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
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 [email protected]
> 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
On Wednesday 07 October 2009, Bryan Donlan wrote:
> On Tue, Oct 6, 2009 at 12:36 PM, Frans Pop <[email protected]> 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.
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
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
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
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
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
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
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...
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)); \
} \
)
On Wed, 2009-10-07 at 10:44 -0700, [email protected] 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
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
> ... 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
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
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
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 ?
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
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
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
On Sat, Oct 10, 2009 at 3:09 PM, Pavel Machek <[email protected]> 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
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 <[email protected]>
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 <[email protected]>
Cc: Frans Pop <[email protected]>
Cc: Dirk Hohndel <[email protected]>
Cc: Len Brown <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
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)
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 <[email protected]>:
<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
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.
* Frans Pop <[email protected]> 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
* David Rientjes <[email protected]> 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
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 <[email protected]>
---
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
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
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
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 <[email protected]>
---
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)
* David Rientjes <[email protected]> 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
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.
* David Rientjes <[email protected]> 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
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?
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 <[email protected]>
> ---
> 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.
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
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.
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 <[email protected]>
---
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
* David Rientjes <[email protected]> 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 <[email protected]>
Ingo
* Frans Pop <[email protected]> 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
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?
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.
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
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. ]
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.
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
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 <[email protected]>
> 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 <[email protected]>
> Cc: Frans Pop <[email protected]>
> Cc: Dirk Hohndel <[email protected]>
> Cc: Len Brown <[email protected]>
> LKML-Reference: <[email protected]>
> Signed-off-by: Ingo Molnar <[email protected]>
> ---
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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.
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 !
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.
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.
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
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
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
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.
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
>
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.
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
The patch: 85a256d8e0116c8f5ad276730830f5d4d473344d
Author: David Rientjes <[email protected]>
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 <[email protected]>
---
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
On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>
> The patch: 85a256d8e0116c8f5ad276730830f5d4d473344d
> Author: David Rientjes <[email protected]>
> 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.
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.
On 06/08/2010 12:13 PM, David Rientjes wrote:
> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>
>>
>> The patch: 85a256d8e0116c8f5ad276730830f5d4d473344d
>> Author: David Rientjes <[email protected]>
>> 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
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 <[email protected]>
>>> 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.
>
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.
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
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