Linus released the Linux development kernel 2.5.17 last night. He summarized the changes in two sentences, "Various FS updates (including merges of quota and iget_locked), and Makefile cleanups from Kai. And yet more TLB shootdown stuff."
This release includes the new and improved changelog format []earlier story]. It combines some of the verbosity of BitKeeper changelogs with the readability of the old style kernel changelogs. Those watching the development kernel evolve will notice that Linus has been good to his word, releasing new kernels with increasing rapidity. Browse the latest development kernels on kernel.org.
From: Linus Torvalds
To: Linux Kernel Mailing List
Subject: Linux-2.5.17
Date: Mon, 20 May 2002 22:16:35 -0700 (PDT)
Various FS updates (including merges of quota and iget_locked), and
Makefile cleanups from Kai.
And yet more TLB shootdown stuff.
Linus
-----
Summary of changes from v2.5.16 to v2.5.17
============================================
acme AT conectiva.com.br
copy_from/to_user checking in
o drivers/sound/*.c
o fs/intermezzo/ext_attr.c
o drivers/isdn/*.c
o drivers/usr/*.c
o sound/{core,pci}/*.c
o drivers/char/*
o drivers/block/*.c
Andrew Morton
o check for dirtying of non-uptodate buffers
o reduce lock contention in do_pagecache_readahead
o larger b_size, and misc fixlets
o fix dirty page management
o reiserfs locking fix
o pdflush exclusion infrastructure
o dirty inode management
o i_dirty_buffers locking fix
o ext2: preread inode backing blocks
o pdflush exclusion
o fix ext3 race with writeback
o fix ext3 buffer-stealing
o writeback tuning
o remove PG_launder
o improved I/O scheduling for indirect blocks
david AT gibson.dropbear.id.au
o Missing init.h in drivers/pci/power.c
dmccr AT us.ibm.com
o Thread group exit problem reappeared
Christoph Hellwig
o cleanup read/write
o Small cleanup of nfsd export checks
o kNFSd cleanup of nfsd_open
o get rid of
jack AT suse.cz
o quota-1-newlocks
o quota-2-formats
o quota-3-register
o quota-4-getstats
o quota-5-space
o quota-6-bytes
o quota-7-quotactl
o quota-8-format1
o quota-9-format2
o quota-10-inttype
o quota-11-sync
o quota-12-compat
o quota-13-ioctl
jaharkes AT cs.cmu.edu
o iget_locked [1-6]
jhammer AT us.ibm.com
o ips for 2.5
kai AT tp1.ruhr-uni-bochum.de
o Rules.make cleanup: introduce c_flags, a_flags
o Remuve some cruft from top-level Makefile
o Move DocBook stuff out of top-level Makefile
o Move arch specific options to their Makefile
o Don't implicitly export all symbols
o top-level Makefile cleanup
o Remove assembler rules from top-level Makefile
o Add scripts to generate include/linux/{version,compile}.h
o Rules.make: Use variables for commands
o Small Rules.make cleanup
o Rules.make: check for changed command line
o Makefile cleanup: Don't rebuild init/version.o on each build
o IA64: Use standard AS rule
o x86_64: Use standard AS rule
o Rules.make: Remove special rule for $(export-objs)
o Fix a typo in drivers/pcmcia/Makefile
o Fix arch/alpha/boot AS rule
o Makefile: fix merge
o ISDN: Export CAPI user interface directly
o ISDN: Remove remaining MOD_{INC,DEC}_USE_COUNT from CAPI drivers
o Make AFLAGS_KERNEL use consistent with CFLAGS_KERNEL
o ISDN: CAPI: Remove duplicate statistics
o ISDN: CAPI: Remove capi_interface_user etc.
o ISDN: CAPI: Move the notification callback
o ISDN: Have the CAPI application alloc struct capi_appl
o ISDN: CAPI: Pass struct capi_appl * instead of index
o ISDN: CAPI use struct capi20_appl * in signal callback
o ISDN: CAPI: Get rid of capi_signal mechanism
o ISDN: AVM T1 ISA CAPI controller fix
o Update /BitKeeper/etc/ignore
o kbuild: Use $(CURDIR)
o kbuild: Suppress printing of '$(MAKE) -C command' line
o kbuild: Fix object-specific CFLAGS_foo.o
o Small fix for net/irda/Makefile
o Fix ext2 compilation
o Fix some compiler warnings
o kbuild: Remove generated ..cmd files on 'make clean'
o kbuild: Standardize building of init/*
o kbuild: Speed up vmlinux build
mason AT suse.com
o reiserfs bitops warnings
o reiserfs iput deadlock fix
Neil Brown
o Increase snd buffer size for UDP
o Change MD Superblock IO to go straight to submit_bio
o Tidy up raid5 code
o Initial md/raid5 support for 2.5 (with bio)
Linus Torvalds
o Clean up %cr3 loading on x86, fix lazy TLB problem
o Fix double i_writecount handling (Tony Luck)
o Make generic TLB shootdown friendlier to non-x86 architectures
o Fix OSS API emulation when sound is compiled as a module
o Update kernel version to 2.5.17
o New makefiles generate .*.cmd files, not .*.flags files
KBuild 2.5
It seems odd that Linus would apply all these build fixes without any comments to Keith Owens about kbuild integration. Is this Linus's way of saying he is make Kai the kbuild maintainer? Would seem a bit harsh without even given Keith some constructive critisism.
Course, this is all wild speculation.
I just want kbuild2.5 and rmap to go in and then 2.6 to come out. There really isn't much left on the the kernelnewbies.org/status page that I'm excited about. Of course IDE/SCSI and VM will probably take forever to stabilize.
Course that is all uninformed speculation :)
I agree
I think Linus is acting strange regarding the new Kbuild, it should go in because it's simply better (AFAIK) - but instead Linus tried to avoid the issue... I wonder if he has some secret up his sleeve
splitting kbuild into parts
Aparrently Linus said in an unrelated thread, (I think it may have been the "patch penguin" thread) that he would prefer that kbuild be broken up as far as possible.
I'm not sure how that would work...
519~/tmp.$ grep ^+++ kbuild-2.5-common-2.5.15-1 | cut -d ' ' -f 2 | grep -v Makefile.in
15.2/Documentation/kbuild/00-INDEX
15.2/scripts/kernel-doc
15.2/scripts/split-include.c
15.2/scripts/mkdep.c
15.2/scripts/Menuconfig
15.2/scripts/tkparse.c
15.2/scripts/tkparse.h
15.2/scripts/Configure
15.2/drivers/scsi/script_asm.pl
15.2/include/linux/module.h
15.2/Makefile
15.2/drivers/tc/lk201-map.c_sum
15.2/drivers/tc/lk201-map.c_shipped
15.2/drivers/scsi/53c700_sum
15.2/drivers/scsi/sim710_sum
15.2/drivers/scsi/53c7xx_sum
15.2/drivers/scsi/53c8xx_sum
15.2/drivers/scsi/53c700_d.h_shipped
15.2/drivers/scsi/53c700_u.h_shipped
15.2/drivers/scsi/53c7xx_u.h_shipped
15.2/drivers/scsi/53c8xx_u.h_shipped
15.2/drivers/scsi/53c8xx_d.h_shipped
15.2/drivers/scsi/sim710_d.h_shipped
15.2/drivers/scsi/sim710_u.h_shipped
15.2/drivers/scsi/53c7xx_d.h_shipped
15.2/drivers/scsi/pcmcia/qlogicfas_inc.c
15.2/drivers/scsi/pcmcia/fdomain_inc.c
15.2/drivers/scsi/pcmcia/aha152x_inc.c
15.2/drivers/char/qtronixmap.c_sum
15.2/drivers/char/qtronixmap.c_shipped
15.2/drivers/char/defkeymap.c_shipped
15.2/drivers/char/defkeymap.c_sum
15.2/drivers/acorn/char/defkeymap-acorn.c_sum
15.2/drivers/acorn/char/defkeymap-acorn.c_shipped
15.2/Config.help
If the scsi /drivers/scsi/script_asm.pl change was sent seperately that would cut down on the number *_sum and *_shipped files changed. But these are tiny changes.
A couple other files could be changed pretty easily.
I'm not really sure how the build system works or how the "Makefile" files are translated into "Makefile.in" files. It seems reasonable that the build system should want only Makefile.in files and not Makefile files so that change may have to be done in one step.
I think it could have helped if the message had said, "third and final attempt to get feedback from Linus" instead of just "third and final attempt". It was pretty easy to read the email the wrong way...
That still doesn't explain
Linus' silence treatment of Keith Owens - which is totally uncalled for, Keith is begining to sound desperate - and I feel that we might be loosing a great kernel developer due to Linus and he's near moronic behavior - the least he could do was reply.. but NOTHING has happened and Keith sounds like he's is getting suicidal or something.
When will it stop...
People have talked about shortening the release cycle to get stable kernels out more often. Is anyone tracking features slated for 2.6 against what 2.5 has achieved so far or will it be another 2 year development cycle?
Alex
Like this ?
Guillaume Boissiere' Kernel status page for 2.5
http://www.kernelnewbies.org/status/
So halfway there then....
Good reference page. So by my estimation they are about halfway through this round of changes. Assume it takes as long to get the other half in we could be in the stabilisation period by October and possibly a 2.6.0 by Jan 2003.
YMMV :-)
Alex