Various things here. Most noticeably more merges with Andrew, with a
lot of various small fixes.
XFS, JFS, ACPI and USB updates. KConfig update, and Rusty's module
parameter implementation. And fix the stupid nanosleep() thing that broke
some programs.
I'm pushing this out, as I've tried to sync up the stuff I got while I was
away this week (hint hint: if it ain't here, it's not in my in-queue, and
you should re-send).
Linus
---
Summary of changes from v2.5.51 to v2.5.52
============================================
Dario Ballabio <[email protected]>:
o eata driver update
Peter Braam <[email protected]>:
o intermezzo update
James Simmons <[email protected]>:
o VT scrolling fix
<[email protected]>:
o USB: start to remove static minor based arrays in drivers
<[email protected]>:
o Datafab KECF-USB / Sagatek DCS-CF / Simpletech UCF-100
<[email protected]>:
o support for Sony Cybershot F717 digital camera / usb-storage
<[email protected]>:
o missing piece of Iphase atm driver update
Stelian Pop <[email protected]>:
o sonypi driver update
Andrew Morton <[email protected]>:
o Avoid recursion in the page allocator
o deprecate use of bdflush()
o create /proc/kmsg, remove sys_syslog()-based
o speed up read_zero() for !CONFIG_MMU
o Fix rmap locking for CONFIG_SWAP=n
o semtimedop - semop() with a timeout
o skip memory-backed filesystems in writeback
o Remove fail_writepage, redux
o show_free_areas extensions
o make sure all PMDs are allocated under PAE mode
o handle overflows in radix_tree_gang_lookup()
o Add a sync_fs super_block operation
o implement ext3_sync_fs
o copy_user checks in filldir()
o vm accounting fixes and addition
o hugetlb fixes
o fs-writeback rework
o Add /proc/sys/vm/lower_zone_protection
o Set a minimum hash table size for wait_on_page()
o Reserve an additional transaction block in
o remove PF_SYNC
o Don't inherit mm->def_flags across forks
o bootmem allocator merging fix
o ext2/ext3_free_blocks() extra check
o don't apply file size rlimits to blockdevs
o limit pinned memory due to readahead
o remove a vm debug check
o madvise_willneed() maximum readahead checking
o provide a default super_block_operations
o tidier atomic check in mempool_alloc()
o Fix off-by-one in the page allocator
o pad pte_chains out to a cacheline
o ext2 synchronous mount fix
o Add prefetching to get_page_state()
o ext3: fix error-path bh leak
o remove vm_area_struct.vm_raend
Andy Grover <[email protected]>:
o ACPI: Get rid of progress dots if not in debug mode
o ACPI: update to 20021212
o ACPI: Fix write-related /proc entry functionality
Anton Blanchard <[email protected]>:
o 2.5 fix for > 25 disks
Art Haas <[email protected]>:
o C99 initializers
Ben Collins <[email protected]>:
o IEEE-1394/Firewire update
Brian Gerst <[email protected]>:
o Remove Rules.make from Makefiles
Christoph Hellwig <[email protected]>:
o [XFS] final sendfile bits
o [XFS] fix small typo in rtdev mount code
o [XFS] don't include root_dev.h
o [XFS] remove linvfs_put_inode
o [XFS] rationalize pagebuf_iomove
o [XFS] add a new xfs_mount parameter to xfs_blkdev_get
o [XFS] get rid of pb_daemon/pagebuf_daemon_t
o [XFS] merge page_buf_private_t into page_buf_t
o [XFS] remove some dead code from pagebuf
o share some code between get_sb_bdev and xfs log/rtdev handling
o CREDITS update
Dave Kleikamp <[email protected]>:
o JFS: Fix off-by one error when symlink size == 256 bytes
o Add more statistics to /prod/fs/jfs/ to help performance tuning
o JFS: Move index table out of directory inode's address space
o JFS: Avoid writing partial log pages for lazy transactions
o jfs_truncate needs to call block_truncate_page
o JFS: Fix accounting of active allocation groups
o JFS: Remove COMMIT_Holdlock
Davide Libenzi <[email protected]>:
o epoll bits forgot a nasty printk()
Dominik Brodowski <[email protected]>:
o cpufreq: clean up CPU information
o cpufreq: move x86 configuration to "Power Management"
Greg Kroah-Hartman <[email protected]>:
o USB: Added usb-serial driver core bus support
o Driver core: Fix class leak in class_hotplug
o USB: Moved usb-serial bus specific code to a separate file
o usbaudio.c: fix for urb callback function change
o USB: Fix compile errors with usb-skeleton driver
o USB: usb-skeleton: removed static array of devices
Greg Ungerer <[email protected]>:
o m68knommu fix kstat_cpu usage int ints.c
o m68knommu add missing do_fork arg
o m68knommu spinlocks around signal api calls
o m68knommu remove sys_security
o m68knommu fix ELF_CORE_COPY_REGS macro
o m68knommu current include thread_info.h
o m68knommu hardirq.h include cache.h
o m68knommu definition of TASK_UNMAPPED_BASE
o m68knommu support restart_block
Ingo Molnar <[email protected]>:
o threaded coredumps, tcore-fixes-2.5.51-A0
o ptrace-sigfix-2.5.51-A1
Jeff Garzik <[email protected]>:
o [NET] support IPv6 over token ring (from lkml)
o [netdrvr tg3] a fix, a cleanup, and an optimization
Kai Makisara <[email protected]>:
o SCSI tape driver fixes for 2.5.51
Linus Torvalds <[email protected]>:
o Fix nanosleep() behaviour with NULL "remaining" argument
o Move intermezzo header files to its own private directory
o Remove bogus checkin file from xfs
Marcel Holtmann <[email protected]>:
o Disable bluetty.o if Bluetooth subsystem is used
Martin Schwidefsky <[email protected]>:
o s390: Makefiles
o s390: nanosleep restarting
o s390: io fixes
o s390: uaccess bug
o s390: old tape file
o s390: staticification
o s390: warnings
o s390: export sys_wait4
Matthew Dobson <[email protected]>:
o NUMA topology sysfs panic fix
Matthew Wilcox <[email protected]>:
o Remove test/set_bit from dl2k
Oleg Drokin <[email protected]>:
o reiserfs: Take into account file information even when not doing
preallocation. Fixes a bug with displacing_large_files option
o reiserfs: Fix a problem with delayed unlinks and remounting RW
filesystem RW
o reiserfs: lock_kernel is replaced with its reiserfs variant
o reiserfs: C99 designated initializers, by Art Haas
o reiserfs: Fixed annoying warnings in fs/reiserfs/procfs.c
Pavel Machek <[email protected]>:
o ACPI/S3: fix gcc3.2 compatibility
o ACPI/S3: simplify assembly code a bit
Pete Zaitcev <[email protected]>:
o Patch for debounce in 2.5
Petko Manolov <[email protected]>:
o USB: pegasus kmalloc/kfree stuff
Randy Dunlap <[email protected]>:
o move console_loglevel scalars to array (resend)
Richard Henderson <[email protected]>:
o Revert bogus include workaround
Richard Henderson <[email protected]>:
o sr_ioctl fix
Robert Love <[email protected]>:
o remove error message on illegal ioctl
o printks in drivers/scsi/hosts.c missing return
Roman Zippel <[email protected]>:
o kconfig: qt installation workaround
o kconfig: off-by-one error
o kconfig: config file parse update
o kconfig: dependencies for choices
o kconfig: symbol change notification
o kconfig: geometry defaults
o kconfig: updates
o kconfig: fix T_STRING usage
Rusty Russell <[email protected]>:
o Revert depmod and hierarchy changes
o Module init reentry fix
o Module Parameter Core Patch
o Parameter implementation for modules
o MODULE_PARM support for older modules
Stephen Rothwell <[email protected]>:
o nanosleep compatibility layer fix
o consolidate sys32_times - architecture independent
o mips64 compatibility syscall layer
o consolidate sys32_new[lf]stat - architecture independent
Trond Myklebust <[email protected]>:
o Fix buffer reservations in nfs4xdr.c
o NFSv4 cleanups
o Add helper routines for fixing up page alignment on xdr_buf
Zwane Mwaikambo <[email protected]>:
o OSS ad1848 initialisation order
Linus Torvalds wrote:
> Various things here. Most noticeably more merges with Andrew, with a
> lot of various small fixes.
Using it, with the addition of Valdis' fix for the Xircom Cardbus PCI
allocation problem. So far so good, except for IrDA irport that is
colliding with the serial driver as Jean told me. Not sure why the
irport-serial problem doesn't bite me in 2.4.x nor did it bite in
earlier 2.5.x though.
--alessandro
On Sun, Dec 15, 2002 at 07:34:09PM -0800, Linus Torvalds wrote:
> Ben Collins <[email protected]>:
> o IEEE-1394/Firewire update
This merge looks fishy. It seems to be yet another let's throw my CVS
repo in merge and backs out Al's work yo get rid of lots of devfs crap.
It also contains strange changes like:
- ch = kmalloc(sizeof *ch, SLAB_KERNEL);
+ ch = kmalloc(sizeof *ch, in_interrupt() ? SLAB_ATOMIC : SLAB_KERNEL);
that really want proper fixing.
>>>>> "CH" == Christoph Hellwig <[email protected]> writes:
Linus> Ben Collins <[email protected]>: o IEEE-1394/Firewire update
CH> This merge looks fishy. It seems to be yet another let's throw my CVS
CH> repo in merge and backs out Al's work yo get rid of lots of devfs crap.
FWIW (which may be little) the ieee1394 code in 2.5.51 simply does not
work and the svn tree (same code as in 2.5.52) does. For those of us
who depend on sbp2 for day-to-day functionality it makes current 2.5
possible....
That said, less divergence between Linus' bk tree and linux1394.org's
svn tree would be welcome.
-JimC
Linus Torvalds <[email protected]> writes:
> XFS, JFS, ACPI and USB updates. KConfig update, and Rusty's module
> parameter implementation. And fix the stupid nanosleep() thing that broke
> some programs.
Something broke the init= kernel cmd line option, I suspect Rusty's
parameter stuff ...
I boot my box via initrd + pivot_root, with "ramdisk_size=16384
root=/dev/ram0 init=/linuxrc rw" on the kernel command line. When
booting 2.5.52 I get a shell prompt at the point where usually linxrc
starts. Just typing "exec /linuxrc" at this point invokes the usual
boot sequence ...
Gerd
--
Weil die sp?ten Diskussionen nicht mal mehr den Rotwein lohnen.
-- Wacholder in "Melanie"
On Mon, Dec 16, 2002 at 10:26:40AM +0000, Christoph Hellwig wrote:
> On Sun, Dec 15, 2002 at 07:34:09PM -0800, Linus Torvalds wrote:
> > Ben Collins <[email protected]>:
> > o IEEE-1394/Firewire update
>
> This merge looks fishy. It seems to be yet another let's throw my CVS
> repo in merge and backs out Al's work yo get rid of lots of devfs crap.
Quit talking shit. I go through a lot of effort to merge in changes sent
to Linus' tree into the Linux1394 repo. I don't just dump changes for no
good reason.
How about pointing out some specifics? Maybe make my job easier by
getting me some patches directly. Trying to track two seperate source
tree's isn't as easy as you might think.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
> > Trying to track two seperate source tree's isn't as easy as you might think.
>
> In fact it's not difficult at all with a proper SCM, a bit of care and the
> right attitude. I merge the changes from XFS (and about half a donzend
> XFS-related repositories inside SGI that all need proper merging / keeping
> in sync) to Linus all the time. And by keeping the changesets (or atomic
> commits in SVN terminlogoy) as one patch each, hand-editing as needed when
> merge conflicts arrive that works very well, even if I had been away and
> the changes for four weeks need merging or as now we're five patchlevels
> away from Linus tree (at 2.5.47). I've not lost a single upstream change
> with that merge policy yet.
>
> And no, that's no BK advertisment, SGI uses a RCS-based SCM internally and
> I use unfied diffs to get it into a staging repository for Linus to pull.
When someone pays me to work fulltime on Linux1394, I'll give it that
much time. Until then I have to make due with what time I have. If I
miss things because people would rather send patches to Linus than me,
it isn't my fault, but I'll do my best to fix it up.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
On Mon, Dec 16, 2002 at 10:16:39AM -0500, Ben Collins wrote:
> > This merge looks fishy. It seems to be yet another let's throw my CVS
> > repo in merge and backs out Al's work yo get rid of lots of devfs crap.
>
> Quit talking shit. I go through a lot of effort to merge in changes sent
> to Linus' tree into the Linux1394 repo. I don't just dump changes for no
> good reason.
>
> How about pointing out some specifics?
Take a look at the changeset at
http://linus.bkbits.net:8080/linux-2.5/diffs/drivers/ieee1394/[email protected]?nav=index.html|src/|src/drivers|src/drivers/ieee1394|hist/drivers/ieee1394/dv1394.c.
Your big BLOB merge basically undoes everything in there.
> Maybe make my job easier by getting me some patches directly.
It was Al's patch, not mine.
> Trying to track two seperate source tree's isn't as easy as you might think.
In fact it's not difficult at all with a proper SCM, a bit of care and the
right attitude. I merge the changes from XFS (and about half a donzend
XFS-related repositories inside SGI that all need proper merging / keeping
in sync) to Linus all the time. And by keeping the changesets (or atomic
commits in SVN terminlogoy) as one patch each, hand-editing as needed when
merge conflicts arrive that works very well, even if I had been away and
the changes for four weeks need merging or as now we're five patchlevels
away from Linus tree (at 2.5.47). I've not lost a single upstream change
with that merge policy yet.
And no, that's no BK advertisment, SGI uses a RCS-based SCM internally and
I use unfied diffs to get it into a staging repository for Linus to pull.
On Mon, 16 Dec 2002, Ben Collins wrote:
>
> How about pointing out some specifics? Maybe make my job easier by
> getting me some patches directly. Trying to track two seperate source
> tree's isn't as easy as you might think.
It's a lot easier if you track them _often_ instead of just occasionally.
That's the main problem I have with other peoples CVS trees - CVS has very
little support for tracking any outside sources, and that coupled with the
fact that people don't track it in a timely manner always generates
problems.
With CVS, a simple script like
(a) get current version
(b) diff against the last version you did the merge against
(c) apply the diff to your new tree
(d) _then_ do the diff against the current version
(e) delete "last version merged", make current version that.
will work pretty easily most of the time for subsystems that don't get a
lot of input from outside the "maintainer". Especially if you do it
reasonably often (you can do the back-merge even when you're _not_ ready
to actually send me your stuff), the diff from my tree is often quite
small and thus easily mergible.
If you think that "maintainer" means that nobody else can touch the tree
and that you thus don't need to care, you're WRONG.
Alternatively, never EVER make a patch against the "current kernel
version". Only make a patch against the _last_ kernel that you merged
with, and if I cannot apply it I will tell you so. Making a patch just
between your tree and mine will _always_ end up losing fixes.
Linus
> If you think that "maintainer" means that nobody else can touch the tree
> and that you thus don't need to care, you're WRONG.
I never said that. What I said was that because I can't spend lots of
time tracking changes, _sometimes_ I miss them. You will see in the SVN
repo logs a lot of places where I merge in changes from your tree. It's
a fact that people make mistakes. I've already rectified this one by
adding in the patch to the linux1394 repo.
I wasn't pushing off blame, just noting that it's not possible to never
make mistakes. You make them too.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
> Alternatively, never EVER make a patch against the "current kernel
> version". Only make a patch against the _last_ kernel that you merged
> with, and if I cannot apply it I will tell you so. Making a patch just
> between your tree and mine will _always_ end up losing fixes.
I think this is a good approach. If people sent Linus patches with some
indication of the baseline of the patch, such as BASELINE=v2.5.49 in the
header of the patch, I'd be willing to go make bk import -temail do
the right thing, which would probably be to try and patch it in in the
working tree, but if that didn't work, it would do
bk clone -l -r$BASELINE tree tree.$BASELINE
cd tree.$BASLINE
bk import -temail ....
cd ../tree
bk pull ../tree.$BASELINE && rm -rf ../tree.$BASELINE
and you'd get BK to merge most of the work.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Mon, 16 Dec 2002, Larry McVoy wrote:
>
> > Alternatively, never EVER make a patch against the "current kernel
> > version". Only make a patch against the _last_ kernel that you merged
> > with, and if I cannot apply it I will tell you so. Making a patch just
> > between your tree and mine will _always_ end up losing fixes.
>
> I think this is a good approach. If people sent Linus patches with some
> indication of the baseline of the patch, such as BASELINE=v2.5.49 in the
> header of the patch,
The problem here is that I often cannot do a sane merge.
I have no problem at all merging stuff that is a week old or so (major
clashes happen sometimes, and I ask for help, but it's rare). However, if
somebody really uses a major external CVS tree and does big patches,
eventually the likelihood of a problem grows big enough that the patch
sender might as well merge _first_ anyway, since otherwise I'll just ask
for his help.
HOWEVER, even if I end up having to ask for help, this is probably
preferable to the "just install my tree" approach, since at least we don't
lose bugfixes and other updates silently.
Linus