This is the patches I have in my pending/twiddled with pile at the moment.
I'll also send bits of this off to Linus
Whats different
o Ramfs allows size limiting (very handy when fiddling with PDA's)
o Knows the 'kgcc' convention for conectiva/mandrake/red hat
o Build ACPI if you have ACPI but no interpreter
o Tidy up naming on machine check code
o 36bit MTRR
o Fix PIV ident bug
o Fix K6 CPU on dual board crash
o Much faster block copy functions on the Athlon
o Fix daemonize to do exit_files. All callers do this or should do
anyway
o Cpqarray procfs fix
o Fix build bug with old hard disk driver
o Fix free then reference with pcbit isdn
o Check/requestion region clean for radio drivers
o Cleaner version of the PnP cadet radio patch
o Seperate tx timeout code for 8390
o Network driver request region fixes
o de4x5 user space copy in spinlock fix
o epic100 delay fixes
o Avoid crash on iph5526 on out of memory
o Fix locking bugs on roadrunner
o Fix crash on insmod risk with many scsi drivers
o Fix incorrect runtime panics in some scsi drivers
o Fix HZ in the aha152x driver
o Remove escaped and dead check for I2O in megaraid
o Fix i810 audio driver
o Fix cramfs initrd data loss bug
o Fix power management locking
o Fix resource printks that only print 4 digits
o Fix missing return value in atm pvc
o Disable SPX (doesnt work, no maintainer etc)
Alan
the network driver changes look ok except for:
epic100:
* CARDBUS is never defined. Should that be CONFIG_CARDBUS?
* just increment the version number. There's no need to add "a" on the
end... this version number just differentiates us from the 'canonical'
Donald Becker version of epic100.c.
net/atm/pvc: return the error value from sock_register, not toss it
away.
ramfs comments:
* Hang on to the ramfs changes for a day or two, there is kmap cleanup
(now returns void*) going to Linus RSN.
* Does ramfs_statfs() need that sb lock in it? Sure free_pages/inodes
might be getting updated on some other CPU, but its statfs so who
cares...
* the default ramfs maxsize, half of all RAM, seems a little
conservative.
* there is no need to kmalloc a private superblock structure, when room
is already allocated inside the superblock structure for private data.
(sb->u)
*
I wonder if we really need removepage added to struct address_space?
That's one API change we shouldn't throw in without discussion, IMHO...
it screams "ramfs-specific hack in core code!"
void __remove_inode_page(struct page *page)
{
+ struct address_space *mapping = page->mapping;
+
+ if (mapping && mapping->a_ops && mapping->a_ops->removepage)
+ mapping->a_ops->removepage(page);
+
And finally, don't you need to EXPORT_SYMBOL pm_devs_lock ?
--
Jeff Garzik |
Building 1024 | Would you like a Twinkie?
MandrakeSoft |
> * CARDBUS is never defined. Should that be CONFIG_CARDBUS?
Yep
> * just increment the version number. There's no need to add "a" on the
> end... this version number just differentiates us from the 'canonical'
> Donald Becker version of epic100.c.
Ok
> net/atm/pvc: return the error value from sock_register, not toss it
> away.
>
>
> ramfs comments:
Note: the ramfs changes are in there for one reason only - that Im hacking
on some bits with a pda type box and I cannot be bothered to keep two
sets of trees
> That's one API change we shouldn't throw in without discussion, IMHO...
> it screams "ramfs-specific hack in core code!"
Absolutely
> And finally, don't you need to EXPORT_SYMBOL pm_devs_lock ?
Yep
Date: Wed, 8 Nov 2000 23:01:50 +0000 (GMT)
From: Alan Cox <[email protected]>
o Fix incorrect runtime panics in some scsi drivers
In drivers/scsi/fcal.c you correctly free "ages", in the
equivalent drivers/scsi/pluto.c fix you forget to do this.
Later,
David S. Miller
[email protected]
Would you care to comment on the VPN Masquerade patch that has been
floating around? Will it make it into an official 2.2.x kernel soon? The
VPN-Masq HOWTO seems to think it is going into 2.2.18 proper.
ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn-2.2.17.patch.gz
> Would you care to comment on the VPN Masquerade patch that has been
> floating around? Will it make it into an official 2.2.x kernel soon? The
> VPN-Masq HOWTO seems to think it is going into 2.2.18 proper.
There is already more than enough in 2.2. The code is on my pending queue
(some of it anyway)